[gmpi] Re: Req 76,78
- From: "Angus F. Hewlett" <angus@xxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 08 Feb 2005 11:09:34 +0000
Steve Harris wrote:
On Mon, Feb 07, 2005 at 07:49:12 +0000, Angus F. Hewlett wrote:
I can think of many situations where you DON'T want to expose the entire
state to the user (or at least not without some kind of filtering
mechanism, maybe some dynamic attributes of GMPI's parameter structure
to say "these are the -important- parameters"). There's an awful lot of
cases with big plugs where you have thousands upon thousands of
parameters, but only 10 or 20 that 95% of users actually want to automate.
Right, but we have a mechanism to deal with that, just wrap the parameters
you dont think it makes sense to automate in a blob, and they wont be
exposed to the user.
Yes, except the size of that blob, and the performance overhead in
passing it, is going to be massive.
Let's take DR-008 as an example.
In its current implementation (and I'm not saying this is perfect), it
has a 128-port automation map that's exposed to the VST (etc.) host.
Within the plug-in, you can map each of these ports to any one of 12,000
parameters. There are further parameters that are not automatable.
With this blob mechanism, any time anything outside of the automation
map changes, the entire blob has to be passed. That's grossly inefficient.
So, everything has to be passed individually. But if we do that, it has
to be exposed to the user at some level.
Didier wrote:
>90% because this segment is only emerging.
>Once a developper has made, for ex (it's my case) a generic multipoint
envelope control, I can tell you he will use it in all of his plugins
(instead of the usual ADSR knobs). Such a little editor can be much more
complex than just
>knobs.
This is true, BUT, for most cases, its state is still easily
representable as a set of scalar parameters.
>You also start to see more & more built-in gates, arpeggiators, etc,
all requiring custom editors.
Why does this have to be custom? What's being represented is actually
rather simple.
>But anyway, in all cases IMO separating GUI & process in different
threads is the dumbest thing ever, at least under windows. Even for just
knobs. It's almost as dumb as how knobs are working in VSTGUI.
You think it's dumb to put GUI and process in different *threads*? EVERY
realtime audio app works that way - even FL Studio, I'm certain of it.
What we're talking about is the ability to run them in different
*processes*.
IMHO, if we're going to expose all parameters to the host, might as well
try and push most developers in to using markup for the UI rather than
writing it in C(++). However, it's an open question as to whether to
make this an API thing (i.e. plug-ins expose their GUI in the form of
markup; we provide a rendering library for host developers to use) or an
SDK thing (plug-ins expose their GUI via a C(++) interface, but we
provide a library which plug-in developers can include allowing them to
write the GUI in markup, but for it to be exposed to the host as C(++)).
Regards,
Angus.
--
=========================================================
Angus F. Hewlett, Managing Director (CEO)
FXpansion Audio UK Ltd - http://www.fxpansion.com
Registered in the UK - #4455834 - VAT: GB 798 7782 33
=========================================================
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
- » [gmpi] Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78
- » [gmpi] Re: Req 76,78