[gmpi] Re: Decision time: 8.2

  • From: Mike Berry <mberry@xxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Fri, 22 Aug 2003 09:44:25 -0600

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

Other related posts: