> Actually, if we have the ability > to record all of the commands in a Nova session this could be really > useful. You could record a live session, and then later run it back > through Nova using some super high quality sample size (and maybe rate?) > for recording into an audio file...
well, this could already be done at the level of the patch ... one would just need to record all the messaging from within the nova language (once, there are good message sequencing objects ;) > > 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. > > How do these DSP contexts work? when putting a detaching object onto a canvas (e.g. a switch~ object), all dsp objects from this canvas are moved to a new dsp subgraph. subgraphs can be muted (switch~), run at a different vector-size and with a certain overlap factor, which is required for fft~ objects (once they are implemented). resampling is another issue, that will be solved with nested dsp contexts ... > > 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 ... > > Hmmm, I'm not sure I see the difference. In live-coding the synthesis > engine has to be optimized for live modification of the dsp chain and > object attributes as well right? in nova, changing the dsp graph is click-free, but it is not a cheap operation. i haven't done any benchmarks, but i guess, the delay time between new objects have been created and the dsp graph is updated can take quite some time ... and is proportional to the number of instantiated dsp objects. in supercollider, i guess, it is cheaper probably constant-time. in nova i am able to do a stronger optimization of the dsp graph, though ... > > 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 ... > > So maybe it should be p_obj? yes .. maybe it should be renamed :) cheers, tim -- [EMAIL PROTECTED] http://tim.klingt.org Just what the hell is the experimental tradition? Morton Feldman
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
