A bit of an idea popped in my head today. I know one goal of nova is to keep the GUI as a component independant to nova's ability to function. As I thought about what this means, I realized that the existance of GUI boxes runs contrary to this goal.
The problem is that gui objects have semantics that must be define. For example, a number box is pretty much (or exactly?) the same as [f], only it is drawn differently. As long as the number of gui objects are finite, this isn't a big deal, since the semantics can be defined in every nova executable. However, what if I want to implement some new complex object for nova, and I want to make a GUI for it that isn't some amalgam of existing GUI objects? Let's say for example, it is some sort of fancy sequencer. I decide it is adventagous to implement a custom GUI instead of using a combination of existing GUI boxes because this sequencer is quite complex, and a custom GUI allows me to make it more usable. In order to maintain the GUI separation goal previously mentioned, I have to somewhere define what this sequencer does (the semantics) separately from how one interfaces to it (graphically, in this case; the GUI). This isn't really possible if the sequencer is one "gui object". I got to thinking, all the builtin GUI boxes function just like some other primitive box. Sliders and number boxes are just [f] with some additional "hints" giving min and max values maybe. There already exist interface hints attached to objects to indicate where they are positioned on the canvas and such; I imagine these range hints can be implemented in the same manner. I seem to recall the graphical bang in pd is actually [bng], and there is also a non-graphical [bang] (maybe i have that backwards). It doesn't make sense to me to have different objects that do the same thing but just look different. It seems to be a violation of interface independence, and it's just not elegant. So, why not have some way to associate possible alternate interface representations to ordinary objects? For most common GUI boxes, the association is to an ordinary primitive object. For more complex GUIs like the sequencer example, the association is probably to some abstraction or subpatch. This has other implications as well. For example, sliders can be switched to number boxes in a patch without deleting and recreating the box. GUIs can be disabled when they are not needed to save space or reduce CPU load. Perhaps more interestingly, it opens the possibility for alternate interfaces to be attached to objects. Perhaps one could implement an auditory interface for blind musicians, or interface to external software or hardware. While this could also be accomplished by adding additional objects to the library and adding them to the patch, I think doing so is undesirable because it creates a dependency on whatever particular device they use. If the patch is then later shared, this interface definition, which is not really important for the primary goal of the patch, is poorly factored to be modified by a 2nd user who has a different studio configuration. Another point is that non-gui objects like [f] have state, but that state isn't reflected in the interface. For example, I find a simple thing like <http://unununium.org/~indigo/counterpatch.png> confusing because it says "[f 1]" but depending on how many bangs it has had, it could be something other than 1. If a number box and [f] are one and the same, then whether or not the current state is displayed or not is a matter of choice of interface, which can be adjusted without modifying any connections. I suppose an alternate solution to this issue is to simply author patches containing no GUI objects as best practice, instead providing control ports where a user of the patch can then attach whatever interface elements he likes, be they GUI boxes, or MIDI objects, or whatever. This has an elegance to it as well, although I think the nature of the interface at present discourages this behaviour. Another thing to consider is how the interface and available facilities can be adapted to make the "best" way to do things also the easiest way. In either case, my mind isn't really decided on this issue, so please share your thoughts. _______________________________________________ nova-dev mailing list [email protected] http://klingt.org/cgi-bin/mailman/listinfo/nova-dev http://tim.klingt.org/nova
