[Dev] 'get' revisited

[henrikfr]

> > 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. 
>  
Actually, we will be requesting the state of a module a regular intervals from the library. At least that is the plan. 

> It seems to me like this requesting of module parameters will generally  
> happen on a per-module basis rather than a per-parameter basis. 
>  
This is something I've been thinking about too. However, this method should be inherited by all classes and shouldn't have to be implemented in the module itself. And, we still need to be able to get the value of the attributes individually for efficiency. 

> 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. 
>  
As I wrote in an earlier post, I think this is a question of design and we just need to find a way to do it that can be used consistently. In OSC '/x' is just an address. If we define an oscillator and we have an address '/frequency', is that the address of a method or an attribute? What Jamie is suggesting is to say that all OSC addresses result in method calls which I guess is OK, as long as it is consistent, but perhaps difficult to grasp for the un-initiated?  

/henrik f