Design for host that needs to support 2 threads rendering their own output from the same MIDI input?

[stuerp]

I tried to explain my problem in the title but maybe that made it more confusing...

I created a CLAP host that passes all validations of CLAP-Saw-Demo-IMGUI in the following scenario:

Platform: Windows
Thread 1 (UI thread) create the plugin and handle the editor
Thread 2 (Render thread) renders MIDI input to a sample buffer

When a second render thread starts to render the same MIDI input to a file f.e. everything crashes. CLAP-Saw-Demo complains that start_processing() is called twice (which is true, each render thread calls it right before rendering starts).

So, the question is which call does each thread need to make to render its own output?

[baconpaul]

A given instance can only have one audio thread.

So I think what you need to do is either make a second instance to render with state or stop processing on the old audio thread, change your thread checker implementation to change the logical audio thread, and start processing on the other thread.

No claps can render in two threads at once from one instance. The API is a single-logical-audi-thread-per-instance model.

Does that help?

[stuerp]

A given instance can only have one audio thread.

So I think what you need to do is either make a second instance to render with state or stop processing on the old audio thread, change your thread checker implementation to change the logical audio thread, and start processing on the other thread.

No claps can render in two threads at once from one instance. The API is a single-logical-audi-thread-per-instance model.

Does that help?

An instance of what? The host? The plugin? Can you please elaborate?

[defiantnerd]

You're loading the Plugin-DLL.
Then create an instance with factory->create_plugin(..)

You can render this instance in an audio-thread.

You can not call this instance of the plugin from two threads. This is what the error message says!

If you want to render in a second audio-thread (gui+audio1+audio2 = 3 threads), you need to create an additional instance with another call to create_plugin.

Don't forget to destroy both instances at exit.

[stuerp]

Got it, I think. I will need some time to restructure and retest the code. I will report back my results later.

Thx, also to @baconpaul .

[stuerp]

That design works for me. Thank you.

What I don't understand yet is that while the create_plugin() call seems valid on the audio thread. The next calls, init() and activate(), should be on the main thread.

[defiantnerd]

Best is to create and set up the plugin instances in main thread.

When they are activated, let the audio thread take over the processing.

Don't forget to maintain also the UI thread interaction.

[baconpaul]

create plugin isn't marked main thread? Oooh it should be.

[defiantnerd]

This sounds not like a good design for your host. It also sounds like you only instantiate one instance.

You could have two render threads, one instance each. But the error indicates you don't have 2 instances.

[stuerp]

Thank you all for the quick response.

I just tried instantiating a second host specifically for the 2nd render thread but then I run into "must be called on the main thread" issues. I read in previous discussions that there can be many 'main' threads just as long all calls are per instance stay on the same thread. On Windows that excludes any GUI stuff (unless you do thread switching) but that's not a problem.

The scenario I have/need to support is a render thread for audio playback and a second render thread that creates a waveform preview of the completely rendered song. For those of you in the know: foobar2000 / foo_midi / foo_wave_minibar_mod.

[stuerp]

This sounds not like a good design for your host. It also sounds like you only instantiate one instance.

One instance of the host, that is correct. It loads the plugin and does all initialization including activate_plugin(). Thereafter the idea was that each render thread initializes its buffers, start_processing() and process().

[baconpaul]

So you could do this pretty easily I think as follows.

When you go to render

1. On the main thread stream the state of your current instance with get state
2. Create a new instance
3. Set the state on it with set state
4. Make a new thread arbitrarily and render that new instance (never calling create editor)
5. tear down that old instance

That could work pretty well.

Other strategies too but thats the one I would think of as a first approach