[LV2] worker thread question

[hermann meyer]

Am 27.12.2012 22:27, schrieb David Robillard:
> On Tue, 2012-12-25 at 07:06 +0100, hermann meyer wrote:
>> Hi
>> New to the list, so first hello to all.
>>
>> I come here with a question about the worker thread extension, it's:
>> How could I ensure that the worker request will also be send from
>> internal host UI's ?
>> Say, I have a GUI element that send a message to the engine control
>> port, to fire up a work sequence, how could I let the host known that
>> this special UI controller do that, and that his internal UI must do the
>> same to ensure all work like suspected?
>> Even, if the URI in use is a self defined one?
> I am not quite sure what you are asking here, but perhaps this will
> help:
>
> Everything in the UI API has to do with a single thread.  The worker
> extension is an API for the plugin, it has nothing to do with the UI.
> It is best to think of what you need to do from the simple perspective
> of the plugin (which talks to the world via ports), or things just get
> confused.
>
> It sounds like you are talking about sending messages to the plugin from
> the UI and you want these messages processed in the worker?  To do this
> you use ports normally, all ports are processed in the same thread, i.e.
> the process thread that calls run().
>
> If you want to perform actions based on a message that are not
> real-time, you receive it in the real-time process thread, then send a
> request to the worker from run() to process it in the worker callback.
> This is the main point of the worker extension.
>
> The eg-sampler example plugin does exactly this.  If you want to do
> non-real-time things in response to messages from a UI, do what
> eg-sampler does.
>
> -dr
>
Thanks David

. . but you will imagine that the design from the eg-sampler example 
plugin is exactly were I'm talking about (and is what I'm tried first) . 
The UI send a message to run() which in-turn fire up a worker thread. 
The internal UI from the host didn't know about that and will not work. 
So, the internal host UI is brocken.

Now I have some controllers which presented to the user as simple knobs, 
like all other controllers as well, but those knobs control some 
convolvers which need a impdata.update when the controller is moved.
Clearly that is a job for the worker-thread.
For the record,I have no problem to get it all work, that isn't what I'm 
ask about, my question is related to the UI->host->engine communication, 
which seems to me, break the internal host UI.

A way to handle this issue is to watch the state of those convolver 
controllers (in the engine) and fire a work thread when needed. This way 
the internal UI from the host work as well.

Best way to handle this would be a watch thread (in the engine space) 
were (controller) state changes could be fetched.
Imagine that it could come to plug-ins which need to watch a couple of 
states, and it isn't nice by design to watch them in the rt-thread.


regards
hermann