[gmpi] Re: Topic 8: Parameters
- From: "Vincent Burel" <vincent.burel@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Fri, 8 Aug 2003 11:50:41 +0200
----- Original Message -----
From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Friday, August 08, 2003 11:08 AM
Subject: [gmpi] Re: Topic 8: Parameters
> On Thu, 7 Aug 2003, Tim Hockin wrote:
>
> > As opposed to? We discussed this for XAP, too, and we couldn't find a
REAL
> > reason that controls, with raw data blocks, were insufficient.
>
> That's true. IF you are allowed raw data blocks, and IF the control map
> (parameterspace, whatever) is dynamic. Otherwise many developers will just
> define some kind of "state" control for the whole plugin, and use the raw
> data block to store opaque data as you describe below.
we need the abilities to manage both
- data block.
- automated parameter.
And the host has to take care about the Context (data block) and automated
parameters in the same time.
there is different reasons :
- all paramters are not public and some of them can have no representation
on the GUI.
- the automation makes sens with a few amount of parameters not with all.
i met different problem with automation :
- 1- the time to program it. Most of SDK's are planned for kiddy effect
with 10 parameters and that's all. with the multichannel and more
complicated effect , you can rich several hundreds of parameters with
different behavior for each and the time to programm the connection between
parameter / automation process /audio processing, can become too much long.
- 2 -Secondly the computer cannot support the load when there is too much
parameter handled one by one (even if it's every 20ms only). Especially on
complicated effect when a public parameters is related to a big amount of
DSP parameters to re-compute. And even just a parametric EQ 5 bands can
overload your computer, because every 10 ms of 20ms you send freq/Q/gain and
each time you have to recompute the effect DSP parameters.
- 3 - the user is not able to manage correctly hundreds different parameters
in automation mode, this makes no sens. When the effect become complicated,
the user prefer to work with snapshot.
- 4 - Each Parameter automated needs a special processing behind to avoid
zipper noise and transition problem , this also can multiply the algorithm
load by 2,at least , and much more...
- 5- Also automated parameter Editing can become a hell, because normally
only the GUI of the effect is able to let the user edit a parameter
correctly. This is worst again when there is multi relation between
different public parameters.
-6- linked parameters is also a hell to manage, for example a simple Stereo
EQ, able to let you set independently left and right, can cause trouble
during automation PLAY. this is a problem to warrant that the automation of
the linked parameters will be synchronized.
Regards
Vincent Burel
----------------------------------------------------------------------
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:
