bb.linuxsampler.org

Yes. It's just that the SFZ 2.0 spec is only available in print and not online. I think that it is the author Simon Cann who put in all the effort to properly document it in his book. SFZ 2.0 is pretty much the same as 1.0 but with some added or renamed opcodes and additional sections. And hopefully somethings have been corrected and clarified.

It's a format that ought to be popularized.

The SFZ 1.0 spec at Cakewalk DevXchange probably needs an errata. Here's another issue I've come across:

sw_lokey, sw_hikey -- Defines the range of the keyboard to be used as trigger selectors for the sw_last opcode. Defaults: sw_lokey=0, sw_hikey=127.
sw_last -- Enables the region to play if the last key pressed in the range specified by sw_lokey and sw_hikey is equal to the sw_last value. Default: sw_last=0.

If I would follow the description above literary I would be required to press C-1 before playing a note if none of the opcodes is set explicitly. However the default values are defined as being "expectable":

Input Controls and Performance Parameters opcodes are optional, so they might not be present in the definition file. An 'expectable' default value for each parameter is pre-defined, and will be used if there's no definition.

But what "expectable" means isn't defined, I guess it should be interpreted as RECOMMENDED in general and as MAY in the problematic case above.

So I think I will change the default to -1 (unassigned) which makes more sense.

Another errata worthy behavior from SFZ 1.0:

group -- Exclusive group number for this region. Default: group=0.
off_by -- Region off group. When a new region with a group number equal to off_by plays, this region will be turned off. Default: off_by=0.

So all groups are mutually exclusive by default?

-1 (unassigned) is a more reasonable default.

Something else I don't find spelled out clearly:

seq_length -- Sequence length. The player will keep an internal counter creating a consecutive note-on sequence for each region, starting at 1 and resetting at seq_length.

Will the internal counter only be advanced on a note-on produced by a key (regular note-on) or will it also advance when a continuous controller (set by on_loccN and on_hiccN opcodes) trigger a sample?

Of course that depends on a correct interpretation of the on_loccN and on_hiccN opcodes. I read the spec as they actually trigger the region like a regular note-on:

Sample trigger on MIDI continuous control N. If a MIDI control message with a value between on_loccN and on_hiccN is received, the region will play.

Examples:
on_locc1=0 on_hicc1=0

Region will play when a MIDI CC1 (modulation wheel) message with zero value is received.

And not that they define the range of last control message required for the region to play. I think the latter behavior similar to the modwheel dimension in Gigasampler is more reasonable.

But if one read the executive summary you are told this:

Unlimited regions of sample playback based on MIDI controllers (continuous controllers, pitch bend, channel and polyphonic aftertouch, keyboard switches) and internal generators (random, sequence counters)

That statement seem to confirm that my preferred behavior is the correct one since there are no other opcodes to create those CC regions other than on_loccN and on_hiccN. But the next bullet point says:

Sample playback on MIDI control events.

Which is the other interpretation of on_loccN and on_hiccN!

Just a note for future sample developers:

lochan and hichan only makes sense to set when the SFZ instrument is loaded into a sample channel operating in omni mode (assigned MIDI channel is "ALL") unless you want to be evil and i.e. deny someone using you precious percussion library on any other MIDI channel than #10.

PS. I can't wait to get my hands on Simon Cann's Cakewalk Synthesizers to get all the things in previous posts straightened out.

dahnielson wrote: Of course that depends on a correct interpretation of the on_loccN and on_hiccN opcodes. I read the spec as they actually trigger the region like a regular note-on [...] And not that they define the range of last control message required for the region to play. I think the latter behavior similar to the modwheel dimension in Gigasampler is more reasonable.

But if one read the executive summary you are told this:

Unlimited regions of sample playback based on MIDI controllers (continuous controllers, pitch bend, channel and polyphonic aftertouch, keyboard switches) and internal generators (random, sequence counters)

That statement seem to confirm that my preferred behavior is the correct one since there are no other opcodes to create those CC regions other than on_loccN and on_hiccN. But the next bullet point says:

Sample playback on MIDI control events.

Which is the other interpretation of on_loccN and on_hiccN!

I have finally figured it out!

Take a look at this example from the preamble (my emphasis):

It is very important to note that all Input Controls defined in a region act using the AND boolean operator. Consequently, all conditions must be matched for the region to play. For instance:

<region> lokey=64 hikey=67 lovel=0 hivel=34 locc1=0 hicc1=40 sample=440.wav

This region definition instructs the player to play the sample '440.wav' if there is an incoming note event in the 64-67 range AND the note has a velocity in the 0~34 range AND last modulation wheel (cc1) message was in the 0~40 range.

These are the two opcodes used to define the CC region. But when you try to find them in the actual Opcode List, they're nowere! Non-existing!

But if you look at the entry in the list for lovel, hivel you will find them being mentioned in the "Default"column instead of lovel/hivel. So the two entries for lovel/hivel and locc/hicc have been merged/mixed/f-up'd. The bottom line is simply that whoever wrote the SFZ 1.0 spec did a sloppy job!

I am looking into SFZ but the real reason I am posting is because after posting in the forum for hours I saw that there was only one category that my name was not the most recent post

Hey the guys with the green font on their names always dominate the board

Sorry for the silly post

hi,

are there any news concerning sfz{1|2} support for linux sampler please ?i have a urge library to convert and i was wondering...

Thank for the interest. It's progressing slowly. So I would advice you not to hold your breath.

thanx for the answer, i appreciate
do you know about that project : http://audio.clockbeat.com/sfZed.html ?
maybe this can help somehow
see ya