Hi,
This kind of follows on from the recent thread about settable [s]. One thing I have never understood about PD, is why only one side of the [catch~]/[throw~], [s~]/[r~] is settable, and why it is the sender with the former, and the receiver with the latter?
It would be a really useful feature for me to have at least one of these settable at both ends. I am achieving this at the moment with a dynamic patching kludge, but it is quite nasty.
Does anyone think this is worth adding as a feature request, or know an alternate method (without externals).
Jamie
hi Jamie
it'd be nice to have a setable r~/s~ or catch~/throw~... attached a solution with throw~ -> catch~ -> s~ -> r~ so you can set both. that will delay the signal about 2 blocks :-( and i think it might not be suitable for dynamic patching since it will get an error without the catch~ or s~ .. good luck!
eni
On Aug 11, 2006, at 10:26 AM, Jamie Bullock wrote:
Hi,
This kind of follows on from the recent thread about settable [s]. One thing I have never understood about PD, is why only one side of the [catch~]/[throw~], [s~]/[r~] is settable, and why it is the sender with the former, and the receiver with the latter?
It would be a really useful feature for me to have at least one of these settable at both ends. I am achieving this at the moment with a dynamic patching kludge, but it is quite nasty.
Does anyone think this is worth adding as a feature request, or know an alternate method (without externals).
Jamie
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 2006-08-11 at 11:11 +0200, Enrique Erne wrote:
it'd be nice to have a setable r~/s~ or catch~/throw~... attached a solution with throw~ -> catch~ -> s~ -> r~ so you can set both. that will delay the signal about 2 blocks :-(
it will in the worst case, but in the best case there won't be any delay. this depends on creation order.
if you create: catch~ - throw~ and r~ - s~, you'll have a delay of two blocks.
if you create them in this order: throw~ - catch~ and s~ - r~, there is no delay at all.
if a certain pair causes a delay is dependent on where its objects are in the dsp-chain. of course a [r~] cannot read what its related [s~] not already has been written into the buffer, so it reads the buffer from the last cycle.
since the execution is considered not be defined, when someone connects an outlet with two inlets (which actually *is* defined, but you cannot see it), there should be also way of telling pd, in which order a [send~] should write and its [r~] should read. having to care about their creation order is kind of a hackish programming style.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Aug 11, 2006, at 10:26 AM, Jamie Bullock wrote:
Hi,
This kind of follows on from the recent thread about settable [s]. One thing I have never understood about PD, is why only one side of the [catch~]/[throw~], [s~]/[r~] is settable, and why it is the sender with the former, and the receiver with the latter?
because [s~]/[r~] is a 1-to-n connection (with n=0..N) and [throw~]/[catch~] is a n-to-n connection. making both ends settable in (one of) the two pairs, will eventually invalidate the "1"-side of this relation (and "1" is really a fixed size)
Enrique Erne wrote:
hi Jamie
it'd be nice to have a setable r~/s~ or catch~/throw~... attached a solution with throw~ -> catch~ -> s~ -> r~
i haven't looked at your patch, but this is the way to go: combine [catch~]+[send~] or [r~]/[throw~] to achieve whatever you want.
so you can set both. that will delay the signal about 2 blocks :-(
not if you have the correct execution order. (but probably i _should_ have a look at your patch)
mfga.dr IOhannes
and i think it might not be suitable for dynamic patching since it will get an error without the catch~ or s~ ..
IOhannes m zmölnig wrote:
On Aug 11, 2006, at 10:26 AM, Jamie Bullock wrote:
Hi,
This kind of follows on from the recent thread about settable [s]. One thing I have never understood about PD, is why only one side of the [catch~]/[throw~], [s~]/[r~] is settable, and why it is the sender with the former, and the receiver with the latter?
because [s~]/[r~] is a 1-to-n connection (with n=0..N) and [throw~]/[catch~] is a n-to-n connection.
oops!, of course [throw~]/[catch~] is a n-to-1 connection.
mfg.adr. IOhannes
On Fri, 11 Aug 2006 13:50:06 +0200 IOhannes m zmölnig zmoelnig@iem.at wrote:
IOhannes m zmölnig wrote:
On Aug 11, 2006, at 10:26 AM, Jamie Bullock wrote:
Hi,
This kind of follows on from the recent thread about settable [s]. One thing I have never understood about PD, is why only one side of the [catch~]/[throw~], [s~]/[r~] is settable, and why it is the sender with the former, and the receiver with the latter?
because [s~]/[r~] is a 1-to-n connection (with n=0..N) and [throw~]/[catch~] is a n-to-n connection.
oops!, of course [throw~]/[catch~] is a n-to-1 connection.
This explains why you can't have multiple [catch~] or [s~] objects, but it doesn't explain why both ends of the connection can't be 'set' after the object has been instantiated. I can see how the existing scenario is useful if you want to [throw~] to a selection of fixed [catch~] objects, or [r~] from a selection of fixed [s~] objects. However, what happens if the number of buses isn't determined in advance? I want to have an arbitrary number of multiply instantiable abstractions containing [s~], [r~], [throw~] or [catch~] and control routings between them dynamically without patching.
Jamie
On Fri, 11 Aug 2006 11:11:35 +0200 Enrique Erne pd@mild.ch wrote:
hi Jamie
it'd be nice to have a setable r~/s~ or catch~/throw~... attached a solution with throw~ -> catch~ -> s~ -> r~ so you can set both. that will delay the signal about 2 blocks :-( and i think it might not be suitable for dynamic patching since it will get an error without the catch~ or s~ .. good luck!
eni
Thanks. That's a really useful idiom, which hadn't actually occurred to me. However, it only works if you define the buses in advance i.e. once they are defined, you can route arbitrarily between them.
best,
Jamie