MuSE crash if Linuxsampler loads SFZ?

[dailybug2]

I'm using MusE compiled from recent GIT sources and Linuxsampler also compiled from recent sources on Ubuntu-18.04.

Linuxsampler (LV2 plugin) works fine if a .gig file is loaded into Linuxsampler with qsampler. But MusE crashes instantaneously if a .sfz is just loaded into LS. Is this a known bug, or am I doing something wrong?

Btw; SFZ seems to be a really odd format; the samples have to be present outside the .sfz:

./Wurlitzer.sfz
./samples/wurly_el_piano up122_b0.wav
./samples/wurly_el_piano up127_c#4.wav
./samples/wurly_el_piano up122_a3.wav
./samples/wurly_el_piano up103_c#5.wav
./samples/wurly_el_piano up127_d#1.wav
./samples/wurly_el_piano up32_g1.wav
...

Is this really true?!

br
Wolf (I'm not a bug!)

[Tim E. Real]

Hi. I have it working right now with a random sfz I found "plucked_piano_strings/piano-strings-finger-plucked.sfz"
Works for me OK so far.

Be sure to use recent (~November) releases of lv2, lilv, and sord etc. especially lilv. Some major fixes were done.

[dailybug2]

OK, thanx a lot. Perhaps I have an illegal mix of recent (compiled) packets and outdated packets from the Ubuntu distro.
Soon I will switch to Ubuntu 20.04-LTS and then I'll do the big cleanup, recompiling everything.

[Tim E. Real]

The 'order' of operations may be important here.

Be sure to start MusE first, then load the LV2 LS plugin, then start QSampler and load an instrument.

If QSampler is started before MusE, MusE will freeze requiring stopping LS or killing it.
I think other apps behave the same, at least QTractor does here.

[dailybug2]

Yes, I'm aware of the startup order. Btw; Linuxsampler works fine with .gig instruments as LV2 a plugin. It also is possible to start Linuxsampler externally and just trigger it via MIDI from MuSE. This way the SFZs also work fine. But this is nothing good for - no effects, poor handling.

I tried to compile liblilv which outdated on Ubuntu-18.04 and I ran in a fractal tree of other libs to be updated first. I stopped after the 2nd one. Conclusion: Ubuntu-18.04-LTS is dead (for MusE+LS), definitely have to switch to 20.04-LTS. As I'm using Xubuntu which is not out yet, I still have to wait some days. I will drop a message here once I have tested this on 20.04.

[kybos]

Just tested with Mint 19.3 (which is based on ubuntu 18.04).
No crash here, everything working as expected (SFZ Salamander piano).

MusE: Current master
LinuxSampler: 2.1.1 (from kxstudio)
Everything else from the distro (qsampler, liblilv, liblscp...).

[spamatica]

I sometimes use linuxsampler and have not seen any problems recently.
linuxsampler has a VST plugin too I believe, maybe try that?

Btw; SFZ seems to be a really odd format; the samples have to be present outside the .sfz:

./Wurlitzer.sfz
./samples/wurly_el_piano up122_b0.wav
./samples/wurly_el_piano up127_c#4.wav
./samples/wurly_el_piano up122_a3.wav
./samples/wurly_el_piano up103_c#5.wav
./samples/wurly_el_piano up127_d#1.wav
./samples/wurly_el_piano up32_g1.wav
...

Is this really true?!

I can see this may seem odd but it is actually a very good design as it allows for easy editing if something is not quite right in the sfz.
If they supported the same format in a zip-file that might look better (maybe they do)

[dailybug2]

In the meantime, Xubuntu-20.04 is out and I compiled MuSE and Linuxsampler within a fresh installation. No show-stopper encountered. The MusE packet from Ubuntu is outdated once again in respect to the GIT repository...

I did not actually use MusE, just some quick tests. And, yes, Linuxsampler can be used as an LV2 plugin within MusE, without the crashes mentioned before.

I logged all the commands used for build and installation, but at this instant I do not have the time to make them presentable. I will provide them here soon for the ones who are not familiar with the compilation of Linux packets but do want to have the recent fixes and functions from the GIT repository - highly recommended!

Nice weather outside ... bye

[tseaver]

@dailybug2 wrote:
Btw; SFZ seems to be a really odd format; the samples have to be present outside the .sfz:

The design is quite deliberate, and allows for a huge improvement over all-in-one SF2 files: you can have multiple instruments which use the same samples, each defined in its own SFZ text file, allowing others to re-use the original samplist's work.