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