[gmpi] Re: Req 76,78

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

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

didier, this was discussed for weeks on this mailing list last year. i
really don't want to hash it out all over again. we had several
windows-based programmers object, and in the end those of us who favor
this particular requirement convinced even them of its worthiness.

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

i already pointed out that its not about safety, although that can be
an added benefit.

>>>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(??)

the requirement in GMPI specifies that the DSP and GUI parts of a
plugin may not execute in the same context (process/address
space/whatever). it doesn't say any more than that.

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

i'm willing to grant you whatever knowledge of windows you have - its
likely to far exceed my own. but i also know that windows current
design is not part of the future of audio. the new design for audio in
longhorn looks nothing like the stuff in XP, and thats because MS
knows that what they have isn't adequate. i don't know that longhorn
will be able to match OSX and Linux for low latency audio, but it
seems more likely. meanwhile, 

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

the people from GRAME got it work pretty well when they ported their
software to windows. its not as good as OSX or linux, but it provides
acceptable latencies when done correctly.

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

the requirements specifically mention windows, osx and linux, and
imply other possible operating systems.

--p

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

  1. Home
  2. gmpi
  3. Archive
  4. 02-2005