[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[fluid-dev] sfz on top of fluidsynth
From: |
Stefan Westerfeld |
Subject: |
[fluid-dev] sfz on top of fluidsynth |
Date: |
Fri, 18 Oct 2019 19:14:51 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
Hi!
I've been working on a sfz loader for fluidsynth. I've made the code
available on github, it is C++17, I use LGPL2.1+ like fluidsynth itself:
https://github.com/swesterfeld/liquidsfz
So this adds the necessary bits to make fluidsynth be able to parse,
load and play sfz files. This is early in the development process, so
quite a few essential opcodes are still unsupported. Partially the
question is also to what degree fluidsynth itself could/should be
modified to get better sfz support.
For instance, in the SalamanderGrandPiano, a sound is supposed to be
played if a key is released (trigger=release):
https://sfzformat.com/opcodes/trigger
Another sound is supposed to be played if the sustain pedal is pressed:
https://sfzformat.com/opcodes/on_hiccN
As far as I can see, neither can possibly be implemented with the
existing loader API, because the loader API only allows me to define a
note_on function. Probably some more examples of unimplementable with
the current API (or even synthesis model) exist. So in the long run, I
see three ways to deal with this
- fluidsynth is actively extended to get better sfz support
- these opcodes will remain unsupported forever
- liquidsfz gets its own sampler and no longer uses fluidsynth
Cu... Stefan
--
Stefan Westerfeld, http://space.twc.de/~stefan
- [fluid-dev] sfz on top of fluidsynth,
Stefan Westerfeld <=