24 Mar
2012
24 Mar
'12
7:50 p.m.
Hello,
I have been coding the porting of the AMS internal modules to LV2
plugins using the Lv2-C++-Tools.
The more I'm progressing, the more I am wondering if there are any
limitations involved in using this library, especially these days
where a lot of new features are being added to the Lv2 Extensions.
Maybe this isn't really a technical argument, but I really don't like
these libraries as they are because the pkg-config names are really
generic and impossible to find, and make them seem like some kind of
official "LV2 plugin library" or something.
They really need a proper, somewhat unique, name.
For example, I am coding a plugin that output the
position of the
mouse cursor as two control ports (handy to develop a kind of theremin
synth).
Getting the cursor position from the X Library is an expensive
operation, and the new Worker Extension seems perfect for the job, but
I can't figure out if somehow it is compatible or not with the
Lv2-C++-Tools.
Whoah now! The worker extension is a plugin-side thing, not UI, and
there is an EXTREMELY small chance that you actually want to be doing
multi-threaded things in your UI code. Trust me. The most
obvious pros of using Lv2-C++-Tools is its simplicity.
Porting an AMS module takes only 20 to 30 minutes with it, while doing
it without the help of the library takes much more time and is way
more tedious.
(I am much more confortable coding in C++ than C, but the question
deserves to be asked, am I doing something wrong here that I find it
way more difficult to code without the help of Lv2-C++-Tools?)
Personally I think a good C++ wrapper header(s) would be a good thing to
have, but I don't really get the point of the rest of it.
Also not sure the kinda crazy template hackery is worth it... 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.
But that's my 2 cents!
(I became a software developer because I'm extremely lazy, and I like
computers to do the monkey work for me!)
Cheers,
-dr
Aurélien
24 Mar
24 Mar
8:30 p.m.
New subject: LV2-C++-Tools
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
9:58 p.m.
New subject: LV2-C++-Tools
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!
10:13 p.m.
New subject: LV2-C++-Tools
On Sat, 2012-03-24 at 20:58 +0000, Aurélien Leblond wrote:
[...]
Of course you can't do X things in the audio
thread!!! Holy crap!
Ha! How can I be so stupid!
Ok, I get it now (well I hope anyway).
:) 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
the GUI to feed that into two control inputs of the plugin itself.
The plugin would simply take the value of those 2 control input, and
feed that into two audio outputs (or VC outputs, for that matter)...
And obviously, the two would be conpletely separated, the way it
already is for other plugin: audio processing on one side, GUI on the
other....
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
ports.
(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
wouldn't be that different than how a usual plugin works now, but
instead of being let say a combo box changing the controls value of
the plugin, it's simply the position of the mouse cursor.
Yep
(by the way you are completely right, I'm learning
audio dev as I go
in this project! that does explain my confusions sometimes...)
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 :)
-dr
11:19 p.m.
New subject: LV2-C++-Tools
On Sat, Mar 24, 2012 at 4:58 PM, Aurélien Leblond <blablack(a)gmail.com> wrote:
(by the way you are completely right, I'm learning
audio dev as I go
in this project! that does explain my confusions sometimes...)
not just audio development.
it is slowly becoming more and more true that applications with
attempt to interact with the windowing system from anything other than
"the main GUI thread" (variously defined, depending on the windowing
system) will likely have issues. this is particularly true on windows,
but is becoming more true on X11 systems and even on OS X, its very
important to use an very particular API.
so "create a thread that polls for mouse position" is a no-no, whether
your app is an audio app or not.
11:35 p.m.
New subject: LV2-C++-Tools
On Sat, 2012-03-24 at 18:19 -0400, Paul Davis wrote:
On Sat, Mar 24, 2012 at 4:58 PM, Aurélien Leblond
<blablack(a)gmail.com> wrote:
"Shared data plus locking" is a pretty crap model in general, really.
When people talk about all the complications that threads introduce,
they're really talking about this. Shared mutable state is the cancer
of multi-threaded programming.
Eventually, we (as in, the software world) are going to have to move to
more appropriate models if we want to be able to feasibly produce
software for increasingly parallel machines.
(Drawing to a screen isn't something you gain anything by making
parallel anyway, I submit that this isn't a flaw of windowing toolkits
but something you just shouldn't be doing anyway)
-dr
(by the way you are completely right, I'm
learning audio dev as I go
in this project! that does explain my confusions sometimes...)
not just audio development.
it is slowly becoming more and more true that applications with
attempt to interact with the windowing system from anything other than
"the main GUI thread" (variously defined, depending on the windowing
system) will likely have issues. this is particularly true on windows,
but is becoming more true on X11 systems and even on OS X, its very
important to use an very particular API.
so "create a thread that polls for mouse position" is a no-no, whether
your app is an audio app or not. 
25 Mar
25 Mar
5:42 p.m.
New subject: LV2-C++-Tools
On Sat, Mar 24, 2012 at 10:34 PM, David Robillard <d(a)drobilla.net> wrote:
"Shared data plus locking" is a pretty crap
model in general, really.
When people talk about all the complications that threads introduce,
they're really talking about this. Shared mutable state is the cancer
of multi-threaded programming.
I'm very interested in the various "paradigms" or patterns of programming
RT safe applications. I've done a bit of reading on the topic, and am
concidering doing my Final Year project based around the concept of
multi-threaded RT safe data storage / retrieval & inter thread
communication.
Idea's for further research, books, papers etc etc all welcome. At this
time I'm thinking about a good title for the paper, and what exactly would
be most interesting to focus on having a perspective as an LAD... :)
-Harry
24 Mar
24 Mar
8:52 p.m.
New subject: LV2-C++-Tools
On Sat, Mar 24, 2012 at 06:50:10PM +0000, Aurélien Leblond wrote:
@Fons: I phrased it wrong the first time :) by
expensive, I meant that
my poor design was creating a lot of xruns :)
As Dave has already pointer out, a plugin - at least the DSP
part of it - is not the proper place to do anything X.
It would probably fairly easy for the host to provide X,Y on
two control ports, just as it provides the Jack ports, MIDI
interfaces etc.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
9:14 p.m.
New subject: LV2-C++-Tools
On Sat, Mar 24, 2012 at 12:52 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sat, Mar 24, 2012 at 06:50:10PM +0000, Aurélien
Leblond wrote:
Just trying to be the voice of reason here... There are plenty of
tools out there to convert joystick/mouse/whatever position into
sensible MIDI messages. I've even written a few myself:
http://lsmi-all.sf.net
IMHO, one should never need to deal with input devices in a plugin.
And, yes, the host could also provide this information, but I don't
think it's the hosts responsibility to be providing the plugin any
information that the user didn't explicitly request be delivered to
the plugin (e.g. by clicking on an XY Pad control and moving the
cursor position).
Anyway, if you ever want to be able to record and playback this
theremin sound, MIDI is the way to go.
@Fons: I phrased it wrong the first time :) by
expensive, I meant that
my poor design was creating a lot of xruns :)
As Dave has already pointer out, a plugin - at least the DSP
part of it - is not the proper place to do anything X.
It would probably fairly easy for the host to provide X,Y on
two control ports, just as it provides the Jack ports, MIDI
interfaces etc.
9:38 p.m.
New subject: LV2-C++-Tools
On Sat, Mar 24, 2012 at 01:14:55PM -0700, J. Liles wrote:
IMHO, one should never need to deal with input devices
in a plugin.
And, yes, the host could also provide this information, but I don't
think it's the hosts responsibility to be providing the plugin any
information that the user didn't explicitly request be delivered to
the plugin (e.g. by clicking on an XY Pad control and moving the
cursor position).
The user 'requests' this information by connecting the X,Y CV ports
provided by the host to the CV inputs of some module(s). Just as one
would input audio.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
4621
days inactive
4622
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
6 participants
participants (6)
-
Aurélien Leblond -
David Robillard -
Fons Adriaensen -
Harry van Haaren -
J. Liles -
Paul Davis