[LV2] worker thread question
brummer- at web.de
Sat Dec 29 22:49:30 PST 2012
Am 30.12.2012 07:02, schrieb 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
>>>> a massive set of problems for little to no benefit. It is
>>>> 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
>>>> a lot of thought and experimentation. It is this way for good
>>>> 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.
>>> 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
>>> 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
> 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.
Ah,:-[ okay, I get this point and will move the schedule call to run.
> 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
> 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
> 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 :)
> Devel mailing list
> Devel at lists.lv2plug.in
More information about the Devel