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

[Andy Farnell]

That would have been the function of a versatile
[z~] object in my mind. Default would be [z~ -1]
or a one sample delay, and a second inlet would
allow [z~ -blocksize] to do what we normally
do with a [s~] and [r~].

There was one from Zexy that I used for a long
time time before I understood how Pd differs
from notated DSP, and that you can't actually
do things like make a phasor without setting
the blocksize to 1

To me the 'hidden' fucntionality of [s~/r~]
departs from "The diagram is the program" and
its far nicer to make these delays explicit
and visible. All the same, thats the way it is
and it's probably more pain than gain to 
upset it all now.


On Sat, 17 Apr 2010 09:33:20 -0400
Spencer Russell <spencer.f.russell at gmail.com> wrote:

> On Sat, Apr 17, 2010 at 9:04 AM, 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
> >
> 
> I've actually wondered this for a while: Why is it that send~ and
> receive~ objects require special treatment instead of being treated
> the same as any other edge in the graph? I understand that in the
> current implementation using s~ / r~ pairs is the only way to create a
> graph with cycles (or fake the effect of one, anyways), but it doesn't
> seem obvious to me that that is the only valid way to go about it.
> 
>  If they were just "invisible wires" then cycles would require other
> treatment, obviously, but it seems like cycles could be "broken" and
> turned into leaf nodes in the graph automatically, or by requiring the
> user to put a 1-block delay in explicitly, instead of letting the
> s~/r~ pair do double-duty and add the possibility for ambiguity as
> described above.
> 
> I suppose I would lean towards the 2nd method, to make sure the break
> point of the cycle is well defined.
> 
> -s
> 
> _______________________________________________
> 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)