5 Feb
2003
5 Feb
'03
7:32 a.m.
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" <S.W.Harris(a)ecs.soton.ac.uk>
To: <linux-audio-dev(a)music.columbia.edu>
Sent: Wednesday, 05 February, 2003 11:57
Subject: Re: [linux-audio-dev] PTAF link and comments
calls)
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
bytecode would be too slow I think, the maths for some UI work is quite
heavy.
- Steve