[PD] elucidation on syncing r~'s

[Tim Blechmann]

> from what you say, I understand that in order to force a certain
> directin of DSP flow (either directly, or as in the execution order
> example), I *have* to use patch cords in one way or the other. OK.
this is sadly true ...

> I admit that I am rather clueless with respect to core programming,
> but if that is the information that is needed by pd to sort things
> right, then implementing a "substitute patch cords by
> send~/receive~"-feature wouldn't seem especially non-trivial to me
> (although it is certainly more work than I imagine at the moment).
not as easy as it seems ... with s~/r~, you can easily have loops in
the dsp graph ... it only adds a block delay ... 
i once had a look at it ... isn't that trivial as it seems...
the biggest problem is ... the graphical representation is _exactly_
the same as the internal representation ...
this makes it pretty straight forward to use it, but has some severe
limitations ... in theory, it should be possible to optimize both dsp
and message graph ... but i see very little hope to implement this in
pd ...

cheers ... tim

-- 
mailto:TimBlechmann at gmx.de    ICQ: 96771783
http://www.mokabar.tk

latest mp3: kMW.mp3
http://mattin.org/mp3.html

latest cd: Goh Lee Kwang & Tim Blechmann: Drone
http://www.geocities.com/gohleekwangtimblechmannduo/

After one look at this planet any visitor from outer space 
would say "I want to see the manager."
				      William S. Burroughs