Re: [linux-audio-dev] ladspa GUI round 2

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] ladspa GUI round 2
From: Robert Jonsson (robert.jonsson_AT_dataductus.se)
Date: Fri Mar 30 2001 - 18:28:31 EEST


I feel very good about this!

Infact, the model which is being discussed now is something I have been
pondering for almost a year now (I'm no fast progresser).
I was under the impression that this approach wasn't going to be well
receieved so I didn't talk alot about it....I'm glad it is such a
success (boosts my EGO also ;-)...

Most of what I had realized seem to have been brought up here on the
list also, I might still have a clue or two though that I'd like to
share. Let the rambling commence!

- Because automation should be available, all data passing MUST go
through the host. Data will be passed through the normal data ports
which are already defined in LADSPA. As a happy coinsidence this also
makes the design and implementation really simple.

- Detecting of a GUI should be made through the already available ID.
The GUI could have the same ID.
Since the GUI is more or less a standalone application which
communicates via stdout/stdin there should be very little confusion.
Either the GUIs are saved in a "gui" subdirectory. Or they all have the
additional name *.ladspagui or somesuch.

- In the above reasoning, having the GUI as a standalone application
opens up a lot of possibilities. How about letting the GUI be a HOST
also? Though only able to host it's own plugin.
I was thinking of usage something like this:

%> play test.wav | pluginGUI1 --usestdforaudio | pluginGUI2
--usestdforaudio | play
Ehm, not sure I got the syntax right, I didn't, right? The idea being to
construct simple signal chains on the commandline and letting the
different plugs send the data through stdin/stdout (note that this is
AUDIO data, not CONTROL data)

- Not directly related, but if we are to put the GUIs free there is good
reason to control how guis are displayed and managed.
I would vote for making a few guidelines about GUI design which would
allow the GUIs to be managed by a plugin-gui-manager (ehh?).
X supports something commonly refered to as SWALLOWING. It is the
technique used to put foreign window client areas INSIDE your own client
area. WindowMaker applets work like this for instance.
If all GUIs have the same dimensions (although bigger than applets) it
should be quite possible to design a managing application, in which all
these GUIs will be put.
I was thinking something like how guiless-plugins are managed in VST,
stacked in a Window of it's own. Although not as confined as their
solution, a gui should be able to look as it pleases.
I think REASON (have only seen screenshots) have a system where you can
scrolldown in a larger window to gain access to different
plugins/machines, stacked in a row.
I'm not sure these systems are the best(pretty shure they are a workable
solution though), but having all plugins pop windows open anywhere they
like on the screen will not be a good solution.

Nuff for now, hope some of it made sense....
I will bring more if I remember anything else...

/Robert

Steve Harris wrote:

>>
>> what do you all think ? we could have this done in a few days!
>
>
> That sounds fantastic, I've been away for the last few days, and havn't
> been able to really think about the implications if this, but I'm
> returning this evening. I could nock up something quickly to test this
> approach give an api. Its sounding more and more like the right thing.
>
> - Steve


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 15:58:11 EEST