Frank Barknecht wrote:
Normally I like it if there are lots of verbosely named subpatches when dealing with a complicated algorithm, i.e.:
[pd initialize] | [pd increment-timetag] | [pd send-new-x-value] | [pd loop-backwards-through-arrays] | [pd check-for-old-value] | [pd insert-sorted] | [pd output-median]
yeah this is a smart move. i'd probably do it that way if i was re-implementing things. while developing this i had a clearish understanding of more-or-less how to make it work; but there was also a considerable amount of making-it-up-as-i-went-along in there too.
then again, this approach brings you head to head with the problem of what to do when each subpatch has to communicate multiple things to subpatches further down the line... do you pack and unpack at the inlets/outlets? do you have multiple inlets and outlets?
and debugging execution order problems when things are sub-patched, for example: no thanks. if you calculate something in step 3 and don't need it again until step 6, but it needs to be delivered to the step 6 objects _before_ the thing you calculated in step 4 but _after_ the thing you calculated in step 5 - what happens then? i find it's clearer to have those scary fanning connections coming out of trigger objects, in this case.. sometimes i really wish i could use DesireData's stepping functionality, because reverse engineering using print objects is awkward at best; but as it is there is no DesireData for OSX, and no-one seems interested in helping me make it work at the moment.
... and then, of course, it's always a bit hairy trying to separate stuff after the fact, because:
I wanted to make the patch clearer by separating stuff into more subpatches like this, but then I broke it. :(
: exactly.
:-)