[LV2] worker thread question

Robin Gareus robin at gareus.org
Sat Dec 29 17:37:24 PST 2012


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*..

> 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.

> 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%.

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?

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



More information about the Devel mailing list