[Pd] Stack Overflow

[Chuckk Hubbard]

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 at 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"