Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
I get this all the time. It's a real problem, because in a longer score it usually means the first half of the score has had all its notes changed to a new reference pitch and the second half hasn't, and there's no way back from that but to reload the piece.
I have a "JInext" abstraction I made, which takes a bang or a next message, and finds the next $1 scalar in pd-score. Because I have a vertical line on each beat, and octave marking lines, and tempo markers, plus notes, it has to skip past a lot of other templates.
You could implement the beat, octave etc. lines as arrays instead of as single structs.
Then even a long score with 1000 beat lines will just contain one single "beatgrid" struct. And it's even much easier to patch.
An example is attached.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Thanks. That is an interesting example. I have mixed meters, and not all beats are quarter notes, so I'd have to experiment... I like VERY much that the beat lines cannot be accidentally selected while selecting notes. Still, I have tempo markers at irregular intervals in the score, and isolating them involves more skipping (of notes) than isolating the notes does. Neither notes nor tempo markers could be put in an array, because both can be added at any time and have to be sorted according to X before being played back.
Actually, playback works fine; it is when the patch steps through the score all at once, to transpose all notes, that I run into overflow errors. I'll try deleting all the beat lines and see if it works that way, and if so then your solution might work.
-Chuckk
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
Thanks. That is an interesting example. I have mixed meters, and not all beats are quarter notes, so I'd have to experiment...
You can also add a "float x" field to the array element structure ("beat"), then each beatline will specify its own spacing and "spacing" in "beatgrid" will be ignored. Acually you can also delete the "float y" field, as your beat lines probably don't need to be moved in vertical direction, at least not as single lines, only as a group.
Still, I have tempo markers at irregular intervals in the score, and isolating them involves more skipping (of notes) than isolating the notes does. Neither notes nor tempo markers could be put in an array, because both can be added at any time and have to be sorted according to X before being played back.
Arrays are always sorted. However I understand what you mean, and I agree that arrays are not useful for that kind of data.
Actually, playback works fine; it is when the patch steps through the score all at once, to transpose all notes, that I run into overflow errors.
Ah, that's interesting, so you may already have a solution to your problem. You could try to do the transposing stuff with the same and working algorithm of the playback stuff. Like playback on speed. ;) You probably have a tempo control. If you play back at a very high tempo, do you get stack overflows as well? If not, then you should be able to rework the transposing stuff tobe similar to playback, only faster.
ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Instead of changing the recursion inside my "next" abstraction, I changed the fact that its output of the requested scalar was what triggered the search for the next one... an external [until] object now triggers it to find each scalar. A bang message is sent to the "next" object first, to avoid an empty pointer error, and then until sends the "next" message. The bang from the pointer at the end of the list turns it off. The recursion inside the "next" abstraction is only ever as deep as the number of scalars before the next requested scalar, which apparently isn't enough to cause an error for most things.
But I don't understand why the attached patch doesn't work. Using my recursive patch, I get no "empty pointer" errors, no matter what I do in the program, from the abstraction. However, this [until] version freezes my system, and the only way that would seem to be possible is if a "next" message were sent without a "bang" message having been sent first.
Actually, playback works fine; it is when the patch steps through the score all at once, to transpose all notes, that I run into overflow errors. I'll try deleting all the beat lines and see if it works that way, and if so then your solution might work.
-Chuckk
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__
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"
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
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.
Ah, yes, of course you're right here, I somehow did get this wrong, bad coffee for breakfast. :(
I'll try again - this is from your previous mail:
But I don't understand why the attached patch doesn't work. Using my recursive patch, I get no "empty pointer" errors, no matter what I do in the program, from the abstraction. However, this [until] version freezes my system, and the only way that would seem to be possible is if a "next" message were sent without a "bang" message having been sent first.
If you send a "next" before you send a "bang" to "JInextB", you get a stack overflow. But you *also* get a stack overflow, if you send a "next" *after* you have reached the end of the structures list.
You get this because there is nothing stopping the until: Instead of a pointer out of the first or a bang out of the End_Of_List outlet of the pointer object, you just get a console messages saying:
error: ptrobj_next: no current pointer
You can check this yourself if you replace the [until] with a [bang] message and press [next( manually until you reach the end of the list, then press [next( again. There will be no output to any of the two outlets of [JInextB], so there will be nothing to stop the [until] (which thankfully only is a [bang] now).
The patch I posted earlier does fix this, as it's not the incoming message, that starts the [until] loop, but anything, that is:
a) not a wanted pointer of type $1 and b) not the end of the list.
And this thing, that is "not a and not b", is a pointer from the second (middle) outlet.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Yes. I was going nuts trying to figure this out, when I detached the inlet in my [until] version and it suddenly worked using your testing print objects. Apparently it is the way I have it implemented in my patch: its own left outlet is still set up to retrigger the inlet. I didn't have any stray [next( messages going in, that was what was confusing me; because if there were, my previous version should have given empty pointer errors, and it didn't.
I don't know how else to implement this, without its output retriggering it. I did fix my transposing function, pretty much, so the old recursive JInext patch is doing all its jobs fine. It's just not realistic to try to revamp my whole sequencing function this close to my finals (this program isn't for credit).
One problem I still run into with my transposer is float accuracy. I can enter a chord on 1/1, 5/4, 3/2, 7/4, and 9/4, and then hover my cursor over 7/4 and hit T, and everything shifts so that 7/4 becomes 1/1. Then I can enter the same chord, hover my mouse over 7/4 again, and hit T, and 7/4 becomes 1/1, so that the original 1/1, middle C, is now 16/49. Theoretically, over the course of a long piece, this could happen any number of times, but in reality Pd seems to have limits. If I hit G while the score patch is active, everything reverts to the original 1/1, so the previous 7/4 would become 49/16. But if I've gone through enough modulations since the beginning, sometimes I get "1e-.006" type numerators and denominators. I inserted a fraction simplifying patch, which divides prime numbers up to 11 from numerator and denominator, which helps, but I still have limits. Now I'm wondering: a) is it possible to use integers as a type for a struct field? b) what are the limits on Pd's float accuracy?
Thanks. -Chuckk
On 3/26/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
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.
Ah, yes, of course you're right here, I somehow did get this wrong, bad coffee for breakfast. :(
I'll try again - this is from your previous mail:
But I don't understand why the attached patch doesn't work. Using my recursive patch, I get no "empty pointer" errors, no matter what I do in the program, from the abstraction. However, this [until] version freezes my system, and the only way that would seem to be possible is if a "next" message were sent without a "bang" message having been sent first.
If you send a "next" before you send a "bang" to "JInextB", you get a stack overflow. But you *also* get a stack overflow, if you send a "next" *after* you have reached the end of the structures list.
You get this because there is nothing stopping the until: Instead of a pointer out of the first or a bang out of the End_Of_List outlet of the pointer object, you just get a console messages saying:
error: ptrobj_next: no current pointer
You can check this yourself if you replace the [until] with a [bang] message and press [next( manually until you reach the end of the list, then press [next( again. There will be no output to any of the two outlets of [JInextB], so there will be nothing to stop the [until] (which thankfully only is a [bang] now).
The patch I posted earlier does fix this, as it's not the incoming message, that starts the [until] loop, but anything, that is:
a) not a wanted pointer of type $1 and b) not the end of the list.
And this thing, that is "not a and not b", is a pointer from the second (middle) outlet.
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"
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
Yes. I was going nuts trying to figure this out, when I detached the inlet in my [until] version and it suddenly worked using your testing print objects. Apparently it is the way I have it implemented in my patch: its own left outlet is still set up to retrigger the inlet. I didn't have any stray [next( messages going in, that was what was confusing me; because if there were, my previous version should have given empty pointer errors, and it didn't.
I don't know how else to implement this, without its output retriggering it. I did fix my transposing function, pretty much, so the old recursive JInext patch is doing all its jobs fine. It's just not realistic to try to revamp my whole sequencing function this close to my finals (this program isn't for credit).
If you want to do this later, I have a small addition: The [spigot] stuff turned out to be unnecessary. Triggering the until multiple times in my patch doesn't change or break anything. I attached a cleaned up version of the example I did, called "ds-traverse". It should be possible to use as a drop-in replacement for JInext with the supplied wrapper called "JInext-dropin.pd", which has exactly the same interface as your JInext.pd.
Now I'm wondering: a) is it possible to use integers as a type for a struct field?
No, I don't think so: only float, symbol, array and list are possible types in struct-definitions.
b) what are the limits on Pd's float accuracy?
There is a thread going on about this currently, you should have it in your mailbox, it's subject is "32bit integer float".
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
I solved this problem in a far simpler way than I foresaw. I included in the patch two experiments I used to understand the [delay] object. In the lower one, if you disconnect the delay and make the connections directly to their destinations, there are stack overflows. This version of JInext works with no catches in all of its roles.
-Chuckk
On 3/26/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
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.
Ah, yes, of course you're right here, I somehow did get this wrong, bad coffee for breakfast. :(
I'll try again - this is from your previous mail:
But I don't understand why the attached patch doesn't work. Using my recursive patch, I get no "empty pointer" errors, no matter what I do in the program, from the abstraction. However, this [until] version freezes my system, and the only way that would seem to be possible is if a "next" message were sent without a "bang" message having been sent first.
If you send a "next" before you send a "bang" to "JInextB", you get a stack overflow. But you *also* get a stack overflow, if you send a "next" *after* you have reached the end of the structures list.
You get this because there is nothing stopping the until: Instead of a pointer out of the first or a bang out of the End_Of_List outlet of the pointer object, you just get a console messages saying:
error: ptrobj_next: no current pointer
You can check this yourself if you replace the [until] with a [bang] message and press [next( manually until you reach the end of the list, then press [next( again. There will be no output to any of the two outlets of [JInextB], so there will be nothing to stop the [until] (which thankfully only is a [bang] now).
The patch I posted earlier does fix this, as it's not the incoming message, that starts the [until] loop, but anything, that is:
a) not a wanted pointer of type $1 and b) not the end of the list.
And this thing, that is "not a and not b", is a pointer from the second (middle) outlet.
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"
I mean this version of JI next.
On 4/5/06, Chuckk Hubbard badmuthahubbard@gmail.com wrote:
I solved this problem in a far simpler way than I foresaw. I included in the patch two experiments I used to understand the [delay] object. In the lower one, if you disconnect the delay and make the connections directly to their destinations, there are stack overflows. This version of JInext works with no catches in all of its roles.
-Chuckk
-
Chuckk Hubbard -
Frank Barknecht