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. 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. I think you should try to use the existing plugins available commercially (try Halion & Kontakt for exemple) to understand the limits of this design. 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.
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 :-). XML + Scripting language is very nice but not flexible enough. Sebastien ----- Original Message ----- From: "Steve Harris" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 05 February, 2003 11:57 Subject: Re: [linux-audio-dev] PTAF link and comments > On Tue, Feb 04, 2003 at 11:56:39 -0800, Tim Hockin wrote: > > Defining a proper cross-platform GUI system will be fun. I see four levels > > of UI from plugins: > > > > 1) none - host can autogenerate from hints > > 2) layout - plugin provides XML or something suggesting it's UI, host draws > > it > > 3) graphics+layout - plugin provides XML or something as well as graphics - > > host is responsible for animating according to plugin spec > > These three are not useful, because it doesn't allow custom UI objects to > be drawn, eg. compressor curves, meters etc, which is the whole point. > > > 4) total - plugin provides binary UI code (possibly bytecode or lib calls) > > bytecode would be too slow I think, the maths for some UI work is quite > heavy. > > - Steve