[PD] Zen Garden re-implementing the wheel in C++?

[Andy Farnell]

Giving up extensible generality and moving
from a linear structure to finite but
'big enough' adjacency matrix always
seemed the way to go. 

I'm not speaking for Martin on ZenGarden
though, I'm not sure what his current
ideas are, or even if its still active.

How did topoloical sorting of a list
work out in Nova Tim?

a.
 




On Sat, 17 Apr 2010 15:04 +0200
Tim Blechmann <tim at klingt.org> wrote:

> unfortunately, this is not a trivial issue.
> 
> dynamically changing the signal graph is possible (actually, i had an 
> implementation of that in nova). do the topological sorting in the 
> background and you are fine.
> 
> the tricky part are implicit dependencies. see this trivial patch:
> |adc~|
> |
> |send~ foo|
> 
> |receive~ foo|
> |
> |dac~|
> 
> it execution order is ambiguous. either (a) adc-send-receive-dac or
> (b) receive-dac-adc-send. the actual execution order depends on the 
> implementation. the case (b) introduces one sample block of latency between 
> send and receive, (a) doesn't introduce any latency.
> without the loss of generality, lets assume that the actual order of the dsp 
> graph is (b). now you add a connection between adc~ and dac~. the 
> topological sorting of the dsp graph may come to the execution order (a). 
> adding the connection, you change the layout of the signal graph, changing 
> the order of send~ and receive~ and therefore its semantics. you actually 
> loose one sample block and therefore have an audio dropout.
> 
> if there are any possibilities to circumvent this issue, i haven't found 
> any. for special cases, it works, but whenever implicit dependencies have to 
> be taken into account, things are getting very messy. if you want to have 
> dynamically changing signal graphs, don't use max-like languages. it is not 
> a problem of the implementation, it is a problem of the programming model in 
> general! if you need dynamically changing signal graphs, you should use a 
> system, that is designed for this use case.
> 
> cheers, tim
> 
> 
> > Yes. This was a design goal from early on.
> > A dynamically rewritable signal graph is
> > quite essential to advanced procedural audio.
> > 
> > On Sat, 17 Apr 2010 12:04:09 +0200
> > Tim Blechmann <tim at klingt.org> wrote:
> > 
> >> > I'm excited about the idea of a more object-oriented approach, and
> >> > especially with the idea of ditching all the Tk/Tcl garbage, but I
> >> > don't really see the utility of re-implementing all the DSP graph
> >> > code.
> >> 
> >> depending on their implementation, it may be possible to do click-free
> >> changes of the dsp graph, which is the weakest part of the dsp engine of
> >> pd. from my understanding impossible to fully eliminate audio dropouts
> >> when changing max-like signal graph, since the implicit resource access
> >> order may change, depending on the use case.
> >> 
> >> tim
> 
> -- 
> tim at klingt.org
> http://tim.klingt.org
> 
> Happiness is a byproduct of function, purpose, and conflict; those who
> seek happiness for itself seek victory without war.
>   William S. Burroughs
> 
> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


-- 

-----------------------------------------------------------
Sent from my 3 (http://three.co.uk) mobile broadband
   Third world internet for a first world economy.
* 20 bytes/second * 99% packet loss  * 60 second latency
 All for only £20/month (Odious and predatory terms apply)