5 Feb
2003
5 Feb
'03
8:48 a.m.
On Wednesday 05 February 2003 13.15, Sebastien Metrot wrote:
[...]
Good point. I've never considered ruling out native code GUIs an
option, so I'm assuming that these are the *other* alternatives.
The fact is I can't talk about this because of an NDA but believe
me: I'm doing exactly this :-).
Well, you might still be able to comment on an idea: Splitting up the
GUI in two parts; one that runs in the same process as the DSP
plugin, and one that runs in another process, possibly on another
machine. This would allow the "local" part of the GUI to interact
with the DSP plugin more effectively, while still messing with your
favourite toolkit in another process.
Of course, fixing all the toolkits would be the Right Thing(TM), but
as it is, I suspect that it's not going to happen any time soon
unless *we* - a bunch of audio hackers - start working on it. Doesn't
seem very likely, but you never know...
Also, I might be totally unaware of some major efforts in progress.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
We're not
talking about *limiting* anything here. These are just
alternatives, and native code GUIs will definitely be one of
them.
I didn't saw it listed in the possible solutions. I think you
should try to use the existing plugins available commercially
(try Halion & Kontakt for exemple) to understand the limits of
this design.
I think you should try to do what they do in the process of a
host using another toolkit... ;-)