Ok, it start to feel like all I do is talking to myself these days. Something I hope will change now as I need some help. Can I take you up on your offer Grishata?
I have now typed up most of the LinuxSampler SFZ Implementaton
chart. It probably still contain some mistakes and omissions (or rather I know
it does). But I think I've got a good grasp of the updated SFZ v2 format. The format is quite extensive as it's supposed to cover all kinds of synths and samplers. We can't possibly support everything and have to settle for what's important to us. We shouldn't be afraid of striking out even more opcodes in the chart than I've already done. Even if we just implement a fraction of it, it will still be more flexible and powerful than our existing GIG Engine.
The basic signal path for each voice is:
Sample player -> Filter -> 3x Parametric EQ -> Amplifier
Each voice has also a number of flexible EGs and LFOs that can be set to modulate any parameter in the above signal path. The number of EGs/LFOs per voice is up to us to decide (allocating them dynamically is probably the best idea). Also pretty much any parameter in the signal path can be modulated by a MIDI CC.
While I intended the SFZ reader to be a reusable external library I probably will have to rethink that. The plan to just plug all the CC values into it and get back all the current performance parameters won't work as the _smoothcc
opcodes can't be implemented in a stateless lib. So I'm scrapping the Articulation
API idea. As the file format is quite straight forward to parse, anyone can easily write their own libsfz
anyway, the sfz.h/sfz.cpp
should simply just be made a part of the LinuxSampler SFZ Engine.
I will probably have to refactor sfz.h/sfz.cpp
as it's now grown quite large. There's a lot of repetition as I've so far just done "the simplest possibly thing that work".
Anyhow, I would appreciate if someone more familiar with the LinuxSampler code framework can lend me a hand and create the new SFZ Engine?
Happy Easter/Pesach everyone!