[PD] d-median (a running median) + d-for (a for loop)

[Damian Stewart]

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.

:-)

-- 
damian stewart | skype: damiansnz | damian at frey.co.nz
frey | live art with machines | http://www.frey.co.nz