LiquidSFZ device

[swesterfeld]

Here is an implementation of a LiquidSFZ device. This supports .sfz and hydrogen drumkit xml files. This is based on the old BEAST device PR (tim-janik/beast#145).

• The obvious next step would be allowing the user to specify the file using a dialog.
• Loading might want to use an extra thread, so that it doesn't block anything. SFZ files can take some time to load.
• This uses pkg-config to depend on libliquidsfz. In the future we may want to use liquidsfz internal API so probably we may want to build the lib/ dir from the latest liquidsfz release as part of the Anklang build.

[tim-janik]

Here is an implementation of a LiquidSFZ device. This supports .sfz and hydrogen drumkit xml files. This is based on the old BEAST device PR (tim-janik/beast#145).

Ah, great to see work on the sample support front ;-)

* The obvious next step would be allowing the user to specify the file using a dialog.

Yes, since that involves a bunch of GUI code, you should put that on the agenda of a team meeting.

* Loading might want to use an extra thread, so that it doesn't block anything. SFZ files can take some time to load.

Is that something you can add to this PR?
AFAIU, it'd suffice to spawn a std::thread that, once done, enqueues a job into AudioEngine::async_jobs and terminates, right?

It'd be good to have a commit that attempts this to look at as a discussion base.

* This uses pkg-config to depend on libliquidsfz. In the future we may want to use liquidsfz internal API so probably we may want to build the lib/ dir from the latest liquidsfz release as part of the Anklang build.

Is that just a tentative idea, or do you need e to look into this?

[tim-janik]

GUI ideas from a recent discussion:

• Add text property with file-selection capability: *.sfz
• GUI provides file dialog for file selection
• Text property with file name is sent via set_property to engine thread
• The process() function switches to BYPASS and queues load_sfz(filename) into worker thread
• Worker thread signals DONE
• The process() function switches to new instrument

[swesterfeld]

I've added an extra thread for loading the .sfz file now, as discussed. To test this, I use a choice with some hardcoded paths, so the filename property is set in the audio thread, and the audio thread passes a request to the loader thread using the selected path from the choice.

I've also rebased the branch.

As for CC handling: the old version of the code mapped the SFZ-defined CCs to parameters. The new code doesn't do this any more, because the CC values (and labels and defaults) now can change dynamically, depending on the SFZ filename. I've kept the relevant code but disabled it. I suggest we first sort out merging this PR and deal with CCs later on.

[tim-janik]

Since LiquidSFZ adds libsndfile as new dependency, I'm looking into packaging related to it.

Ubuntu Focal (our current base line) ships libsndfile-1.0.28. Note that 1.0.29 introduced OPUS support, 1.0.30 had important bugs fixed and 1.1.0 introduced MP3 support, see here: http://libsndfile.github.io/libsndfile/#history

Does LiquidSFZ support OPUS or MP3 files as SFZ wave files?

[swesterfeld]

Does LiquidSFZ support OPUS or MP3 files as SFZ wave files?

Yes, I just tested it to be sure using libsndfile-1.2.2, both MP3 and OPUS work properly within SFZ files.

[swesterfeld]

Please merge this PR even if the UI for the file dialog is not there yet, as as long as we have string properties, I can use them to work on #29.

[tim-janik]

Please merge this PR even if the UI for the file dialog is not there yet, as as long as we have string properties, I can use them to work on #29.

For the record, I've started merging this, it currently causes some breakage on top of trunk that I need to fix first (make branch-check shows the relevant issues).

[tim-janik]

Thanks again. I am currently pushing the patch series that are needed to use the instrument string field. Your code is already merged as part of that, thus I'm closing this report. We can handle follow up issues via the issue tracker.