The most future proof format for sampled instruments is SFZ

[enroe]

Thoughts come to a head. Here we have the idea of a better
encryption format so that sound libraries can also be
"commercialized":

A lot of people use commercial samplesets. It would be nice to have those samplesets in a more future-proof format. If SFZ supported encryption, then more commercial samplesets *might* be in sfz format. Thus providing more future-proofness for those commercial samplesets.

And here we have the tendency towards a thoroughly "free
format" that draws its strength from accessibility, and that
everyone can and should use:

I ... believe that encryption would do more harm than good with the
format. The chief redeeming feature of SFZ, in my opinion, is the open
nature of the format—the very opposite of encryption.

This is a contradiction that occurs in many areas of our world and
causes controversy: Some people would like to convert everything
into a huge shopping world in which everything and everything is
valued in dollars or euros. And the other would like that everything
- as well as the air to breathe - remains free for everyone.

The child in every human being, and so also the artist in one, should
actually vehemently advocate that everything remains "free".
Because art itself also happens out of freedom:

Art - and with it music - happens out of free creativity, out of the
childish desire to change and shape things. Every marketing
consideration, efficiency consideration or deadline would immediately
stifle the free creation of the individual. Any boss who enforces order
in a military manner, who puts pressure on the team and lets everyone
"run in one direction" in an efficient manner, buries any impetus for
art and free creativity.

And it's the same with the music and the sample libraries: do you
want the world to turn into a giant shopping mall, where every piece
of shit has a price, and where really everything is measured in
dollars or euros?

Or do you want a free world where the individual can still breathe
air freely, water is free to drink and sample libraries are free for
everyone?

-------------------- Now some say: you are exaggerating!

No, I do not think so. Of course we are all part of the world where
everything around us is measured in dollars or euros, because we
all have to shop and pay our rent. We all need to submit in a job and
obey the boss in order to generate our income and also to exist
financially in the commercial world. Submitting oneself, earning
money, looking at prices and spending money, consuming, all of
that is a market economy and part of our civilization.

But art and music - music mostly practiced by us as a hobby in the
evening or at the weekend - are a kind of refuge in our personal
freedom, where we pursue our need to create something "freely".
It's sort of our niche for "personal freedom", for actual "being human".

I would like to keep this niche free - also from all the commercial
quirks, from all the price tags and efficiency considerations of my
boss. I don't want this retreat niche to be commercialized either. And
that's why I find "free software", open source, and also free formats
like SFZ so attractive and beautiful. And it is precisely from this that
free formats derive their special suitability for art - for free creation -
for music.

[Ah_Dziz]

I still think that a folder named "patch name" containing properly named wav/aiff with all proper loop, BPM, etc. Metadata included will beat out pretty much everything for future proofing.

I use a number of SFZ features that don't fit in metadata (like velocity layer, which is REALLY important to me, and velocity crossfading, which I often use, and velocity filter control when I don't have velocity layers, and ... well, I bet the list goes on, and I only build REALLY SIMPLE sfzs compared to my friends like DSmolken.)

The few times I've made my own multi samples I always have velocity layer, pitch and, RR number in the name. That's what I meant. It makes stuff incredibly easy to import into any sampler.

[JeffLearman]

Agreed on most points, Audiojunkie. I actually think that encryption (IMHO, just of waveforms) for sfz would be great, but I doubt it'll ever happen (and doubt it's even feasible.) So, that's not a practical issue, and you win.

The best source I know of regarding adoption of SFZ opcodes is at http://sfzformat.com.

Doesn't Polyphone qualify as an open-source GUI SFZ editor? I haven't used it, other than to try it once and realize it wasn't what I needed at the time (but I don't want a GUI-based editor: I create my SFZs using scripts and programs, so I can very quickly create a sampleset from my digital piano, etc. One of my after-retirement projects will be to automate this so it's easy for anyone to do.)

[JeffLearman]

The few times I've made my own multi samples I always have velocity layer, pitch and, RR number in the name. That's what I meant. It makes stuff incredibly easy to import into any sampler.

Me too, so my SFZ sample sets are as future-proof as I can make them, while also being as easy to use as possible.

[JeffLearman]

Enroe, I agree with your sentiment, but I also believe that a songwriter should be able to make a living, so I am a proponent of copyrights. (Of course, copyright law was taken to extremes and abused by the industry in the DMCA and Disney's extensions of copyright periods, because Disney wants to own everything despite it's material is based on public domain fairy tales -- that's another discussion where I'm sure we would agree.)

I also am fine with the idea that people can make money by creating samplesets that they can sell. Frankly, I'm glad that instrument manufacturers are profit-motivated to create the great instruments we have today, most of which would not exist without the commercial markets.

Meanwhile, I'm also happy that hobbyists like me can make free samplesets just for the fun of it. I prefer open software, and plan to contribute some myself someday. So, I'm in complete agreement about all the great attributes of free, open stuff. Plus I play music in public for free, and support others who do, in various ways.

And I'm glad that people and companies can do both.

I'm perfectly OK with SFZ staying without encryption. That's a good thing, since I don't think it could happen.

Now, what were we talking about?

[audiojunkie]

Agreed on most points, Audiojunkie. I actually think that encryption (IMHO, just of waveforms) for sfz would be great, but I doubt it'll ever happen (and doubt it's even feasible.) So, that's not a practical issue, and you win.

The best source I know of regarding adoption of SFZ opcodes is at http://sfzformat.com.

Doesn't Polyphone qualify as an open-source GUI SFZ editor? I haven't used it, other than to try it once and realize it wasn't what I needed at the time (but I don't want a GUI-based editor: I create my SFZs using scripts and programs, so I can very quickly create a sampleset from my digital piano, etc. One of my after-retirement projects will be to automate this so it's easy for anyone to do.)

Yes, Polyphone currently is the best that I know of. However, I'm not sure how many SFZ opcodes it saves and ports from Soundfont to SFZ, and if it supports enough of them to match your scripts. It certainly doesn't support the opcodes needed for DSmolken's patches.

[audiojunkie]

The few times I've made my own multi samples I always have velocity layer, pitch and, RR number in the name. That's what I meant. It makes stuff incredibly easy to import into any sampler.

Me too, so my SFZ sample sets are as future-proof as I can make them, while also being as easy to use as possible.

That's cool! What do you try to include in a typical instrument patch?

[audiojunkie]

Enroe, I agree with your sentiment, but I also believe that a songwriter should be able to make a living, so I am a proponent of copyrights. (Of course, copyright law was taken to extremes and abused by the industry in the DMCA and Disney's extensions of copyright periods, because Disney wants to own everything despite it's material is based on public domain fairy tales -- that's another discussion where I'm sure we would agree.)

I also am fine with the idea that people can make money by creating samplesets that they can sell. Frankly, I'm glad that instrument manufacturers are profit-motivated to create the great instruments we have today, most of which would not exist without the commercial markets.

Meanwhile, I'm also happy that hobbyists like me can make free samplesets just for the fun of it. I prefer open software, and plan to contribute some myself someday. So, I'm in complete agreement about all the great attributes of free, open stuff. Plus I play music in public for free, and support others who do, in various ways.

And I'm glad that people and companies can do both.

I'm perfectly OK with SFZ staying without encryption. That's a good thing, since I don't think it could happen.

Now, what were we talking about?

I want to point out that I too feel that developers and artists should all be able to make money off of their work. I'm not against that at all. Everything that I use that isn't open source or released free is purchased. My problem has always been with the methods that developers go about protecting their product from piracy. I'm of the opinion that the honest will buy the product if they use it, and that the dishonest probably won't. I question the validity of the losses due to theft, because I have serious doubts that the dishonest would buy the samples/programs/etc in the first place. Which leads me to believe that anything more than a simple serial number, keyfile or watermarking is more of a hassle to the honest than a deterrent to the dishonest. Then again, this has been argued back and forth over the last 20 years, and everyone has their own opinion of things. There are valid points on both sides. I mainly use Linux and open source because I like the goals behind open source. Everything that I own and use is legitimate--including my U-he and Tal-Software and DiscoDSP plugins, and any sample libraries I've purchased. I like to support the developers that support Linux.

[JeffLearman]

I use open source because I'm cheap!

[JeffLearman]

That's cool! What do you try to include in a typical instrument patch?

Features I typically use:

• velocity layers

• velocity crossfade (xfout_lovel, xfout_hivel)

• ADSR controls, mostly release (ampeg_release)

• stereo width (mapped to a CC, allowing cancelling out stereo image. I often bake a mid-side stereo effect into the samples, which cancels out in mono.)

• velocity curve adjustment (amp_velcurve)

• random round-robin

• Looping (in the audio file, and I don't bother looping anymore unless it's for something like a GM sampleset where I'm trying to minimize disk space per instrument.) When I use this I also use ampg_hold for the length of the sample before the loop (so release won't start until that point)

• velocity control of filter cutoff, when I'm saving space and not using velocity layers. Works better than one might think for things like piano and acoustic guitar.

For details, see

• https://github.com/sfzinstruments/jlearman.jRhodes3d

• https://github.com/sfzinstruments/jlearman.SteelDrum

• https://github.com/sfzinstruments/Disco ... steel).sfz

I've only done simple picked or percussion instruments (e.g., pianos are percussion because the strings are struck.) Otherwise, I'd also use a number of more sophisticated features allowing different articulation for legato. And drums require tricky stuff to handle things like hihat, where playing one sample (closed hihat) stops another (open hihat.)

So, if I had a saxophone (and if my tone on sax didn't sux) I'd use initial vs. legato notes.

I'd also use a feature like that to sample Hammond organ, but sadly, that also requires features that aren't supported by SFZ format. And if SFZ format supported convolutions (which would be easy to add, and pretty natural for it to support) I'd use that too, to handle piano string and harp resonance. Maybe someday I'll add that to sfizz.

[audiojunkie]

I've done a lot of thinking since the last posts about all of this. I am still convinced that SFZ is the best future-proof format. I've also had some realizations that made me reconsider what are the best available players for these instruments.

I have always Considered Sforzando, Sfizz, and LinuxSampler the best software for playing SFZ files. However, the majority of the SFZ instruments out there (I've been collecting and examining them all week), only the most basic of opcodes are used. to create existing instruments. This brings a lot of problems for users who would like things like midi continuous controller support for functionality as simple as adjusting the attack and release time. Most SFZ files simply do not have this ability built-in to the SFZ. As I understand it, the way of doing things with SFZ when exposing midi continuous control to an SFZ parser, is that these things must be defined within the SFZ file itself, which most people don't do. Granted, there are some out there that expose this functionality, but the vast majority of them don't.

One solution to this is to retroactively add AHDSR opcodes to existing SFZ files, thus affecting other peoples work, which may be of concern if licensing doesn't allow for it. Another option, is to make a very usable fill-in-the-blanks generic SFZ file for most non-coding users to utilize, that includes a basic set of functionality, such as AHDSR, Cut-off, Resonance, Volume, pan, etc. It wouldn't be as flexible as being able to custom code the functionality in, but most people aren't coding any of the functionality in at all right now. A basic set of generic functionality is much better than nothing. Many people use software tools that read and map the samples according to information in the file name, such as midi note or number, etc. An ideal solution would be to make these script making programs a bit smarter and include a generic set of functionality by default. In other words, these programs can by default add the extra code to expose the midi CC code by default to expose this functionality to the host and to midi controllers. This may be the best option. Another option, and one that I've been thinking about very seriously, is to go against the SFZ design, which requires the the midi CC control to be defined within the SFZ file, and have the plug-in treat the SFZ as an oscillator section while adding the midi CC functionality as part of the plugin, rather than part of the SFZ file definition. Examples of plugins that currently do this include TAL-Sampler, Altitude, and the upcoming Shortcircuit-XT. The big encryption-based samplers like Kontakt, Halion, etc do this as well, but I suspect that those who use those programs are using them for professionally created multi-gig sample libraries, and are outside of the scope of this conversation.

TAL-Sampler is my personal ideal right now. It treats the SFZ, as mentioned above, as an oscillator section, and doesn't require controllable aspects of the instrument to be defined within the SFZ. I can do anything through SFZ that I can do through a synthesizer. All midi control is exposed and visible to the host, the GUI, and midi CC devices. My opinion, at the moment, is that SFZ is too powerful for its own good, and that is hurting the format. It's the best format, in my opinion for future-proofing sample libraries, but things can be done to make things better for the user, namely simplifying things.

I think if we as a community came up with a basic subset of SFZ opcodes that most SFZ players utilize that allows the basics such as mapping the sample, velocity layers, muting (like for hi-hats), round robins, midi CC control, etc, and focus our efforts on this with the community, this would do a lot to help non-coding users to create more instruments, this would give developers of SFZ parsers a target goal for basic minimal support, and would help unify to some degree the various factions of SFZ. Right now, we have SFZv1 opcodes, Cakewalk opcodes, SFZv2 opcodes, Sfizz opcodes, Aria opcodes, etc. This is all well good, but at the moment, no two SFZ parser plugins support anything cross compatible more than the basic opcodes. There needs to be a base level of common support, a common denominator recommended for all parsers for compatibility's sake.

I've been going through and trying to determine what I personally would need for basic functionality. So far, I've determined the following:

Important SFZ Opcodes:

<global> -- SFZv1
loop_mode -- SFZv1


<group> -- SFZv1
key -- SFZv1
lovel -- SFZv1
hivel -- SFZv1
seq_length -- SFZv1
amp_velcurve_N -- SFZv1


<region> -- SFZv1
sample -- SFZv1
Lokey -- SFZv1
hikey -- SFZv1
pitch_keycenter -- SFZv1
seq_position -- SFZv1
group -- SFZv1 -- Exclusive group number for this region. Examples: group=3 or group=334
off_by -- SFZv1 -- Region off group. When a new region with a group number equal to off_by plays, this region will be turned off. Examples: off_by=3 or off_by=334
volume -- SFZv1 -- The volume for the region, in decibels.
pan -- SFZv1 -- The panoramic position for the region. If a mono sample is used, pan value defines the position in the stereo image where the sample will be placed.
output -- SFZv1 -- The stereo output number for this region. If the player doesn't feature multiple outputs, this opcode is ignored. Examples: output=0 or output=4


trigger -- SFZv1 -- Sets the trigger which will be used for the sample to play. Values can be: Attack, release, first, or legato


ampeg_attack -- SFZv1
ampeg_hold -- SFZv1
ampeg_decay -- SFZv1
ampeg_sustain -- SFZv1
ampeg release -- SFZv1

fileg_attack -- SFZv1 -- Filter EG attack time, in seconds.
fileg_hold -- SFZv1 -- Filter EG hold time, in seconds. During the hold stage, EG output will remain at its maximum value.
fileg_decay -- SFZv1 -- Filter EG decay time, in seconds.
fileg_sustain -- SFZv1 -- Filter EG sustain level, in percentage.
fileg_release -- SFZv1 -- Filter EG release time (after note release), in seconds.

ampeg_attackccN -- SFZv1 -- Amplifier EG attack time added on MIDI control N, in seconds.
ampeg_holdccN -- SFZv1 -- Amplifier EG hold time added on MIDI control N, in seconds.
ampeg_decayccN -- SFZv1 -- Amplifier EG decay time added on MIDI control N, in seconds.
ampeg_sustainccN -- SFZv1 -- Amplifier EG sustain level added on MIDI control N, in percentage.
ampeg_releaseccN -- SFZv1 -- Amplifier EG release time added on MIDI control N, in seconds.

bend_down -- SFZv1 -- Controls the pitch wheel (down pitch)
bend_up -- SFZv1 -- Controls the pitch wheel (up pitch)

amplfo_depth
amplfo_depthccN
amplfo_depthchanaft
amplfo_depthpolyaft

-----------------------------------------

Possible SFZv2 Opcodes to support:

<control> -- SFZv2
default_path -- SFZv2
label_ccN
set_ccN

What is everyone's thoughts on this? Are all of you happy with things as they are with SFZ? Are all of you saying that you wouldn't like to see the majority of available SFZ instruments be able to do more than just note-on/note-off playing of samples?

I think a good idea would be for us as a community to determine the best subset of required SFZ codes (the smaller the better to encourage developers of plugins to support these opcodes. We could list this set of recommended opcodes as an unofficial recommended basic subset and list it on the sfzformat page.

Comments?

[audiojunkie]

As an aside, along with all of my research this week, I've come to realize a major change in the Sampler industry. What in the world happened to all of the chromatic samplers? There are literally no dedicated chromatic samplers in hardware anywhere to be found anymore. Everything that currently exists is essentially a drum machine with a little bit of chromatic capability thrown in. There doesn't seem to be any good hardware samples since the early 2000s! This alone makes me treasure TAL-Sampler even more than ever.

[audiojunkie]

Agreed on most points, Audiojunkie. I actually think that encryption (IMHO, just of waveforms) for sfz would be great, but I doubt it'll ever happen (and doubt it's even feasible.) So, that's not a practical issue, and you win.

The best source I know of regarding adoption of SFZ opcodes is at http://sfzformat.com.

Doesn't Polyphone qualify as an open-source GUI SFZ editor? I haven't used it, other than to try it once and realize it wasn't what I needed at the time (but I don't want a GUI-based editor: I create my SFZs using scripts and programs, so I can very quickly create a sampleset from my digital piano, etc. One of my after-retirement projects will be to automate this so it's easy for anyone to do.)

BTW, I just discovered that SFZ "DOES" have encryption!!!! Aria is the only player that supports it though. I thought you'd find that interesting.

https://www.chickensys.com/products2/co ... rmats.html

Read the foot note about the Garritan Aria encrypted SFZ format:

"...As of this writing, the only SFZ files that use encrypted samples are the Garritan Aria-Player libraries. Any SFZ file that references an ".audio" file is encrypted."

https://www.chickensys.com/products2/co ... rmats.html

It's been here all along, but just never caught on in popularity. Only the Aria SFZ parser supports it.

[audiojunkie]

So, as I understand this, the following script part would allow midi CC controlled ADSR. Correct?

<control>
label_cc100=Attack time
label_cc101=Hold time
label_cc102=Decay time
label_cc103=Sustain level
label_cc104=Release time

set_cc102=63
set_cc103=51
set_cc104=31

<global>
//AHDSR
ampeg_attack=0.002
ampeg_sustain=0
ampeg_release=0.002
ampeg_attack_oncc100=0.5
ampeg_hold_oncc101=1
ampeg_decay_oncc102=5
ampeg_sustain_oncc103=100
ampeg_release_oncc104=2

The Label_cc opcode would be for any SFZ player that shows visual controls of the assigned midi number on its screen, like Sfizz, right?

The ampeg_attack, ampeg_sustain, and ampeg_release opcodes set the initial time values in seconds for the envelope. This part I think I understand just fine.

The set_ccN opcode sets a default initial value for MIDI CC number N, and where between 1 and 127 the midi cc 102 will start when the instrument is initially loaded. This seems to make sense. So for example, set_cc102=63 is telling the SFZ parser to listen for incoming data on Midi cc 102, and the starting value (between 1-127) for this newly assigned controller is: 63.

This would mean that ampeg_decay_oncc102=5 means that the continuous controller number 102 is being assigned to the decay part of the ADSR function, with an increment of 5 every time the midi controller number goes up or down by 1. So, an initial setting that starts at 63, if someone turns the knob to 64, the initial release of 0.002 is incremented or decremented by a stepsize of 5. I'm guessing that the number after the = is the stepsize, although the documentation doesn't make it clear. It simply states that it is a float value with a range between -100 and 100, but it isn't clear as to if it is the stepsize of the incrementation, so I'm not sure.

[DSmolken]

Yeah, at first glance that looks like it would work. You can add that to the top of any instrument, and vibrato would be similarly easy.

Two caveats: some instruments will have multiple <global> headers (defeating the point of the global nomenclature, I know, I know... but even a lot of my free ones have three or four, as that makes implementing unison easier by giving each voice its own global), and this would need to be added to each. Also you might not want the same AHDSR envelope on everything in certain cases, for example when there are separate release or mechanical noise samples.