Problem during export of composition

[ApexSoundMusic]

Hi again,

SO I will try the test described in the previous post. I'll let you know the results.

I've figured something new also; I also tested the G8tor synth + 1 automation curve in a brand new project. This one only consisting of that 1 synth and automation. That one exported succesfully! So I'm not sure if it's purely the VST... Maybe it is related to something else within the project....

Anyway, besides the before mentioned test I should note that I found a way around the issue by automating effect plugins instead of the G8tor parameters, so for now the issue isn't holding me up anymore.

@Big Tick, I'll keep an eye out if I can reproduce it or if I can cut down the project untill there is only G8tor left (and if the issue then persists...)

[ApexSoundMusic]

To exclude any threading issues: ApexSoundMusic pls go into MuLab Audio Setup and set Num Audio Processor Threads to 1. Then do that same export that repeatedly hangs. Does it still hang when only using a single audio processor thread?

I encountered the issue again with a newer version of the project. In this case, all the automation from the G8tor plugin was removed so it couldn't have been that same cause.
Then I tried out your suggestion of setting the number of audio processing threads to 1 and exported again. This time without issues! So just now I went back to the old backup project which I saved to test later on and first did a new render with the old settings, to verify that the problem still persisted, which it did of course. Then on this instance of the project I also set the thread number to 1 and exported the composition, again without a problem!

So it might indeed be a threading issue, just as you said. What should I do to prevent this and export with 4 threads? Or are there any other steps to take or settings to be changed?

Thanks again!

[mutools]

Please try this:

1) Start MuLab 8.6.9 = latest version
2) Make sure multi-core enabled to 4 threads, your standard setup.
If you had to change anything to reset to 4 process threads then quit & restart MuLab so to ensure you started MuLab with multi-core enabled.
3) Open that problematic project with G8tor and do the export. It crashes, right?
4) Restart MuLab (still with multi-core enabled) and again load that same project as in step 3.
5) Now before exporting simply replace all instances of G8tor by TAL NoiseMaker. (right-click G8tor -> Replace -> VST -> Tal NoiseMaker)
6) Now again export to audio file.

Does it crash?

[ApexSoundMusic]

Please try this:

1) Start MuLab 8.6.9 = latest version
2) Make sure multi-core enabled to 4 threads, your standard setup.
If you had to change anything to reset to 4 process threads then quit & restart MuLab so to ensure you started MuLab with multi-core enabled.
3) Open that problematic project with G8tor and do the export. It crashes, right?
4) Restart MuLab (still with multi-core enabled) and again load that same project as in step 3.
5) Now before exporting simply replace all instances of G8tor by TAL NoiseMaker. (right-click G8tor -> Replace -> VST -> Tal NoiseMaker)
6) Now again export to audio file.

Does it crash?

I followed the steps you described. First steps 1 to 3, and indeed (as previously verified) it crashes. Then steps 4-6 and the export of the project was indeed successfull. So I think I thus far have verified that:
- I can export the project with the G8tor plugin enabled but only when setting the audio processing engine to 1 thread
- I cannot export the above scenario with multiple (or at least 4) threads
- I can export the exact same project, with 4 threads, when replacing G8tor with TAL noisemaker
- I haven't, however, reassigned the existing G8tor automation curves in the test project by assigning them to TAL Noisemaker parameters. But I'd also note that, in a newer version of that same project the export also crashed without any automation on G8tor being present within it.

[mutools]

So is it correct to conclude that the crashing only occurs when using G8tor?
If that's the case then BigTick can you pls further zoom in on this issue.
As Apex reports it does seem to be related to multi-threading, but as it only happens with G8tor it seems to be an issue on plugin side. If you need info from me, let me know. (here or via email, as you prefer)

[Big Tick]

well it would be useful to know what happens when you export with multi-threading on, and how different it is than regular playback. I'm not sure why it would fail during export, but work fine during playback.

[mutools]

There is no real difference between processing based on the main audio thread or based on the GUI thread. The only difference i see is that, when exporting, one of the process threads has a lower thread priority because it's the main GUI thread instead of the main Asio thread.

[mutools]

Just a quick thought: Apex, could it be that the issue only occurs when using multiple instances of G8tor? Or did the export crash also occur when using only 1 single instance of G8tor?

[Big Tick]

There is no real difference between processing based on the main audio thread or based on the GUI thread. The only difference i see is that, when exporting, one of the process threads has a lower thread priority because it's the main GUI thread instead of the main Asio thread.

Oh wait, so you are calling audio rendering from the main GUI thread in that case ? That will definitely not play nice with G8TR, and many other plugins.

[mutools]

Oh wait, so you are calling audio rendering from the main GUI thread in that case?

Sure. What's wrong with that?

That will definitely not play nice with G8TR.

Why does this cause an issue in G8TR?

and many other plugins.

Which ones?
I did not notice any related issue in the many years that this specific system is working.

Why would calling processReplacing from the GUI thread (eg. in case of offline rendering) be a violation against the VST 2 SDK?

I can ensure you that no VST plugin instance process function is called from 2 threads at the same time.

[Big Tick]

{quote]

That will definitely not play nice with G8TR.

Why does this cause an issue in G8TR?[/quote]

Without getting into too much details, the audio <-> ui message queues will get really confused if the audio and UI threads are the same thing.

[dakkra]

Typically in my experience, the GUI thread always runs independently from processing threads. This is usually done to ensure that GUI responsiveness, animations, and interactivity remain in good status regardless of the processing state. Communication between worker threads and the GUI thread is done via events, and those events are only to trigger/add tasks on queues. That way threads are not waiting on each other to finish (and also prevents deadlock). Of course in a DAW some form of GUI thread waiting has to be done to show the "current" state of DSP (spectrum analyzers, oscilloscopes, level meters, etc...) but that typically shouldn't cause other threads outside of the GUI to wait.

One again, this is just my experience with software development. I am admittedly quite young and new to this field, but the model/paradigm in my experience has always been GUI thread only talks via events, and only waits when necessary. No processing threads should have waits on the GUI, and should only receive tasks from the GUI thread, meaning no audio processing on the GUI thread.

[mutools]

Without getting into too much details, the audio <-> ui message queues will get really confused if the audio and UI threads are the same thing.

With all sincere respect, but i think that's an issue on your plug side. Queue syncing should normally be possible with proper thread locks. And it's also possible to detect whether the calling thread is the GUI thread and handle accordingly. I have to do that too all the time with MUX Plugin as i encountered many different and unexpected hosts cases, even cases where i doubted it's valid wrt the VST 2 SDK eg calling setParameterAutomated from a process thread, but i implemented the necessary code to handle it.

[mutools]

@Dakkra, that's a way to do it. But i think it's not the right way to rely on it, especially if it's about software made by independent devs and using an SDK with lots of vague definitions.

I would be surprised if MuLab would be the only app calling processReplacing from the GUI thread in case of Export/Render. I'm not only talking about host DAWs but also audio and video editors etc.

[Big Tick]

Without getting into too much details, the audio <-> ui message queues will get really confused if the audio and UI threads are the same thing.

With all sincere respect, but i think that's an issue on your plug side. Queue syncing should normally be possible with proper thread locks. And it's also possible to detect whether the calling thread is the GUI thread and handle accordingly. I have to do that too all the time with MUX Plugin as i encountered many different and unexpected hosts cases, even cases where i doubted it's valid wrt the VST 2 SDK eg calling setParameterAutomated from a process thread, but i implemented the necessary code to handle it.

Well we went through a lot of trouble just to eliminate locks
The VST SDK never specified it unfortunately. So yes it is technically correct (but in my book, a little rude) to call audio rendering from the UI thread.

We only got that issue with MuLab so far so I assume the other DAWs don't call audio rendering on the UI thread.