Hallo, David Powers hat gesagt: // David Powers wrote:
I am making a simple patch to automatically morph between parameters every so often. One idea for this is, if I end up VJing at the 6 am afterparty and I am too drunk, I can have it morph things for me and I can take a break. :) Well, I'm not sure if that is a joke, or if it's true.
Anyway, I know I'm doing something stupid with this patch, that causes it not to work right. The first time I run it, I hit bang, and it outputs twice to the print, instead of once - there is some kind of loop that I don't want.
The [s top] at the bottom will be read in again at the [r top] at the top and thus it will bang the [pack] twice at the first start.
Why does it do so? Because you didn't use [trigger] and have "fanned" connections in your patch at a crucial place: the outlet of [pd get_new_target]. Always use [t] where order might matter. Always.
So, the outlet of [pd g_n_t] goes to both the pack and the select. But which one will get it first? It's undefined without trigger. In your patch currently the [pack] gets it first, then the [select]. So at the first random number, lets call it A, [pack] will start a ramp from 0 to A, and [select] will first look for a 0, then for A. It will get the zero immediatly from the pack->line, because [line] starts at 0, so "change->sel->s top" will bang and reinitiate a new random number, lets call it B. B will get send to both [pack] and [select] again. In your patch, again the [pack] will get it first, then the [select], however actually the order is undefined as you didn't use [trigger].
So while [line] still is trying to reach A, [select] now is waiting for B which it might never see, if B is not in the range 0,...,A.
So to fix your patch, the old saying stays true: Pd stands for "Pull da trigger!"
Btw: You could also replace the [== 0][change][sel 1] construct with a simple [del] whose delaytime you set from the "[random 3000] + 500".
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__