hi jeff, > * A base node class that lets you add and remove edges to other nodes, > and probably access a per-node property hash for parameterization and > communication to the "outside world". All the audio and control nodes > would derive from this guy. > > * All the stuff that is processing the graph in order to do DSP > scheduling could also be completely decoupled from the user defined > graph API. You hand it a graph and it generates it's own DSP processing > chain for scheduling. The graph would be observable so any updates on > node properties or changes in the graph would be sent to the scheduler.
the design of supernova, takes the concepts of groups and synths from supercollider. groups are groups of synths, synths are processing units, similar to subpatches in pd/max/nova ... i am not sure about the external interface, i thought about integer ids (like supercollider) or uuids (like nova) the synth-graph is similar to the ugen-graph in nova, however it will rely on busses for communication, which have a higher expressive power in terms of multi-threaded audio computation. the synth-graph is then compiled to a dsp queue, a graph representation, that can be used for multi-threaded synth scheduling ... when nodes are added to the graph, one can specify some position constraints (like: before synth x, after synth y), so the synth-graph should be more transparent to the user than the ugen-graph in nova ... > * Supporting Chuck style, sample synchronous scripts will be really > awesome, but I think it's important to not let it bleed into the DSP > chain API. The scripts should either run inside a DSP node, or run in > an external script runner that can call methods on graphs and nodes. for performance reasons, there will be the need to have ugen api for audio, control rate and events ... if no event will happen, you want to use the optimized, unrolled dsp function, similarly you want to have different functions for audio-rate and control-rate (e.g. compare with supercollider's or pd's ugen apis) ... i am not quite sure, how the event-rate api will look like, it will probably be different to the control-rate api, but will be able to use it as a fallback ... the virtual machine for the scripting language should run - synchronous in the synth (realtime thread), sandboxed, so no blocking actions are allowed - asynchronous (non-realtime thread) > * One of the difficulties I had in Nova was pulling apart the PD type > language from the actual DSP stuff. It would be so nice to just have a > big library of DSP nodes that could be chained together and run. On top > of that any number of languages, scripting APIs, gui manipulators could > be developed to create and manipulate DSP graphs. supernova has a strong separation between the signal-scope and the language-scope. you will be able to run the dsp engine without entering the language-scope ... in this case, it will be a pure dsp application ... > You really have some great code in the Nova source, and I bet with some > refactoring and simplification you could get a lot more developers to > join in because it would be easier to figure out and to jump in. For > example, implementing a new DSP node should be as simple as creating one > class in one file. I would start a branch with the goal of using the > least amount of code possible to support fully functional DSP graphs. > You already have this going, so it's probably a matter of pulling it > away from all the other stuff connected to it. i am not sure about the design, yet ... since supernova's ugens are going to be similar to nova's ugens, one will probably have to implement - a ugen factory class - one or more ugens, created by the factory - a registration for the moment, there is no way to build a synth from ugens, and it is possible to write synths in c++, but that is not the way, supernova is supposed to be used ... (for now, i have one branch with a simple sine, used for debugging purposes) > As for the GUI, I think either the Qt GraphicsView or the Clutter > library are the best option. They can both be rendered in OpenGL, and > they both support object level grouping, events, transformations, and > animation. 3D manipulation is rarely useful for anything practical so > GL is really only good for effects, not functionality. Having a fancy > GUI can get people interested in the project though, so maybe getting > some generic shaders setup to do glowing and pulsing and burning would > get people excited... as i wrote before, i am more in favor of a dumb gui, sending osc messages ... i am not familiar with clutter, have you worked on any project with it? how does it compare to qt? cheers, tim -- [EMAIL PROTECTED] http://tim.klingt.org Art is either a complaint or do something else John Cage quoting Jasper Johns
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
