[linux-audio-dev] PTAF link and comments

[David Olofson]

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