Hi Joaquin & Jeanette.
The problem here is that the overrun is occurring in the ftmorf iftfn table which might have say only 16 points (values) in the table (pointing to 16 tables in the wavetable), so unfortunately adding a guard point will not help. Neither will adding a guard point to the tables in the wavetable.
It’s important to mention the example I sent Jeanette that she is referring to was what led to some confusion, and it was problematic as I’ve now realized. Hence her asking the question here. Apologies to Jeanette, it was a gap in my understanding of ftmorf that raised the issue. The Canonical manual example doesn’t really detail the specifics of the iftfn index being allowed (or in some cases not allowed) to wrap back to the end of the first table clearly. Or perhaps I just didn’t understand it correctly.
And Jeanette, since we’ve been emailing about a specific usage, we can discuss seperately about the possible issue regarding -1 vs -1.001 and why one may be problematic, if not for further input. It’s still a small mystery although I have unproven suspicions.
Here’s an example that demonstrates the basic issue & explains a little about ftmorf in case others encounter a similar problem in the future:
sr = 48000
ksmps = 32
nchnls = 1
0dbfs = 1
giftfn ftgen 0, 0, 4, -2, 1, 2, 3, 4
giresfn ftgen 0, 0, 2048, 10, 1
giTab1 ftgen 1, 0, 2048, 10, 1
giTab2 ftgen 2, 0, 2048, 10, 0, 1
giTab3 ftgen 3, 0, 2048, 10, 0, 0, 1
giTab4 ftgen 4, 0, 2048, 10, 0, 0, 0, 1
giftfn2 ftgen 0, 0, -4, -2, 1, 2, 3, 4
instr 1
kNdx = linseg(0, p3, p4)
printk .5, kNdx
ftmorf kNdx, giftfn, giresfn
aSig = poscil(.8, 220, giresfn)
out(aSig)
endin
instr 2
kNdx = linseg(0, p3, p4)
printk .5, kNdx
ftmorf kNdx, giftfn2, giresfn
aSig = poscil(.8, 220, giresfn)
out(aSig)
endin
i1 0 16 4
i1 17 . 5
i2 34 16 4
e
Ftmorf obviously morphs between the tables. As soon as the index passes 0 it starts to morph into the adjacent table. It does allow morphing (allowing some wrapping) from the final table back to the end of the non-adjacent first table, but no futher.
If there are 4 tables, as you pass the beginning of the index of the 4th table (>3), it “wraps” far enough to allow reaching the end of the first table again. But no further. It will not show the index is unavailable nor report any error. But it will suddenly make a quirky leap from the end of the first table straight to the final table & just hang there. I guess it’s not actually leaping but still playing the final table & no longer able to morph, it just sounds like a leap.
The Canonical example does not reflect that the final table can morph back thru the end of the first. You can replace the line:
kndx line 0, p3, 7
with
kndx line 0, p3, 8
and it works.
So ftmorf will also allow index values well beyond the final table number, but in that case it’s generally only playing the final table.
However, if the iSize of the iftfn is negative, then once the kNdx passes the beginning of the final table it will not allow wrapping or morphing back to the first table. The code will stop and report an index error.
The code above demonstrates this. The max index values for linseg are p4 in the score. In the first score example, you can clearly hear the final table wrap back to the end of the first - playing only the fundamental.
In the second example, once the kNdx wraps and reaches the end of the first table, it does the aforementioned “jump” from the fundamental to the final table & hangs there.
The third score example simply replaces the giftfn table with a negative size (-4) table (giftfn2). In this case, as soon as kNdx passes a value of 3, as can be seen in the console print, the code stops and reports an error. It will not attempt to morph back to the first table; with 4 tables the max allowable index value is <=3, not <=4.
Scott