hi jeff, > I was just checking out the synthesis tookit, > (http://ccrma.stanford.edu/software/stk/information.html) and it got me > wondering if you ever thought of using it for Nova. Tim, have you been > implementing all the objects from scratch, or mostly porting from PD, or > something else?
i wrote most of the dsp objects from scratch ... mainly because the libraries, that i had a closer look at, had some issues ... stk seem to be some textbook implementations, not optimized for performance or anything (iirc, they are using double precision floating point numbers for sample representation) ... some other libraries (SndObj, csl, clam) had other issues ... some of the dsp algorithms are implemented as generic c++ templates, so they can be reused in other environments (e.g. i'm using some of the filter implementations as ladspa plugins for mastering) > Also, reading a bit about the Chuck project, it got me thinking about > two different aspects of nova. First is this idea of being sample > synchronous across virtual machines. In Nova the DSP engine is > processing in windows of samples. nova does the audio computation in blocks of 64 samples. however there is the notion of dsp contexts, which can be used to run a part of the dsp graph with different block sizes. in future, there will be some sample-accurate objects, similar to the functionality of vline~ in pd. sample-accurate synchronization between different nova interpreters is nothing, that nova deals with. first, one would have to solve hardware issues, though ... synchronizing the clocks of the audio interfaces i am also not sure, whether this is an issue, that nova should deal with ... > The second thing is supporting live coding. I was wondering if the > Nova engine needed to be specific to a visual programming environment > like PD, or if it could just be a realtime audio system that could be > operated on in a number of ways. in theory nova can be used for live-coding ... however, it is not optimized for live-coding, but for runtime performance ... i.e. when dsp objects are added, the dsp graph needs to be resorted ... supercollider is optimized for dsp live-coding (afaik, adding synths to the server is a very cheap operation) ... > In the back-end there is the idea of > gobj, for example, in a number of places. Does it really have to think > at all about graphical anything, or can it just operate at the level of > interacting audio objects? nova is using a dataflow paradigm for the language. visual programming is one way to implement the dataflow paradigm. the term `gobj' is not really a 'graphical' object, but more a 'patchable' object ... > External programs, whether they are language > interpreters, virtual machines, visual programming environments or > whatever could just send messages to operate on the DSP graph and modify > attributes. I would love to write a live-coding system in Ruby some day... i would be quite interested in a way to define dataflow graphs in a scripting language, but didn't find a decent syntax, yet ... last year, i tried to write an api to define nova patches in python, however the syntax was not really usable ... (it can be found in the patch-generator subfolder in the git archive) cheers, tim -- [EMAIL PROTECTED] http://tim.klingt.org After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
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
