On Thu, Sep 27, 2007 at 12:35:44AM +0200, Tim Blechmann wrote: > hi again, > > > Well, the "engine" is actually a "language interpreter". I don't think > > it makes much sense to have a configuration file for a language > > interpreter. This means the semantics of the language vary from site to > > site, which is a dangerous idea. PHP tried it, and you'd be crazy to say > > it's a good idea (magic quotes, anyone?). The Python lanugage itself has > > no configuration. The 'python' executable allows some configuration, > > such as setting environment variables like PYTHONPATH. Still, this isn't > > anything you couldn't do in the python language (sys.path), and in fact > > there are quite a few usages of python which do not include these > > configuration channels (most of them python interpreters embedded in > > other applications) > > i see your point ... and actually, the search paths are the only point, > where i am currently configuring the language ... however future > settings will include the state of the audio engine and stuff like > that ... > > > The engine is completely useless without an interface. Without it, it's > > a concept or maybe a library implementing that concept, but not > > something that a computer can execute. What you may have are multiple > > interfaces to the same engine, and different configuration files for > > each. Some interfaces may provide a superset of the others, so it would > > make sense to be able to share configuration files. What do all > > interfaces have in common? The ability to evaluate the nova language. > > the engine is not useless without the interface at all: > - there still exists the text-based patcher language, that i developed > last year ... > - there are people, who do not use a user interface for performance ... > i personally haven't used a graphical interface for any of my > performances for more than two years and currently i am using the nova > command-line interpreter to perform with nova > - there are people, who may want to run it on headless machines like > this: http://dieb13.klingt.org/content/images/mix/klopfer/show.html
I guess we are confused on terminology. I was thinking of "the engine" as those parts of code that have nothing to with how input and output are done, but only there is input and there is output, a state, and ways to change that state and the output through the input. For example, the engine would have some idea of a patch as some data structures in memory representing a graph, but it would not know about how to save a patch or load one from disk. This is why I said the engine is useless without an interface; it couldn't load patches, it couldn't get any audio input or output; it couldn't even be invoked because it has no notion of "command line options" or anything like that. I guess maybe what I'm think of as "engine" is what you consider as "kernel"; is that correct? > > If the engine provides a general mechinism to store and retrieve numbers > > (variables, essentially), then I don't see why anyone should say the GUI > > must not use them for its configuration. Sure, any patch that depends on > > their existence is invalid outside the context of the GUI, but if this > > is just the GUI configuration patch, why does this matter? > > the engine would require a bit more than a (hierarchical) > general-purpose property mechanism ... thinks that i currently think of > are: > - accessing the property mechanism from within the language is not > realtime-safe, so some indirection is required (message-thread to system > thread) > - when setting a specific property, the gui clients have to be informed, > requiring an additional notification > - indirection ... you load a patch when starting the interpreter (gui > thread), which the objects are created (system thread), and synchronized > with the interpreter (message-thread). loadbangs are executed > (message-thread), properties are set (system thread), the observers are > notified (observer thread) and finally the gui is notified (gui > thread) ... not mentioning, that the configuration patch should probably > be closed as you don't want to have it laying around in (locked) > memory ...it is quite a lot of overhead, that i wouldn't mind if i can > avoid it ... > - using a text file as configuration file (xml, yaml, json, ini) is way > more easier to read and/or customize with a text-editor, trying to edit > a nova-patch file by hand, you will go crazy after 30 seconds (my own > experience from writing the first patches in a text-editor about one > year ago) > > > > If what > > you want is a program which displays your pd patch graphically, and > > changes the background to flashing teal and pink every time you enter > > the chorus of your song, why should you have to do it from scratch when > > there is already a program that does the hard part? > > well, what i was talking about, were the _global_ preferences. in the > case you describe, it should be perfectly possible to customize single > (or groups of) gui objects via messages to the instance as is a common > practice in pd/max ... > > i will keep your proposal in my mind ... but from what i see the > situation now, it just doesn't feel right to me ... Well yeah, but why stop at local preferences? I don't think global preferences are that much different. I think I've made a pretty good case for this in my other reply, so I'll leave it at that. I think the reason it may not feel right to you is that the color of connections really have anything to do with goal of nova, making music, so why should some core part of nova care about it? My counter argument is that in fact the core doesn't care. All it knows is that there are some objects connected together just as normal for an audio patch and is totally oblivious to the fact that they have anything to do with the GUI. Making analogies again, consider this: import fancy_webserver fancy_webserver.default_port = 8080 Python doesn't know anything about webservers, but I can still use the primitives provided by the python language to configure one. Perhaps it just seems weird at first in nova because it is not designed as general purpose programming language like python, but I think the advantages of this idea far outweigh that little weird feeling. Obviously one of these objects will have to somehow convey information to the GUI. I haven't actually found the code to do it it yet, but I've read that GUI feedback is implemented in a form to do things like make bangs flash and in the future implement number boxes and whatnot. It's not a stretch to imagine a numberbox that changes the the default connection color instead of the number displayed in the numberbox. You mentioned a couple of technical reasons in opposition to my proposal which I think are good arguments. The first regarding the difficulty in editing the preferences I would address in two ways, or a combination thereof. The solution I like the most is to make the nova GUI so awesome that editing patches isn't a pain. I think this would involve less mouse dependence such as we have previously discussed. However pratically speaking I haven't thought of a way to make the interface that awesome yet. So, one could implement an object which parses a text file and spews messages based on what it reads. By doing it this way, instead of just rejecting my proposal and adding some XML parser to the GUI for configuration or whatever, you can reuse this object to read and write configuration for all sorts of other things. For example, you might find it handy for sequencer data. Less code means fewer bugs and less development time, aka win. Regarding overhead, this is an area where I am not really experienced enough to know yet. I can only assume the necessary code is either already written or will be written soon since it's needed for things like number boxes, and previously mentioned, and since numberboxes and whatnot are pretty normal in operation, the overhead will be managable. _______________________________________________ nova-dev mailing list [email protected] http://klingt.org/cgi-bin/mailman/listinfo/nova-dev http://tim.klingt.org/nova
