linuxaudio.org

On Wed, 2011-03-02 at 16:58 +0100, Olivier Guilyardi wrote:

quoted text
> On 03/02/2011 03:30 PM, Stefano D'Angelo wrote:

>

> > Let's try to make everybody (un)happy:

> > http://blogs.sonyericsson.com/developerworld/2011/02/24/webgl-support-in...

>

> Pretty amazing.

>

> > However, as I see it now, this is a possible list of GUI techonologies

> > that may be worth considering:

> > 1. HTML/JS/CSS (web UIs)

> > 2. OpenGL (advanced UIs)

> > 3. GTK+ and Qt (almost all current LV2 desktop hosts use either)

> > 4. EFL (might be sound on "very embedded" devices)

> > 5. SDL (as portable as possible)

> >

> > plus all of the combinations of the above.

> >

> > How to decide what to do? Let's choose targets...

>

> You are focusing on the GUI technology but you are leaving aside the question of

> the communication between UI and audio processing. Choosing a GUI technology

> will have consequences on that.

>

> With native OpenGL, both the draw() and run() method would reside in the same

> .so, and the plugin could perform high-performance IPC internally, within a

> single process.

NO. This is, very deliberately, not how the UI extension works.

You /can/ do this with certain extensions, but it is an awful kludge and

should not be done for fundamental communication. You can however do it

to add optional whiz-bang features (like waveform rendering) - if the UI

and plugin are in the same process - which is not necessarily true.
UI <=> Plugin communication is handled via ports via the host. This

allows many things, the most obvious of which being that whole network

transparency thing you just threw out the window ;) The other obvious

reason is that all of that "high performance IPC" stuff, which involves

multiple threads and synchronization etc, is not easy, and obviously not

something we want every single plugin and UI to have to solve

repeatedly. Host's job.
> Just an example: a compressor plugin which shows the input and the output

quoted text
> waveform in realtime, for visual feedback of the applied compression.

>

> I think that what I'm saying about OpenGL about internal IPC also applies to the

> other technologies that you mention, apart from the web UI.

>

> So, with a web UI and even with WebGL, what are your ideas for communicating

> between the UI and the audio processing thread/process?

Plugins communicate via ports. Specifically, we need a higher level

'message' extension which logistically would function like MIDI does

now, except.. not be MIDI.
-dr
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev