@jofemodo Thank you for the 2109 0921 update! Here is my first comparison of Sfizz and Linuxsampler.
I used the Pi 4 headphone out into a Focusrite Scarlett 18i20 2nd generation into Quicktime m4a into Logic exported to mp3 (that was a mouthful…)
My test is a Brass sfz file that has CC1 applied to pitch LFO, CC2 applied to Filter and Amp LFO, and CC74 tied to filter cutoff.
I used a 2 pole filter, 1200 hz cutoff, cc74 depth of 9600 and filter/amp lfo depth on cc2 of 200.
Using the 2109 release I had to increase the alsamixer gain to 0db to get a good sound level. In the stable version (d852c8f) the mixer output level is -4.5 db. Both synth volumes were 96.
Like Linuxsampler, Sfizz also recognizes coded controllers - you can hard code ccs into your sfz file.
Here is the audio using 2109 Linuxsampler:
Here is similar audio using 2109 Sfizz:
Here is the audio from the Linuxsampler stable:
The big differences are the filter cutoff depth and the Amp LFO depth.
We still need to gain stage the two synths as well.
My next test will load about 750 meg of sfzs across 9 Midi Channels.
Each sfz player supports a subset of the protocol’s opcodes. If you have a sample set that uses an opcode that you need but is only supported by one of the engines, then you must use that engine. You can look at their respective websites to find out more and there have been some comparison tables drawn.
I am using Linuxsampler for our new clip launcher (in dev) because it is the only one that will continue to play if you change its config file which I need for this purpose. If not, I might have used a simpler engine. I only need a few opcodes.
Is is somehow possible to get some output (errorlogging would be fine) from Linuxsampler? It sometimes does not play a very simple sfz without even the slightest indication why. It would be very handy if there was some kind of (even minimal) feedback. Sfizz isn’t too picky, but the number of concurrent engines is limited, so sometimes I like to split the sfz’s between the two.
To do some test I tried to load in Linuxsampler a SFZ user sample (Matt’s Fender Rhodes): after clicking on the sample name nothing happens.
If others have same behavior I’ll open a ticket
I don’t have the machine to test, but I recall from half a year ago that linuxsampler was sometimes picky with sfz that had the samples in subfolders (don’t recall if the default_path opcode was the problem or the solution) but it worked after copying the samples to the sfz root folder and edit the sfz accordingly.
That is a good suggestion, but it is not as easy as it sounds.
There is no decent Debian package and the most recent (and stable) Windows package does not work ( “procedure entry point could not be located” for all items ).
It seems there is a robot that faithfully produces a broken version every month.
The forum is closed and points to a mailinglist where you can subscribe. The subscription process is broken so you can’t subscribe…
All in all it looks like Linuxsampler is abandonware.
So instead of complaining that it doesn’t work as we want, we should be thankful that the Zynthian devs managed to get it working at all
kind regards,
Hans.
ps.
Found a working version (linuxsampler_20240124_setup.exe) and will try to use it for debugging.
Will do, but can take a while. I’m now trying to make a ribbon controller. Not a ‘touch keyboard’ with fixed notes, but one that generates a sliding pitch relative to the last played note. Like on a CS80
I know, that is a bit (or a lot) overconfident, but without challenge it’s no fun.
Linuxsampler is a pain point because of it’s license. It says it is GPL but then adds a clause saying it isn’t for commercial use. This means it isn’t GPL. The clause is also vague, does it mean I can’t charge for music made with Linuxsampler? Does it mean if you buy a Zynthian kit it shouldn’t be provided but if you build your own you can install it? We don’t know, but the liability is that the code owner could appear and start sueing.
All of this, and the lack of upstream development, means that no-one wants to touch Linusampler with a barge pole. It’s one of the reasons we have Sfizz at all.
Exactly, so what licence is it published under? There’s the rub. It’s proprietary. This is why distros like Debian and Fedora don’t want to package it in their main repos.
