Scoring Central

Hi,

Just registered and I start with a question right away. Hope this is the right place (noob question)

I use Reaper For Linux and both native linux vst's and windows via Wine/LinVST. My question:

• I load a sfz file from SSO Library (Brass - Bass Trombone) in Linuxsampler, not a single sound on the four soundsfonts (TB Solo, TB Solo KS, TB Solo (looped) and TB Solo (looped, decay)
  
• I load exactly the same file in SForzando - they all work
  
• I load exactly the same file in SFZero (linux) some works, but not all of them
  

Why is it like that? I tried several sf in Linuxsampler, some work and some don't. The same sf in SForzando they always work. I know that Linuxsampler ain't the newest one and no updates what I know of. I run it through Fantasia, don't know if that's the case here. Somehow it ain't "reading" the file as good as SForzando. I don't know how many Reaper For Linux users is here, but maybe someone know and recognize this problem.

Thanks

//Tobbe

(05-22-2019, 03:47 PM)Tobbe Wrote: [ -> ]Just registered and I start with a question right away. Hope this is the right place (noob question)

Sure, it is fine to ask these kinds of questions.

One of many troubles with SFZ format is that there is no single standard; every SFZ player supports its own set of opcodes, so you don't have any guarantee that two players will render the same sound. From my experience, Linuxsampler has better coverage than SFZero, but still there are things that work well in SForzando that just fall apart in Linuxsampler.

(05-22-2019, 05:03 PM)Michael Willis Wrote: [ -> ]

(05-22-2019, 03:47 PM)Tobbe Wrote: [ -> ]Just registered and I start with a question right away. Hope this is the right place (noob question)

Sure, it is fine to ask these kinds of questions.

One of many troubles with SFZ format is that there is no single standard; every SFZ player supports its own set of opcodes, so you don't have any guarantee that two players will render the same sound. From my experience, Linuxsampler has better coverage than SFZero, but still there are things that work well in SForzando that just fall apart in Linuxsampler.

Is SF2 files "more" standard than SFZ?

(05-22-2019, 05:08 PM)Tobbe Wrote: [ -> ]Is SF2 files "more" standard than SFZ?

Welcome to the forum!

Sf2 and SFZ files are unrelated so I don't really understand the question here.... Soundfont = sf2 format.

I think Tobbe is asking whether SF2 soundfonts are more consistent across different players than SFZ. I'm inclined to say yes, with caveats. SF2 is a much more simple format; as such it is less complicated to implement a plugin to play SF2, and I'm not aware of any deficiencies in the open source sf2 engines. However, being a simple format, you miss out on a lot of nice features that you get in SFZ: round robin, crossfading, and release samples to name a few.

Yes, I just wanna know the difference. I tried SSO 1st  and 2nd Violin yesterday with Linuxsamper and everything worked. They are in SFZ format. But the Brass files doesn't.

Thanks for clarifying

/Tobbe

Because SFZ has never had a central standard-setting authority, it has always been open for any developer to come in and add or ignore whichever features they like or see as most useful.

Originally, there was the SFZ 1.0 standard, made by a fellow named René Ceballos, as a new standard for open, easily-edited instruments. All previous instrument formats, including the very popular Soundfont (i.e. '.sf2') format, the fledgling proprietary Kontakt (.nki) format, and all the older proprietary formats associated with hardware (Ensoniq, E-mu, Roland, Korg, Kurzweil, Yamaha, etc.) were difficult to edit without the use of specialized tools and advanced knowledge.

Rene's idea was simple but quite ingenious: make a solidly future-proof format which requires nothing more than a text editor and very basic scripting knowledge to create. He designed the basic standard to be extremely robust and flexible, while at the same time compact and very concise- with only a few dozen key opcodes, one can create just about any control system or feature set imaginable. Better yet, being a simple and open standard, SFZ proved to be easy to add to samplers.

However, that is where things started to get tricky. In the beginning, both Plogue and Cakewalk showed interest in the format. Cakewalk more or less considered themselves the stewards of the format until their bankruptcy last year, however Plogue, working with Garritan, created their own set of opcodes as for their ARIA Engine to allow the extended behavior they desired, ignoring many of the opcodes that Cakewalk added to their "SFZ 2.0" standard for the extended behaviors THEY desired! The Plogue/Garritan branch is often called "SFZ 2.0 with ARIA Extensions", although it doesn't comply completely with Cakewalk's "SFZ 2.0", as defined in Simon Cann's book on the subject... at least not yet.

Then there are the many other samplers which have partial SFZ support, such as LinuxSampler. There are even some samplers out there which only support maybe a dozen of the ~200 original opcodes from SFZ 1.0. The problem is, despite being fairly simple conceptually, SFZ 1.0 still has some opcodes which require pretty advanced programming in the backend to make work, so for many developers who use SFZ partially, it is a matter of implementing SFZ support for only those features which already exist, are most useful, or are easiest to add. For other cases, it is merely designed as an easy way to save or import basic velocity and key mappings. Without a central authority to demand compatibility to a core standard through control of licenses or other means, it is entirely up to individual developers.

The ARIA Engine, on the other hand, and by extension its two end user forms, 'ARIA Player' and 'Sforzando Player', are thus the two most widely-supporting player options out there. Not only do Sforzando and ARIA completely support SFZ 1.0 opcodes, they also have a good chunk of SFZ 2.0 and then all of the ARIA Extensions. To the best of my knowledge, the only other player with complete SFZ 1.0 compliance (aside from the defunct Cakewalk SFZ-based samplers) was Rene's own homebrew player, rgc: sfz (or was it sfz:rgc?). LinuxSampler comes in third place for compliance, I think, though it is still missing some SFZ 1.0 opcodes, which is the reason those instruments are silent in LinuxSampler.

Wait a minute: the strings work but not the brass? SSO brass has velocity controlled low-pass filters to simulate dynamic layers, so maybe that's what's causing this. Try disabling the LPF in the sfz files to see if that solves the problem.

(05-23-2019, 11:56 AM)Mattias Westlund Wrote: [ -> ]Wait a minute: the strings work but not the brass? SSO brass has velocity controlled low-pass filters to simulate dynamic layers, so maybe that's what's causing this. Try disabling the LPF in the sfz files to see if that solves the problem.

Is this right place (in red)

// ------------------------------
//  Sonatina Symphonic Orchestra
// ------------------------------
//         Bass Trombone
// ------------------------------

<group>
ampeg_release=0.600
fil_veltrack=11000
// fil_type=lpf_2p
cutoff=120

Brass - Bass Trombone Solo (Failed to load instrument!)
Brass - Bass Trombone Solo (looped) works
Brass - Bass Trombone Solo (looped, decay) works
Brass - Bass Trombone Solo KS (Failed to load instrument!)

Yes, that's it. I would try and disable all the filter opcodes (fil_veltrack and cutoff too) to be on the safe side. As for instruments not loading, that is a separate issue. I seem to remember something about the file paths in some SSO files being lower case while the actual sample folders have upper case letters. This is not an issue on Windows where SSO was created, but on a case sensitive OS like Linux it is. So you need to make sure that the files that won't load have the correct paths in them.