On Fri, Oct 05, 2007 at 12:54:13PM +0200, Tim Blechmann wrote: > hi mischan & phil, > > from my understanding there are quite a number of differences between a > plain [f] object and a [gui.f] (numberbox) object. > > the functionality of the [f] object is limited to: > (1) set float > (2) set float & send to output > (3) send the stored value to the output > > a gui object does support other operations accessible from the > language: > (1) and (2) require additional gui notification > (2) and (3) maybe send the float to a messagebus > (3) similar to [f] > (4) setting gui-specific properties > > > biggest concern, that i have about combining [f] and [gui.f] objects is > the gui notification overhead. > in a typical patch, for most cases [f] objects are sufficient, [gui.f] > objects are usually to be used to build user interfaces or to set some > values to an object during patching. > [gui.f] objects shouldn't be used for debugging purposes ... the > interpreter implements the notion of "debug mode", that provides means > to access the last message, that was sent through a connection. > [...]
I'm not understanding the differences you are trying to point out here, other than that a number box has an interface while [f] does not. What I understand is that each of [f] and number boxes have an internal state, exactly one float. Each also provides a way to change that state, one way that emits the new value on the output, and one way that does not. Each can also be commanded to send the current state on the output without changing it. There are two other aspects in which they differ. Firstly, while they both do pretty much the same thing, the way those things are done are different. Number boxes have only one inlet, but accept a "set" message. [f] has two inlets. I don't see any reason at all for these differences in behaviour. Why should there be two *incompatible* tools to do the same job? It's more to learn, and should I ever want to alternate between a number box and [f], I have to add a compatibility layer. The other difference is as you said, number boxes require GUI feedback, and obviously have an interactive interface, which is how they differ usefully from [f]. I think you must have misunderstood the idea I proposed. The idea was not to do away with [f] and replace it with numberboxes always. The idea does not imply that all [f] like things will require GUI notifications. The idea was this: there be one object that implements a "float register", and this object can, *optionally*, have attached to it any interface from some number of possible interfaces. Maybe a number box, maybe a slider, maybe something else. Only when one of these optional interfaces is in use are GUI notifications required, and then only if the interface requires it. Overhead compared to a regular [f] when the interface is nil would be exactly 0. More generally, any box can optionally, instead of it's default and lightweight [fooobject] representation, have an alternate interface which may include indication of state (thus requiring GUI notifications) or provide some means of interaction by being clickable, draggable, or whatever. _______________________________________________ nova-dev mailing list [email protected] http://klingt.org/cgi-bin/mailman/listinfo/nova-dev http://tim.klingt.org/nova
