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. when thinking about a complex patch with several thousands of objects, and maybe a few hundred [f] objects, i really don't want to have the overhead for gui synchronization ... seeing the nova message thread as 'soft-realtime' thread, one should avoid system calls as much as possible. nova doesn't completely avoid system calls (and thus it is _not_ a hard-realtime system), especially the callback framework uses heap-allocated memory ... gui notifications imply a call to malloc and thus they should be avoided if possible ... [gui.f] shares quite a lot of common functionality with slider objects like [gui.hsl] or [gui.vsl] ... so they should probably share the same codebase on the language side ... they are more powerful and more complex than [f] objects, which are designed to be lightweight ... both are different and should be used differently ... when building patches for live performances, one should build user interface and patches separate from each other ... although i don't think, the separation should be as strong as in supercollider or vibrez, where the user interface is completely independent from the underlying language, performance patches should have separate gui and engine parts ... however one could steal ideas from other systems like pd (graph-on-parent) or max/msp (bpatcher) to find ways for building gui and engine in one patch ... cheers, tim -- [EMAIL PROTECTED] ICQ: 96771783 http://tim.klingt.org Which is more musical, a truck passing by a factory or a truck passing by a music school? John Cage
signature.asc
Description: This is a digitally signed message part
_______________________________________________ nova-dev mailing list [email protected] http://klingt.org/cgi-bin/mailman/listinfo/nova-dev http://tim.klingt.org/nova
