SFZ

[dahnielson]

Yes, new opcodes were required for Steinway, and also for the porting of GPO/JABB. We however added them following the "style" of the other pre-existing opcodes, so that it all felt like a logical progression, or that they would fill some obvious oversights in the spec. (For instance amplitude and amplitude_oncc were missing whereas "egXX_amplitude" already existed as target for EGs and LFOs.)

Note: amplitude and volume are different opcodes, the first being expressed as percentage, and the other in decibel (sometimes its good to have both available).

[dahnielson]

Now I'm just anal and documenting everything that won't be supported by LinuxSampler. Like SFZ v1 stuff that can be considered deprecated.

(Funny how "deprecated" has a connotation in the developers vocabulary compared to the standard usage.)

[dahnielson]

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 and _stepcc 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!

[grishata]

I think I can handle at least the very basic/initial implementation of the new engine, but first we really need to make a new release and there are still some bugs that need to be fixed. After that, this will be my top priority.

[dahnielson]

Great to hear!

[cuse]

The SFZ2 format looks very promising, probably the best candidate for a 2nd engine in LinuxSampler at this point. As the new LS release is (hopefully) just days or max. weeks ahead, I hope we can start with that very soon.

Does SFZ2 support scripting as well? If not, is there a way in SFZ2 to extend it with scripting support for our engine?

[dahnielson]

The SFZ2 format looks very promising, probably the best candidate for a 2nd engine in LinuxSampler at this point. As the new LS release is (hopefully) just days or max. weeks ahead, I hope we can start with that very soon.

Does SFZ2 support scripting as well? If not, is there a way in SFZ2 to extend it with scripting support for our engine?

No, there's no scripting in SFZ2.

However, my question will then be: what do you want to script? Because the SFZ2 format allow you to do a lot of impressive stuff directly with its opcodes to create deeply sampled and programmed instruments, that you otherwise would need scripting to achieve in e.g. Kontakt.

Of course, there's always the possibility to add a new custom opcode that can be used to point to a script file.

[cuse]

However, my question will then be: what do you want to script? Because the SFZ2 format allow you to do a lot of impressive stuff directly with its opcodes to create deeply sampled and programmed instruments, that you otherwise would need scripting to achieve in e.g. Kontakt.

That's too early to say, since I haven't really digged into the SFZ2 specs yet. But I'm quite sure no matter how powerful the already existing opcodes are, there will certainly be demands for more features, that is either new opcodes or even a separate scripting language. But we'll certainly start with implementing already existing opcodes and at a (far) later point we will see if there's need for our own extensions.

[Octron]

Hi,
is it possible to use multichannel Wav or OGG Files instead of simple Stereo or MONO Files in SFZ??

It would be a great benefit because I am planning to build a Drum library.
Therein I decide to play not only the direct microphoned source but also the overheads. For example Snaredrum direct signal from upper membrane and second direct signal from lower membrane and finally the overhead signal.

If I could do so, I am able to build a real sounding drum set with crosstalks.

By the way, is there a short delay when playing two sounds via the same midi channel?
Or are the two sounds played back sample-synchron??

If not, I could build serveral librarys, each for each drum instrument, stack them in Linuxsampler and connect them all to the same midichannel.
If the samples were played back really simultaneously it would be possible to trigger a real drumset with 10 microphone positions playing all together.

Best Wishes!

[Andreas]

Hi,
is it possible to use multichannel Wav or OGG Files instead of simple Stereo or MONO Files in SFZ??

No, sorry, it's not currently possible.

By the way, is there a short delay when playing two sounds via the same midi channel?
Or are the two sounds played back sample-synchron??

I'm not sure, but I think that depends on the chosen midi driver and the sequencer. If LS gets midi events with the same timestamp it should play them synchronously, sample-accurate.