I would strongly suggest that we not do a single context blob, but
instead leave it up to the plugin to determine the best grouping of
opaque data. In an example that I posted earlier, imagine that you have
a large analysis chunk which is constant but a small amount of other
opaque data that changes regularly. With a single context, the host then
has to save the large chunk redundantly every time the small one changes.
If we use opaque parameters, then the host simply saves the blob for
each parameter which changes. These can be automated, simply not
represented, byt the host. Obviously, whatever control is actually being
automated needs to be changed using plugin UI.
This brings up another topics which we need to cover - how does the
plugin report parameter changes to the host? Tim, can you add that to
the list.
Mike
Vincent Burel wrote:
----- Original Message ----- From: "Tim Hockin" <thockin@xxxxxxxxxx> To: "GMPI list" <gmpi@xxxxxxxxxxxxx> Sent: Friday, August 22, 2003 2:38 AM Subject: [gmpi] Decision time: 8.2
8.2: How do parameters fit into saving and restoring of a plugin's state? -------------------------------------------------------------------------
How is plugin state saved and restored? Ideas:
a) All the parameters (or stata, as per topic 8.1 abstractions). b) A pair of chunk = save_state(); restore_state(chunk); functions c) Other? Explain.
Instead of talking about parameters, i would prefer we talk here about CONTEXT. And i would talk about a CTX port (which would be the only one mandatory port on a plug-in) allowing to set/get the entire context of the effect defining the complete behavior of the effect. The context can contain parameters but also private setting or special tables or whatever datas which are never seen by the user... The Data protocole of this port will be private (the host won't be able to understand the datas here).
---------------- parenthesys --------------- personnally i would prefer that we look at the hardware model. I'd prefer to talk about port and protocole than to talk about parameters only. for example i'd prefer to have a true M.I.D.I. port (here the data protocole is already defined), a GUI port for the GUI (which as to be seen as an external remote) and also one port for public automated parameters (where maybe we can defined a public protocole to let the host understand the datas in the stream). and other port for other purpose if needed (except the CTX port, all other can be optionnal).
This way does not forbid the host map some M.I.D.I. message into automated parameter if wanted, or GUI parameter into M.I.D.I. ...
The Plug-in, before processing a frame, will have to take a look in the buffer of each port and then will be able to handle completely its behavior in a logical way (that we have also to define).
A port can be defined as a simple software interface typedef tagGMPIPort { LPT_FNCT_INFO getInfoProtocole; LPT_FNCT_GET getData; LPT_FNCT_SEND sendData; LPT_FNCT_SETCALLBACK setRtxCallback; } T_GMPIPort;
port can be uni or bi-directionnal, some port can need a callback to push datas from the effect (server) to the client (for example to the GUI to display PEAK METER)... GetInfoProtocole can be done in order to reply to many different requests if needed (size of data, type of data, parameter description etc....) The plug-in can change the function pointer according the configuration of the effect (nbchannel, samplerate etc...) ----------- end of parenthesys -------------
For Managing Multi Port, for each interface, we need one port (an input/output entry point if you prefer) for each, to communicate with the effect. If the effect plug-in is in charge of processing what is incoming on the different port, the host has to handle the consistency of the different User Interface (clients) connected to the Effect, according the fact that we can imagine for example that we have different GUI for handling the effect (one classical GUI and a special one to be embeded in the Mixer for example - Mixing with plug-in on computer is actually a hell -)...
If the Host send a preset by the CTX port, the host will have after to update the GUI connected on the same effect, also probably the hardware remote if exist, and so on... I think the big deal is here, in the way we have to manage the different clients connected to the effects...
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
-- Mike Berry Adobe Systems
---------------------------------------------------------------------- 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