That is because you are not reading point 16, but point 15. The table opcode will never overflow, it either limits or wraps around.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 8 Jan 2019, at 02:38, Pete Goodeve  wrote:
> 
> Well, I investigated some more, and now I'm even more confused!
> I decided I should forget MIDI and see how simple table lookups
> behave.
> 
> From the manual, I see:
> 
> "For arrays whose length is a power of 2, space allocation always provides
> for 2^n points plus an additional guard point.  If size is an exact power of 2,
> the guard point will be a copy of the first point. If size is set to 2^n + 1,
> the guard point value automatically extends the contour of table values."
> 
> So if, for example, I use this score statement:
> 
>  f1 0 16 7  0.2 16 1
> 
> I should get a table with index 0 containing 0.2 and index 15 = 1.0.
> According to the above, the guard point should contain 0.2 also.
> I expected that 'index 16' would access the guard point.
> 
> If I used a size of 17, keeping everything else the same, the
> table contents would be as before, but the guard would now be 1.0.
> 
> That's not what happens!  Here's my test code (run in 6.04):
> 
> 
> 
> 
> -m0 -odac
> 
> 
> 
> 
> instr 1
>    printks "16 points table -- no guard:\n", 1
>    giRamp = 1
>    ka = 0
>    kb table ka, giRamp
>    printks "%d:    %f\n", 1, ka, kb
>    ka = 15
>    kb table ka, giRamp
>    printks "%d:    %f\n", 1, ka, kb
>    ka = 16
>    kb table ka, giRamp
>    printks "%d:    %f\n", 1, ka, kb
>    printks "16 points table -- with guard:\n", 1
>    giRamp = 2
>    ka = 0
>    kb table ka, giRamp
>    printks "%d:    %f\n", 1, ka, kb
>    ka = 15
>    kb table ka, giRamp
>    printks "%d:    %f\n", 1, ka, kb
>    ka = 16
>    kb table ka, giRamp
>    printks "%d:    %f\n", 1, ka, kb
>    endin
> 
> 
> 
> 
> f1 0 16 7  0.2 16 1
> f2 0 17 7  0.2 16 1
> i1 0 0.1
> 
> 
> 
> 
> 
> The result is:
> 
> 16 points table -- no guard:
> 0:    0.210526
> 15:    1.000000
> 16:    1.000000
> 16 points table -- with guard:
> 0:    0.200000
> 15:    0.950000
> 16:    0.950000
> 
> Not only am I not seeing the expected guard-point,
> but the normalization seems crazy!
> 
> What am I missing?
> 
>    -- Pete --
>    
> 
> 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

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

There's an iwrap parameter on table that will set wrap around.

As for normalisation: tables are rescaled by
default, so the abs max value is 1.0; that can be turned off when the table is generated.

Indexes can be raw entries (0-15), or normalised (0-1), depending on the 
imode parameter. In any case, you will
not read the guardpoint directly via table.

The guardpoint is used in interpolated lookup for an index n where size-1 < n < size
I guess with tablei and index 15.9999999
you would be very close to the value of
the guardpoint in your case.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 8 Jan 2019, at 22:03, Pete Goodeve  wrote:
> 
>> On Tue, Jan 08, 2019 at 07:00:08AM +0000, Victor Lazzarini wrote:
>> That is because you are not reading point 16, but point 15. The table opcode will never overflow, it either limits or wraps around.
> 
> OK, thanks.  It seems to limit (in both directions).  Is there any state
> in which it will wrap?  So I guess there is no way of seeing the guard
> point?
> 
> I still don't understand what the normalization is doing, though.
> The docs say it rescales so the maximum is 1.0.  So if the maximum
> is already 1.0 shouldn't it leave all the values alone?  Why is the
> value at index o raised?  And the maximum reduced if the table
> is longer than the points supplied?
> 
>> 
>>> ......
>>> The result is:
>>> 
>>> 16 points table -- no guard:
>>> 0:    0.210526
>>> 15:    1.000000
>>> 16:    1.000000
>>> 16 points table -- with guard:
>>> 0:    0.200000
>>> 15:    0.950000
>>> 16:    0.950000
>>> 
> 
> Thanks,
> 
>    -- Pete --
> 
> 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

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

Well, I don't know why the final example is not being rescaled. I would expect it to be
skipped. As for the first example, I think the 
rescaling must have had some sort of rounding that caused the first point to change. In the second case, I think the extended guard point must be 1.0 as it extends the contour, but the whole curve
is rescaled. Having one further point must 
be the reason why the start now is 0.2.

We need to check why rescaling has not been skipped, it could be a bug.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 9 Jan 2019, at 01:57, Pete Goodeve  wrote:
> 
>> On Tue, Jan 08, 2019 at 10:47:04PM +0000, Victor Lazzarini wrote:
>> There's an iwrap parameter on table that will set wrap around.
> Ahh, sorry.  I missed that parameter.
>> 
>> As for normalisation: tables are rescaled by
>> default, so the abs max value is 1.0; that can be turned off when the table is generated.
>> 
> I'm afraid it still isn't making sense to me...
> 
> If I have a 16-point, GEN07 say, normalized table:
> 
>  f1 0 16 7  0.2 16 1
> 
> I get:
> 
>  0:    0.210526
>  15:    1.000000
> 
> So the maximum is corectly 1.0, but why is the zero index rescaled??
> 
> If I add the guard-point:
> 
>  f2 0 17 7  0.2 16 1
> 
> the lower end is now correct, but why is the maximum reduced?:
> 
>  0:    0.200000
>  15:    0.950000
> 
> According to the f-statement docs, both the last value and the
> guard point should be the same, and I would think they ought to
> be scaled to 1.0.
> 
> Worse, I tried an unscaled table:
> 
>  f3 0 16 -7  0.2 16 1
> 
> and again I get:
> 
>  0:    0.200000
>  15:   0.950000
> 
> So it *is* being (wrongly) scaled!
> 
> If all this does mke sense, I'd love to know how! (:-/)
> 
> Thanks,
> 
>    -- Pete --
> 
> 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

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

yes, the index scaling should to 0 - size-1

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 9 Jan 2019, at 06:45, Pete Goodeve  wrote:
> 
> Sorry, but I have to revisit one more time...
> I got sidetracked by the normalization problem, but my original
> worry about ctrl7 going to zero at max is still valid.
> 
>> On Tue, Jan 08, 2019 at 07:00:08AM +0000, Victor Lazzarini wrote:
>> ... The table opcode will never overflow, it either limits or wraps around.
> 
> Obviously if this was true for ctrl7 also it couldn't snap back to 0
> at the top end.
> 
> So I took a look at the source, and here's the problem:
> 
> In midiops2.c:ictrl7:
> 
>          value = *(ftp->ftable + (int32)(value*ftp->flen)); /* no interpolation */
> 
> I haven;'t dug into table allocation, but I assume 'ftlen' would
> be 128 for a 128-point table (and for 129 too?).  So multiplying
> the original value -- scaled it seems 0..1.0 -- by ftlen is going to
> overflow into the guard point!
> 
> A ticket is appropriate, I guess.
> 
>    -- Pete --
> 
> 
> 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

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

As it turns out all opcodes related to that one were wrong. There was also no policing of value ranges, which could cause
memory access problems. I’ve fixed all of this now in git.
Thanks for the report
========================
Prof. Victor Lazzarini
Maynooth University
Ireland






> On 8 Jan 2019, at 02:37, Pete Goodeve  wrote:
> 
> Well, I investigated some more, and now I'm even more confused!
> I decided I should forget MIDI and see how simple table lookups
> behave.
> 
> From the manual, I see:
> 
> "For arrays whose length is a power of 2, space allocation always provides
> for 2^n points plus an additional guard point.  If size is an exact power of 2,
> the guard point will be a copy of the first point. If size is set to 2^n + 1,
> the guard point value automatically extends the contour of table values."
> 
> So if, for example, I use this score statement:
> 
>  f1 0 16 7  0.2 16 1
> 
> I should get a table with index 0 containing 0.2 and index 15 = 1.0.
> According to the above, the guard point should contain 0.2 also.
> I expected that 'index 16' would access the guard point.
> 
> If I used a size of 17, keeping everything else the same, the
> table contents would be as before, but the guard would now be 1.0.
> 
> That's not what happens!  Here's my test code (run in 6.04):
> 
> 
> 
> 
> -m0 -odac
> 
> 
> 
> 
> instr 1
> 	printks "16 points table -- no guard:\n", 1
> 	giRamp = 1
> 	ka = 0
> 	kb table ka, giRamp
> 	printks "%d:	%f\n", 1, ka, kb
> 	ka = 15
> 	kb table ka, giRamp
> 	printks "%d:	%f\n", 1, ka, kb
> 	ka = 16
> 	kb table ka, giRamp
> 	printks "%d:	%f\n", 1, ka, kb
> 	printks "16 points table -- with guard:\n", 1
> 	giRamp = 2
> 	ka = 0
> 	kb table ka, giRamp
> 	printks "%d:	%f\n", 1, ka, kb
> 	ka = 15
> 	kb table ka, giRamp
> 	printks "%d:	%f\n", 1, ka, kb
> 	ka = 16
> 	kb table ka, giRamp
> 	printks "%d:	%f\n", 1, ka, kb
> 	endin
> 
> 
> 
> 
> f1 0 16 7  0.2 16 1
> f2 0 17 7  0.2 16 1
> i1 0 0.1
> 
> 
> 
> 
> 
> The result is:
> 
> 16 points table -- no guard:
> 0:	0.210526
> 15:	1.000000
> 16:	1.000000
> 16 points table -- with guard:
> 0:	0.200000
> 15:	0.950000
> 16:	0.950000
> 
> Not only am I not seeing the expected guard-point,
> but the normalization seems crazy!
> 
> What am I missing?
> 
> 	-- Pete --
> 	
> 
> 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


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