2 Feb
2004
2 Feb
'04
3:56 p.m.
Hello.
What is "/dev/shm"? How it is used? "df" shows:
none 62812 0 62812 0% /dev/shm
What about the following idea?
My LADSPA plugin would allocate a segment of shared memory from "/dev/shm".
That is possible because most likely all Linuxes have that device.
Then somehow I create a backdoor for LADSPA controls. The backdoor goes
through the shared memory segment. Finally, I would write an independent
GTK application which provides my own GUI to the plugin.
If one does not use the GTK application, then all what is available
are controls provided by the host.
Regards,
Juhana
4:29 p.m.
Juhana Sadeharju <kouhia(a)nic.funet.fi> writes:
What is "/dev/shm"? How it is used?
"df" shows:
none 62812 0 62812 0% /dev/shm
On many systems it is a mount point for a tmpfs filesystem. This is
required by some POSIX shm implementations (shmopen(), etc.). I think
it is starting to be created automatically by some (many?) current
distributions.
Last year, Paul Davis wrote a version of JACK (in CVS only) that
required POSIX shm. There was massive confusion at the time, because
many systems did not have the appropriate mount configured. And, that
is not the kind of thing JACK's `make install' should do.
My LADSPA plugin would allocate a segment of shared
memory from "/dev/shm".
That is possible because most likely all Linuxes have that device.
Then somehow I create a backdoor for LADSPA controls. The backdoor goes
through the shared memory segment. Finally, I would write an independent
GTK application which provides my own GUI to the plugin.
If one does not use the GTK application, then all what is available
are controls provided by the host.
Nice. Personally, I think a socket interface would be better, though.
--
joq
3 Feb
3 Feb
6:10 a.m.
On Mon, Feb 02, 2004 at 02:25:54 -0600, Jack O'Quin wrote:
OSC! that way you make LADSPA plugins inside hosts OSC compaible as a side
bonus.
Using SHM for that kind of IPC is painful - the synchronisation issues are
hard to deal with and you have to worry about overflow.
- Steve
If one does
not use the GTK application, then all what is available
are controls provided by the host.
Nice. Personally, I think a socket interface would be better, though. 
2 Feb
2 Feb
5:50 p.m.
On Mon, 2004-02-02 at 14:52, Juhana Sadeharju wrote:
What about the following idea?
My LADSPA plugin would allocate a segment of shared memory from "/dev/shm".
That is possible because most likely all Linuxes have that device.
Then somehow I create a backdoor for LADSPA controls. The backdoor goes
through the shared memory segment. Finally, I would write an independent
GTK application which provides my own GUI to the plugin.
And now your LADSPA plugin won't work on anyone's machine that doesn't
have shm set up just like you do. Bad Idea(TM).
Linux Audio Developer's SIMPLE Plugin API. Don't go making your plugins
do crazy crap like that. :)
If you really want to make a custom GUI for your plugin, nothing's
stopping you from writing a simple jack/ladspa host that just takes
input, runs it through your plugin, and outputs via jack (this is really
easy BTW) and putting whatever UI you want on it. Then your plugin will
still be a normal LADSPA plugin everyone can use.
-Dave
3 Feb
3 Feb
4:43 a.m.
Dave Robillard wrote:
If you really want to make a custom GUI for your
plugin, nothing's
stopping you from writing a simple jack/ladspa host that just takes
input, runs it through your plugin, and outputs via jack (this is really
easy BTW) and putting whatever UI you want on it. Then your plugin will
still be a normal LADSPA plugin everyone can use.
But you cannot automate it in ardour ...
Uwe
--
voiceINTERconnect www.voiceinterconnect.de
... smart speech applications from germany
9:51 a.m.
On Tue, 2004-02-03 at 03:38, Uwe Koloska wrote:
Dave Robillard wrote:
Well if there was a way to get problem-free GUIs in LADSPA plugins,
people wouldn't be talking about GUIs for LADSPA plugins so much ;)
If you really want to make a custom GUI for your
plugin, nothing's
stopping you from writing a simple jack/ladspa host that just takes
input, runs it through your plugin, and outputs via jack (this is really
easy BTW) and putting whatever UI you want on it. Then your plugin will
still be a normal LADSPA plugin everyone can use.
But you cannot automate it in ardour ...
10:23 a.m.
On Tue, Feb 03, 2004 at 08:49:49 -0500, Dave Robillard wrote:
On Tue, 2004-02-03 at 03:38, Uwe Koloska wrote:
Its not finding a way thats the problem, its getting people to agree on
one.
- Steve
Dave Robillard wrote:
Well if there was a way to get problem-free GUIs in LADSPA plugins,
people wouldn't be talking about GUIs for LADSPA plugins so much ;) If you really want to make a custom GUI for your
plugin, nothing's
stopping you from writing a simple jack/ladspa host that just takes
input, runs it through your plugin, and outputs via jack (this is really
easy BTW) and putting whatever UI you want on it. Then your plugin will
still be a normal LADSPA plugin everyone can use.
But you cannot automate it in ardour ... 
10:44 a.m.
On Tue, 3 Feb 2004 14:18:59 +0000, Steve Harris wrote
On Tue, Feb 03, 2004 at 08:49:49 -0500, Dave Robillard
wrote:
This again :)
'scuse my ignorance - but how does it work with VST plugins?
http://www.ohmforce.com/media/ss_OhmBoyz_funky.jpg !!!
dave
................................. www.pawfal.org/nebogeo
On Tue, 2004-02-03 at 03:38, Uwe Koloska wrote:
Its not finding a way thats the problem, its getting people to agree
on one. Dave Robillard wrote:
Well if there was a way to get problem-free GUIs in LADSPA plugins,
people wouldn't be talking about GUIs for LADSPA plugins so much ;) If you really want to make a custom GUI for your
plugin, nothing's
stopping you from writing a simple jack/ladspa host that just takes
input, runs it through your plugin, and outputs via jack (this is really
easy BTW) and putting whatever UI you want on it. Then your plugin will
still be a normal LADSPA plugin everyone can use.
But you cannot automate it in ardour ... 
11:13 a.m.
On Tue, Feb 03, 2004 at 03:31:23 +0100, Dave Griffiths wrote:
In theory:
VST provides a (cross-platform) library (libvstgui) that is used
to draw pixmap GUIs. The plugin code calls UI functions.
In practice:
Many plugins call OS specific drawing functions.
I'm not sure how automation is handled, but I dont think UI controls are
routed via the host, so I'm guess its done on "trust" and fudged timing.
I prefer models where all paramer changes go though the host so it can get
its automation sample accurate and repeatable.
- Steve
Its not
finding a way thats the problem, its getting people to agree
on one.
This again :)
'scuse my ignorance - but how does it work with VST plugins?
http://www.ohmforce.com/media/ss_OhmBoyz_funky.jpg !!! 
12:07 p.m.
In theory:
VST provides a (cross-platform) library (libvstgui) that is used
to draw pixmap GUIs. The plugin code calls UI functions.
In practice:
Many plugins call OS specific drawing functions.
I'm not sure how automation is handled, but I dont think UI controls are
routed via the host, so I'm guess its done on "trust" and fudged timing.
the plugin is supposed to make a callback to the host
("setParameterAutomated") to tell the host about the change in the
parameter value.
7:47 p.m.
'scuse my ignorance - but how does it work with
VST plugins?
http://www.ohmforce.com/media/ss_OhmBoyz_funky.jpg !!!
That's definately the most compelling reason I've ever seen why NOT to
implement LADSPA GUIs....
-DaveR
7590
days inactive
7591
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
7 participants
participants (7)
-
Dave Griffiths -
Dave Robillard -
Jack O'Quin -
Juhana Sadeharju -
Paul Davis -
Steve Harris -
Uwe Koloska