[Csnd] ftmorf / table creation issue
| Date | 2023-09-05 23:43 |
| From | "Jeanette C." |
| Subject | [Csnd] ftmorf / table creation issue |
Hey hey,
we seem to have come up against an issue with either ftmorf or table creation.
There are two examples, one using fixed table creation of iftfn with all
numbers of the waves hard coded and stored in giTables. This examples creates
16 waves and has a kIndex to ftmorf that goes up to 32, with verified printing
and it works.
Then there is another example, where I create a blank GEN02 table:
iWavetable = ftgen(0, 0, -iSize, 2, 0)
Then the table is filled with dynamically allocated ftable numbers. Those are
also verified. The kIndex to ftmorf runs up to exactly ftlen(iWavetable) -1
and it fails with ftmorf complaiining about table number 0 being invalid.
Using ftsave to store the iftfn to disk, I see that the saved values are one
more than the reported size and that the last value is 0. Could this have
anything to do with it?
Further checks in the code prove that kIndex never goes above
ftlen(iWavetable) -1. I put an if-statement afterwards. Using
ftlen(iWavetable) - 1.001 works.
Still, can anyone see a reason why ftmorf can wrap around in one case and not
in the other? If you need good example code, I'd have to condense both
orchestras down to a sensible minimum.
Best wishes,
Jeanette
--
* Website: http://juliencoder.de - for summer is a state of sound
* Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g
* Audiobombs: https://www.audiobombs.com/users/jeanette_c
* GitHub: https://github.com/jeanette-c
'Cause living in a dream of you and me
Is not the way my life should be... <3
(Britney Spears)
Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here |
| Date | 2023-09-06 00:11 |
| From | joachim heintz |
| Subject | Re: [Csnd] ftmorf / table creation issue |
could it have to do with the "guard point"?
victor did some good explanations, perhaps here in the list. it might
be worth to search for it.
On 05/09/2023 19:43, Jeanette C. wrote:
> Hey hey,
> we seem to have come up against an issue with either ftmorf or table
> creation. There are two examples, one using fixed table creation of
> iftfn with all numbers of the waves hard coded and stored in giTables.
> This examples creates 16 waves and has a kIndex to ftmorf that goes up
> to 32, with verified printing and it works.
>
> Then there is another example, where I create a blank GEN02 table:
> iWavetable = ftgen(0, 0, -iSize, 2, 0)
> Then the table is filled with dynamically allocated ftable numbers.
> Those are also verified. The kIndex to ftmorf runs up to exactly
> ftlen(iWavetable) -1 and it fails with ftmorf complaiining about table
> number 0 being invalid.
>
> Using ftsave to store the iftfn to disk, I see that the saved values are
> one more than the reported size and that the last value is 0. Could this
> have anything to do with it?
>
> Further checks in the code prove that kIndex never goes above
> ftlen(iWavetable) -1. I put an if-statement afterwards. Using
> ftlen(iWavetable) - 1.001 works.
>
> Still, can anyone see a reason why ftmorf can wrap around in one case
> and not in the other? If you need good example code, I'd have to
> condense both orchestras down to a sensible minimum.
>
> Best wishes,
>
> Jeanette
>
Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here |
| Date | 2023-09-06 01:23 |
| From | "Jeanette C." |
| Subject | Re: [Csnd] ftmorf / table creation issue |
Sep 6 2023, joachim heintz has written:
> could it have to do with the "guard point"?
Hm, it seems to have more to do with the actual size, power of two or
not, and the way the size is specified, negative or positive. A positive
size parameter with a power of two size, _APPEARS_ to solve the issue.
Besides, I tried power of two + 1 as well.
Best wishes and thanks,
Jeanette
> victor did some good explanations, perhaps here in the list. it might be
> worth to search for it.
>
>
> On 05/09/2023 19:43, Jeanette C. wrote:
>> Hey hey,
>> we seem to have come up against an issue with either ftmorf or table
>> creation. There are two examples, one using fixed table creation of iftfn
>> with all numbers of the waves hard coded and stored in giTables. This
>> examples creates 16 waves and has a kIndex to ftmorf that goes up to 32,
>> with verified printing and it works.
>>
>> Then there is another example, where I create a blank GEN02 table:
>> iWavetable = ftgen(0, 0, -iSize, 2, 0)
>> Then the table is filled with dynamically allocated ftable numbers. Those
>> are also verified. The kIndex to ftmorf runs up to exactly
>> ftlen(iWavetable) -1 and it fails with ftmorf complaiining about table
>> number 0 being invalid.
>>
>> Using ftsave to store the iftfn to disk, I see that the saved values are
>> one more than the reported size and that the last value is 0. Could this
>> have anything to do with it?
>>
>> Further checks in the code prove that kIndex never goes above
>> ftlen(iWavetable) -1. I put an if-statement afterwards. Using
>> ftlen(iWavetable) - 1.001 works.
>>
>> Still, can anyone see a reason why ftmorf can wrap around in one case and
>> not in the other? If you need good example code, I'd have to condense both
>> orchestras down to a sensible minimum.
>>
>> Best wishes,
>>
>> Jeanette
>>
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
> https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
--
* Website: http://juliencoder.de - for summer is a state of sound
* Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g
* Audiobombs: https://www.audiobombs.com/users/jeanette_c
* GitHub: https://github.com/jeanette-c
'Cause living in a dream of you and me
Is not the way my life should be... <3
(Britney Spears)
Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here |
| Date | 2023-09-06 04:22 |
| From | ST Music |
| Subject | Re: [Csnd] ftmorf / table creation issue |
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: <CsInstruments> 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 </CsInstruments> <CsScore> i1 0 16 4 i1 17 . 5 i2 34 16 4 e </CsScore> </CsoundSynthesizer> 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 On Tue, Sept 5, 2023, 6:43 p.m. Jeanette C. <julien@mail.upb.de> wrote: Hey hey, |