be1 / qliquidsfz

Qt graphical user interface to the liquidsfz library, an SFZ synth player.

• 👋 Hi, I’m @be1
• 👀 I’m interested in music
• 💞️ I’m looking for collaborators for Redrose.
• 📫 How to reach me: my email is [email protected]

qliquidsfz's Issues

Error svnversion: not found

Devuan Daedalus
libliquid-dev:amd64 (1.5.0-2)
qttools5-dev-tools (5.15.8-2)

When issuing the command:
$qmake -config release
sh: 1: svnversion: not found

Am I missing something?

Progress not thread safe

I think the code is not really thread safe which could cause random crashes which might be hard to reproduce.

    this->synth.set_progress_function([this](double percent) {
       int p = (int) percent;
       this->ui->statusBar->showMessage(QString::number(p) + "%");
    }); 

The problem here is that the progress function will probably be called from the loader thread. The statusBar object however lives in the Qt main thread. So accessing it directly could cause crashes.

I've seen that other code you use emits a signal and accesses the ui widgets in the signal handler. If I understand the Qt documentation directly, this should avoid this type of problem, because a queue will be used to handle the signal in the Qt main thread.

LiquidSFZ::Synth usage not thread safe

If you use a LiquidSFZ::Synth object, you need to ensure that only one thread at a time accesses it. Internally, no locking is performed to ensure this. So the problem with your implementation right now is that two threads can and do use the synth instance from different threads at the same time, namely

• int LiquidMainWindow::process(jack_nframes_t nframes)
• void SFZLoader::run()

As the process function is called in the jack thread and load can run for a long time in the loader thread, LiquidSFZ::Synth functions could be executed at the same time, for instance Synth::load and Synth::process, if you are unlucky this causes a crash.

There are probably multiple ways to fix this. Here is one:

I'd suggest using a mutex in the process function and in the loader thread to protect the synth instance. In a naive implementation this would stall the jack thread during load, which is unacceptable. So instead of locking the mutex during process(), I'd recommend using tryLock(). If you don't get the lock in process(), simply write a block of zero samples and return immediately.