Thanks Mathieu,
however, it is not that easy: no loops in my patches (I wouldn't have been able to substitute them by patch cords would I), but nonetheless delays between r~s.
That information is all before your eyes. Just follow your patch >backwards to see where the signal you are send~ing is coming from. If the object you're sending to is _also_ a place where the signal came from (i mean >any signal contributing to what you're send~ing), then you get a chicken-and-egg dependency. Pd then solves that problem by delaying the sent signal so that it only has an impact at the next "instant" in the future, that is, one block away.
--Matthias
however, it is not that easy: no loops in my patches (I wouldn't have been able to substitute them by patch cords would I), but nonetheless delays between r~s.
patch cords and audio busses (send~, catch~) are working completely different ... patch cords are compiled into the dsp graph, audio busses aren't ... you can rely on patch cords, you can't rely on busses...
i'd prefer to have the as part of the dsp graph, too and only resulting block delays if necessary (feedback), but this would require some non-trivial changes to pd's dsp core ... this would especially be tricky, if dsp chains would be changed from one monolithic dsp chain to segmented dsp chains...
cheers .... tim
Hallo, Matthias Blau hat gesagt: // Matthias Blau wrote:
however, it is not that easy: no loops in my patches (I wouldn't have been able to substitute them by patch cords would I), but nonetheless delays between r~s.
Did you read 3.audio.examples/G05.execution.order.pd and see if this helps in your case? (Maybe the patch has another name in your Pd installation, search for "execution.order".)
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "plak" @ http://footils.org/cms/show/44
Thanks Frank and Tim,
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.
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).
--Matthias
Frank Barknecht schrieb:
Hallo, Matthias Blau hat gesagt: // Matthias Blau wrote:
however, it is not that easy: no loops in my patches (I wouldn't have been able to substitute them by patch cords would I), but nonetheless delays between r~s.
Did you read 3.audio.examples/G05.execution.order.pd and see if this helps in your case? (Maybe the patch has another name in your Pd installation, search for "execution.order".)
Ciao
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
On Fri, 26 Aug 2005, Matthias Blau wrote:
however, it is not that easy: no loops in my patches (I wouldn't have been able to substitute them by patch cords would I), but nonetheless delays between r~s.
Ok, it seems like I goofed and I don't know what I'm talking about. I'm rarely using the DSP and it shows.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
-
Frank Barknecht -
Mathieu Bouchard -
Matthias Blau -
Tim Blechmann -
Tim Blechmann