[gmpi] Re: Req 76,78

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 03 Feb 2005 21:24:28 -0500

>> We can't force coders to do things the thread-safe way.  If you really 
>> want to break the rule, nothing's stopping you.
>why/how wouldn't it be thread-safe while in the same process?

I think Jeff slightly misspoke. Its not about thread safety. Its about
the fact that it may be impossible for the GUI to run within the
host's address space.

>it's even worse, interprocess communication can get quite complex (and quite 
>slow), and I'm sure most coders will have much more problems with that, than 
>with simple thread locking.

Many coders have already had to grapple with this in existing plugin
APIs. Look at the mess that comes up on vst-plugins with "which thread
can call which callback at what time?" You demonstrate later that you
are aware of these issues - how can it get any worse?

>> Cleanly separating GUI and Audio code is a natural consequence of good 
>> design.  If good design to you is "completely useless", stick with VST, 
>> you won't be dissapointed.
>Good design is as important to me, but IMO it's separating UI & audio in 
>different process that's very bad (coming from macs maybe?) design. To me, 
>UI & audio should just be in separate threads, because it's the most 

You are missing the future of audio. Look at video/CGI render farms,
and imagine physical modelling happening on a sub-google-sized audio
render network. Look at VST/System Link. Look at racks of dedicated
Gigasampler systems mounted on the wall. Look at the PowerCore and
UAD-1 cards.

The idea that the DSP code runs in the same address space, even the
same CPU, as the GUI is a historical accident.

>efficient you can get, at least under windows. Interprocess communication is 
>very painful (what's your solution, file mapping & ugly mutexes?) and very 
>slow compared to interthread communication (which only requires very fast 
>critical sections).

You're wrong here. Its perfectly possible to use lock-free techniques
for DSP<->GUI communication as long as there is a way to wake up the
GUI from the DSP in an RT-safe fashion. This is not always easy to
find or satisfy 100%, but 95% will do :) Its certainly possible on OSX
(Mach ports), its certainly possible on Linux 2.6 (futexes), and there
are acceptable if not good ways for Win32 and Linux 2.4.

>And yes I'm aware that plugins have problems with thread safety, but that's 
>because a lot of coders aren't aware of how their host sequencer works, and 
>the VST specs hardly mention it. But if your solution to this is 
>interprocess communication, the result will be much worse, and much less 
>I can tell you that, by experience on a sequencer, communication between 
>processing & UI may need to happen *all the time*. Because an UI can be much 
>more than a bunch of knobs.

And I can tell you, based on experience on a sequencer, that its
perfectly doable. If you want a nice small example, check out
SooperLooper, a live looper from Jesse Chappell. SooperLooper itself
is a GUI-less program that can be run using a MIDI pedal board, other
MIDI control devices, and/or a GUI that runs on the same machine or
some other machine. All communication between the engine and the GUI
is via OSC, and it works beautifully. No, there are no waveform
displays, no fancy oscilloscopes, but there are ways to work around
that if you are at least allowed to make the "same host" assumption
(shared memory).

I would point out that its my experience that people with a Windows
background generally are scared of IPC, while people with a *nix
background generally are scared of thread programming. Given the right
set of APIs (POSIX, for the most part) neither are particularly
troublesome once you understand some basics (which I am sure you do).


Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: