Array index out of range

[Ebmtranceboy]

Some combinations of array lengths, p2 and p3 raise PERF ERRORs due to array indices out of range.
See for example the following program where array length, initially 338 for a first note, becomes 319 for the next consecutive note:

<CsoundSynthesizer>
<CsOptions>
-odac
</CsOptions>

<CsInstruments>
sr = 44100
ksmps = 10
nchnls = 1
0dbfs = 1


    instr 1
    
icps    =   cpspch(p4)
ain     poscil  1,icps
  
ilen    =   int(sr/icps)+1
    print   ilen

kbuf[]  init    ilen
kidx    init    0
kval    init    0

aout    =   0
ksmp    =   0

while ksmp < ksmps do
    kin vaget ksmp, ain
    kbuf[kidx % ilen] = kval + kin
    
    kval = kbuf[(kidx + 6) % ilen]
    vaset kval, ksmp, aout

    kidx += 1
    kidx = kidx % ilen
    ksmp += 1
    od

    out aout/30

    endin

</CsInstruments>

<CsScore>
i1 0 2 7.00
i1 2 2 7.01
e
</CsScore>
</CsoundSynthesizer>

[vlazzarini]

the array length has changed because p4 has changed. Do you mean to say that internally, the array length hasn't changed and then there is a problem?

[vlazzarini]

Ok, I had a look at this. I think this is to do with initialisation of synthetic k-rate vars.
If I replace the line

kval = kbuf[(kidx + 6) % ilen]

with

kn = (kidx + 6) % ilen
kval = kbuf[kn]

and initialise kn to 0 at the top, the warning goes away.

kn init 0

If I remove the init line, the warning is back. So the synthetic var is not being initialised to 0. Not sure
whether it should or not (what is the expected behaviour?).

[kunstmusik]

Interesting, I wonder if array_get is working at init-time, and the synthetic var's value is leftover from the previous instrument instance that is getting reused.

[Ebmtranceboy]

Ok thank you Victor. What troubles me is that the warning (which is a PERF ERROR on my ubuntu system) refers to an index which can't logically be reached thanks to the modulo operator.

[vlazzarini]

Here it is a warning, maybe because the version I am using might be different to yours.
I think that's probably because the synthetic variable contains garbage, since the expression
is only computed at perf-time.

[Ebmtranceboy]

oh OK, so, knowing that, I should probably add another auxiliary variable for the kdix%ilen expression and initialise it to 0 too at the top for precaution.
This default behaviour seems OK to me (now).
Thanks again.
Tell me when you (and Steven) want me to close the issue.

[vlazzarini]

I'd leave it open until we can figure out it's not a bug.

[jpffitch]

I think this is a bug; there should be no activity at init time for temporary variables. I think this is a result of the array semantics

[jpffitch]

I see an asymmetry between array get and array set

birtwistle:/Sourceforge/csound/New/csound6> Search ##array_set.k0
./Opcodes/arrays.c: { "##array_set.k0", sizeof(ARRAY_SET), 0, 2, "", "k[]kz",
birtwistle:/Sourceforge/csound/New/csound6> Search ##array_get.k0
./Opcodes/arrays.c: { "##array_get.k0", sizeof(ARRAY_GET), 0, 3, "k", "k[]z",

so get runs at i anf k rate, but set only at k
One of these is wrong! Setting get to rate 2 removes this error -- but not sure what it does elsewhere!
Seems odd that kk=1 is k-rate but kk[0]=1 is i- and k-

[kunstmusik]

This looks to be a result of something I implemented for Issue #254. This is all very tricky as sometimes users will want to access array's at k-time but give a constant or i-rate sig as an index.

[jpffitch]

I could test my fix against your earlier issue if I had a test program

[kunstmusik]

@jpffitch There's a test CSD posted in the Nabble mailing list archive here:

http://csound.1045644.n5.nabble.com/csound6-getting-i-value-of-a-kArray-member-td5729623.html

[jpffitch]

OK; my patch breaks the older issue.

I still think it odd that kk=0 does not run at i-time but kkk[0]=0 does

On Mon, 9 Nov 2015, Steven Yi wrote:

@jpffitch There's a test CSD posted in the Nabble mailing list archive here:

http://csound.1045644.n5.nabble.com/csound6-getting-i-value-of-a-kArray-membe
r-td5729623.html

—
Reply to this email directly or view it on
GitHub.[AELNQnSOMvnRc2rd0wnBuBErjMKrU4D2ks5pEPMRgaJpZM4Gd4r9.gif]

[jpffitch]

Believed fixed in 6.08 with new array rate computation