[gmpi] Re: Decision time: 8.2
- From: "Vincent Burel" <vincent.burel@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Fri, 22 Aug 2003 09:48:33 +0200
----- 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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
- Follow-Ups:
- [gmpi] Re: Decision time: 8.2
- From: Mike Berry
- References:
- [gmpi] Decision time: 8.2
- From: Tim Hockin
Other related posts:
- » [gmpi] Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- » [gmpi] Re: Decision time: 8.2
- [gmpi] Re: Decision time: 8.2
- From: Mike Berry
- [gmpi] Decision time: 8.2
- From: Tim Hockin