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

[Roman Haefeli]

On Fri, 2008-10-17 at 17:59 +0200, Damian Stewart wrote:
> 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:

and it becomes a lot easier when grouping stuff together from the
beginning. this is at least what i believe and have experienced.
debugging execution order doesn't need to be hard, if you apply certain
paradigmes when patching. personally, i almost always use only one send
symbol MYPATCH. then i give all parameters in use meaningful labels:

[freq $1(
|
[s MYPATCH]

as i said in the previous post, the receiving side should only go into
cold inlets, if possible:

  [r MYPATCH]
  |
  [route freq]
  |
[X ]

when debugging execution order, you only need one single print to
monitor your patch:

[r MYPATCH]
|
[print DEBUG]

yo, after all, i still think, that everyone has and should have their
own personal patching style. however, i find it interesting to confront
different styles with each other.

roman




		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de