I have the following in a patch to create a gating effect...
_______________
/ \
synth-patch /
| | |
| |(fx return) |
| dcm100mixtab/cm_dcm100 |
| |(fx send) |
| | |
| [env~ 64] |
| | |
| [expr 100-$f1] |
| | |
| [dbtorms] |
| | |
| [sig~] |
| | |
| [lop~ 10] |
| | |
[*~ ] |
| |
\ /
____________________________________/
...and it works fine, there is no DSP loop. But when I put all the objects (apart from the synth-patch and the mixer) into an abstraction fxgate.pd, so it looks like this...
__ __ synth-patch
/ \ / \ |
[dcm100mixtab/cm_dcm100] X [fxgate] __/ __/
...Pd throws up an error about a DSP loop. In fact there is no real loop because it works fine with the abstraction replaced by the objects it contains.
Is there a chance Pd's loop detection behaviour could be changed so that this useful design pattern of mixer effect sends/returns could be used within Pd DSP? I.e., expand loop detection to consider abstractions/subpatches as collections of objects rather than as single objects.
BTW, I tested also with a [pd ...] subpatch and that threw up the same DSP loop error.
...Pd throws up an error about a DSP loop. In fact there is no real loop because it works fine with the abstraction replaced by the objects it contains.
BTW, I tested also with a [pd ...] subpatch and that threw up the same DSP loop error.
Last April I took it onto myself to find a DSP Loop solution. My answer is here:
http://iem.at/mailinglists/pd-list/2004-04/019516.html
The key was to use [send~] and [receive~] pairs, and somehow this keeps PD from discovering any DSP loops. Let me know if that helps!
d.
-
ClaudiusMaximus -
derek holzer