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