On Sat, 2012-03-24 at 18:50 +0000, Aurélien Leblond wrote:
[...]
Although it involves the mouse, what I'm trying to
achieve is not
exactly UI related.
The plugin I have has two output called X and Y.
When the mouse is at the bottom left corner of the screen, X and Y are
equal to 0.
When it's at the top right corner, X and Y are equal to 1.
The design I had in mind was to have a thread on the side that would
query the mouse position every 25ms, especially to avoid having it in
the method processing the sound itself (this create a lot of XRuns
when I do that).
You seem to have some ideas about UIs and plugins that are severely
divorced from reality, at least for LV2 (but any working audio program,
really). I will not mince words here because I think the point isn't
getting across very well:
The UI and plugin are COMPLETELY separate and communicate via ports.
They shouldn't be in the same library, and they might not be in the same
process, or even on the same machine. If anything you do in your UI
could possibly cause XRuns something is VERY DEEPLY WRONG. I hope it is
obvious that the UI and the DSP do not run in the same thread. Saying
things like you want a thread to poll X cursor position to avoid doing
it in the sound processing function is a five-alarm siren and red
flashing WARNING sign that something is WAY off here. Of course you
can't do X things in the audio thread!!! Holy crap!
I am guessing you are using the instance-access extension to get a dirty
pointer to the plugin side (in hosts that support it) - which you
shouldn't be - then using it to commit all sorts of crimes against
Jackmanity. Your problems are a result of deliberately circumventing
the proper way of UI<=>plugin communication which inherently avoids this
kind of thing. If anything on the UI side could be causing XRuns you
have very serious fundamental problems, and trying to add threads to
your UI certainly isn't going to help.
In general, you do not want to be using multiple threads to do X
anything. Trust me, you just don't. It is practically impossible, and
won't actually benefit you anyway.
I strongly suggest you look at your plugin code - not your UI code, your
plugin code - find anything in the run() context that could possibly be
held up AT ALL by UI anything, at all, ever, and kill it with fire. No
plugin with something that fundamentally broken in it will ever work
reliably.
The lv2peg tool makes the development a lot faster.
From my own experience, there is duplication of work by setting up the
input/output/controls in the ttl files, then having to set them up
again in the code of the plugin itself.
lv2peg creates the headers automatically.
Fair enough, I guess, use whatever dev tools you like. Plugins
shouldn't have to depend on a library for any of this, though.
Mainly I just wish the thing had a proper friggin' name to end the
constant barrage of user confusion that causes. "lv2-plugin" and
"lv2-gui" are extremely inappropriate pkg-config names for these things.
-dr