5 Feb
2003
5 Feb
'03
8:01 a.m.
On Wednesday 05 February 2003 12.25, Sebastien Metrot wrote:
All these solutions are very limited to simple
UI/Plugins. How
would one build a sampler's UI with these blocks for exemple? The
sampler is the typical problematic UI because the data set is
really huge and have a separate code fragment (ie two processes for
exemple) for the DSP and the UI means having twice the load on
memory/Disk IO when you need to display and edit the actual data.
This is not a pratical solution IMHO and a big design flaw.
It's pretty much unavoidable, given the issues with toolkit
incompatibilities.
Either way, there's still shared memory and ultimately, JACK, if you
really need that high bandwidth interaction between the GUI and the
DSP part.
XML UI
descriptions and scripting languages are very nice and would
probably be very welcomed by the plugin writers but limiting the UI
to these only solution would be very shortsighted.
We're not talking about *limiting* anything here. These are just
alternatives, and native code GUIs will definitely be one of them.
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... ;-)
Their UI is allready very slow (Halion is
particularly
slugish when you use big drum sets or instruments with many
layers). If you have to send events back and forth containing the
actual data you will slow things down to a crawlor you will need to
use platform dependent hacks to share data in between the DSP and
the UI.
Rather the "platform dependent" (but generally available) hack that is
shared memory than trying to pry Qt, GTK+ and FLTK into the same
process...
And forget about everyone using a single toolkit that we pick. It just
won't happen.
I think LAD people wants to enforce this because of
the limitations
of the XWindow system which is a bad reason. The good way of doing
this is to FIX the toolkit so that they can coexist gracefully.
Motif allready provides an API for other toolkits to hook into the
event system, the others should start doing the same. Isn't it what
opensource is all about: taking the time to fix wrong designs
instead of rushing the apps out of the door to satisfiy short term
customers? Apple had the exact same problem in the classic API: the
event management was totaly centralised inside an application, and
they fixed it when developping Carbon. If even apple can fix their
wrong designs, everybody can :-).
Well, question is if we can get everyone in on this, and if we have
the resources to get this working within a reasonable time frame.
(Whatever that is.) We seem to be the ones that are most interested
in getting GUI toolkits to cooperate - but we're also small group of
hackers with too much on our hands and too little experience with
hacking GUI toolkits. Who's actually going to do the work...?
XML + Scripting language is very nice but not flexible
enough.
Nothing is. That's why there has to be multiple alternatives.
//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 ---