[LV2] worker thread question

[hermann meyer]

Am 30.12.2012 02:37, schrieb Robin Gareus:
> On 12/29/2012 09:16 PM, hermann meyer wrote:
>> Am 29.12.2012 20:35, schrieb David Robillard:
>>> As I said, this was tried, and it was much, much more complex and raises
>>> a massive set of problems for little to no benefit.  It is particularly
>>> tedious to implement on the host side, which is why nobody implemented
>>> it.  Doing I/O in run() is a deliberate design decision arrived at after
>>> a lot of thought and experimentation.  It is this way for good reasons.
>>>
>>> In short, you're breaking very important rules in order to "optimize"
>>> away nothing significant, with a result that's much more complicated,
>>> error prone, and slow than the simple and correct solution.
>>>
>>> This code is broken and needs to be fixed.  Do not break the threading
>>> rules of the API.  Seriously.
>>>
>>> -dr
>>>
>> sadly I notice that you didn't understand the need of non-rt dsp
>> processing with user interaction in a plug-in. To bad :-(
>> I guess that you makes thinks more complicated then they really are.
>> That isn't what I understand under a Open spec. Your assumptions leads
>> to no way for implement what I need to make my plugs work with your
>> bless, so be it. I have tried to find a way for communication about that
>> with you, but it seems to me there isn't.
> That's what I sometimes like about AU or even VST. There's no
> discussions about *but we can make it work by hacking and circumventing
> the spec* or the *spec should be changed*..
Morning all

well, I didn't ask for hacking the spec, or change it, it was just my 
answer to the first reactions on my source. Actual I can make it work 
with the spec's which are there.

>> Maybe you tried out my work, before you totally negate it.
> My thoughts about the watch_thread() are unprintable. That's incorrect
> plugin design. Accessing 'self->schedule' from this context is just wrong.
Could you explain me why? I call a thread from a other thread, so under 
which circumstances it mater from which thread I call it? If I get what 
you mean here, I could truly move this call to run, just using a 
sem_post. But it seems to me foolish to do so.

I watch port values from a pointer, which is a private member of my 
class, as well as the thread I use to watch it, as well as the function 
for run(). So could you explain to me why that could influence the host, 
when I watch it from a other thread then run()? I didn't need the port 
values in run(), I just need them in "a worker thread". I could avoid to 
use the worker at all, and use my own, but I understand from the 
discussion about the convolver.IR on LAD, that this is wished to be 
avoid, ad I understand why. For the very same reason I come here and ask 
for the watch tread approve. It is negated here, okay, but I didn't get 
a reason for why "I" shouldn’t use it on my own.

I really like to find a way which satisfy all of us, but just say "that 
didn't work" or "this is wrong", wouldn't help or lead to a conclusion.

Again, here in this example, I just check for two ports values, and it 
already makes a diff in the CPU usage from the rt-thread and the overall 
CPU usage. When I'm ready with what I have I mind, that could become 
more then 20. ports which I need to watch. It is clearly to avoid to do 
that in the rt-context. Again, I never try to write to the mem the 
pointers point to, even if they point to NULL, it wouldn't harm. So why 
the hell it should harm a host when I watch them from were ever?

>> That it works stable, have nothing to do with luck.
> It certainly is luck. It will probably work in 99.9% of all cases. but
> certainly not 100%.

Sorry, please show me a example were it didn't work, even if it is 
theoretical, . .
>
> Otherwise: nice work! I'm looking forward to a gx LV2 plugin. You went
> to so many troubles to make guitarix outstanding software, why not go
> the last mile too and make it a proper LV2 plugin?
I'm just started this experiment.
we have defined our own plug-in specs for guitarix long ago, we pass the 
port values even as parameters from the UI to the engine and visa-verse.

As you may notice I have just release the first LV2 amps from guitarix, 
well, they are without the watch thread approach, and they are far more 
simple then what I have in mind.


> Sure, feel free to curse the specs, anytime :) Yes, they could have been
> written to make your use-case easier. Yes, they suck. but no: LV2 _does_
> allow for non-dsp realtime and non-realtime work. ..and it sucks way
> less than most similar specs. I'm sure you must have cursed at gtk or
> libx11 or even jack at some point during gx development and solved
> things properly at that end. Just bite the bullet and include LV2 in
> that list of /cursed/ frameworks :)
>
> 2c,
> robin