This still doesn't make sense to me. Anything coming from the second outlet of the pointer should be discarded, and the until ought to keep moving the pointer forward until something comes from either the first or third outlet. If the 2nd outlet stopped the [until], there would be no point having the patch, and if it is connected to a [next( message, as it was before, it could lead to a stack overflow, as message after message triggers that outlet when searching for a single tempo marker among hundreds of notes.
On 3/26/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
But I don't understand why the attached patch doesn't work.
It's actually quite easy: You need to connect the second outlet of the [pointer] to a [next( message or the [until]'s right inlet as well. Otherwise if the pointer finds a structure first, that is not of type "$1", the until will never stop and Pd will freeze.
However [until] still can be a very dangerous object. In fact, I stopped using [until] for pointer-traversal, because a similar freeze will happen, if you bang the JInextB when [pd score] doesn't exist! And nothing will be able to stop the [until] in that case. A workaround is possible, though: For that, you don't start the [until] through the inlet, but you use the first pointer found by [pointer] to start the [until] loop (with [t p b]). You will have to take care then to not start the [until] several times ...
I attached a version of JINext which does all this and should be pretty save now against accidentally starting the [until] without stopping it.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-- "It is not when truth is dirty, but when it is shallow, that the lover of knowledge is reluctant to step into its waters." -Friedrich Nietzsche, "Thus Spoke Zarathustra"