[Dev] 'get' revisited

[Jamie Bullock]

On Mon, 2007-04-02 at 11:56 -0400, Stephen Sinclair wrote:

> 
> Anyways, while reading this discussion, I've been trying to think of 
> cases where this /get message will really be needed, and haven't come up 
> with all that many.  There are times, sure, when we'll want to request 
> the state of a module's properties.  For example, when a GUI is loaded 
> up, but the DSP is already running, and it needs to connect up and show 
> the current status of the DSP parameters.  Or even when a module is 
> first created and initialized, the GUI will need to request the default 
> parameters. 

The way Henrik F and I currently have things, both of the above
operations will be accomplished through the library. With the current
design, the GUI would query its instance host (slave), which would proxy
the request via OSC through to the instance host (master) running in the
engine. The master instance host has an in-memory representation of
module state, and it is this data that will get queried and sent back to
the GUI. The GUI never _directly_ queries the modules, so in these
circumstances the '/get' debate is largely irrelevant.

>  But for the most part I think parameters will just be 
> broadcast when they change, right?  So during regular run-time I guess 
> /get will not be used much.
> 

I think it depends on how low level we want Integra modules to be. Last
time this was discussed, some of the group thought that Integra modules
should almost solely be higher level modules (like Jamoma), other
members wanted low-level modules. My view is that we should always
provide a certain amount of low-level functionality so we always have
the choice.

The ability to get individual parameters could be very useful for things
like dynamic interpolation because you can query a module for the
current value of a parameter fand then ramp up to the target rather than
having to always store a duplicate of the current value in the
interpolator.

> It seems to me like this requesting of module parameters will generally 
> happen on a per-module basis rather than a per-parameter basis.
> 
> The module supporting a module-level /report-parameters method or 
> something might be enough of a solution here.  Of course, to support 
> that, internally each module parameter will still need to be "gettable"..
> 

Exactly, I think the question is just about what syntax we use.
Using /parametername instead of /parametername/get is simpler,
(marginally) more efficient, and to me it is more logical (as I tried
[badly] to show in my recent email).

best,

Jamie