[Dev] 'get' revisited

[Stephen Sinclair]

> I think this conceptual model corresponds more closely to what any given
> implementation will do, i.e. even to just return a stored value, a module
> will need to do at least two things: retrieve the value, and output it as
> an OSC message.
>   

Hm, I have to say, I'm starting to lean towards this idea just because 
it gets rid of the whole need for the /get message, which, frankly, 
seems kind of hacky anyways.

I really hadn't at all thought of the /get problems with OSC-route, 
(which I see now might be a bit of a problem), but the reason the .get 
solution was bugging me is that I don't like the idea of introducing a 
new non-standard separator into the addressing scheme that has nothing 
to do with the OSC protocol.

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.  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.

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"..

Hm, just thinking aloud.
Perhaps we need to list some more use cases here and come up with some 
more concrete examples of the various solutions to this problem.


Steve