[gmpi] Re: Req 76,78

  • From: "Didier Dambrin" <didid@xxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Fri, 4 Feb 2005 03:33:11 +0100


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.


why is that?


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?


but it's exactly the same problem with interprocess communication. How does the UI in another process fixes any safety?




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.


then it's the *audio processing* that you want in another process to achieve this, not the GUI(??)



IMO I think that you both may be aware of the future of audio, but far from the reality of programming (at least under windows)



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.


again I really don't know about OSX or linux, but there's no efficient way under windows. When you do this, it's really that you don't have the choice, or when you don't care of communication speed (while it's the main think to care about for a sequencer).




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).

ok, so GMPI is strictly for macs?



----------------------------------------------------------------------
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: