On Sat, 2012-03-24 at 20:58 +0000, Aurélien Leblond wrote:
:) Just makin' sure.
It's easy to screw up if you're not working within a framework that
avoids it. I was just trying to stress that there's a more fundamental
problem here than getting the cursor position being a bit too slow.
> Create a fairly simply GUI that queries the mouse position, and get
That'll do. As long as all the communication happens via ports these
problems are impossible. Some kind of event might be needed for
anything more fancy, but for a couple of numbers KISS with control
(Historical note, it's only to accommodate porting existing plugins from
certain broken proprietary APIs that the facility to directly access the
plugin exists at all. I should probably put some loud disclaimers in
the relevant extensions to explain that actually using them is a
terrible idea intended as a last resort)
> If I'm not wrong, that should dissociate GUI/plugin. In fact it
> (by the way you are completely right, I'm learning audio dev as I go
Took me a while to figure out (the hard way) that the usual "la de da
direct access to everything" approach is an awful idea for audio.
I've since become more or less completely convinced that anything but an
event queue to and from your engine is wrong. Show me a program not
built that way, and I'll show you a program that's probably not
real-time safe :)
Linux-audio-dev mailing list