Hallo, Damian Stewart hat gesagt: // 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]
and debugging execution order problems when things are sub-patched, for example: no thanks.
The important trick is to build your execution order into the order of your subpatches (i.e. to model the subpatches after the execution order).
For example [pd increment-timetag] from above is a separate step in the logic, that has to be activated before all the steps that come after it. So it's put on top of most of the other actions and the graphical layout mimicks the logic flow.
Inside of these subpatches I generally have a construct like this:
[inlet | [t a a] | | | ... do subpatch task | [outlet]
Actually I even have a template subpatch for this, which gets copied and renamed first, then filled later.
This way the subpatch finishes all its work, after that the incoming data gets sent along through the first trigger outlet to activate the next subpatch. It could send along a simple bang, but in d-median.pd I think, passing along the new float value would be appropriate, too.
That's divide and conquer - and order.
This approach may not be needed all the time, but I found it immensly helpful when dealing with complicated algorithms with lots of steps. For example I used it for the Turing machine simulator: http://footils.org/cms/show/58 (see the [pd logic] subpatch there).
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?
Then I probably didn't use the right number and order of subpatches yet. ;)
Ciao
Frank