TEST:
wavetable size / precision
CtkBuffer:*collection appears to drop the last item, as a result of setting numFrames to size - 1 rather than size
With the Ctk test below, the returned \b_setn message is:
[ 'b_setn', 0, 0, 15.0, -0.70710676908493, 0.70710676908493, 0.41421353816986, 0.29289323091507, 1.2928931713104, -0.29289323091507, 1.4142135381699, -0.70710676908493, 0.70710676908493, -0.70710676908493, -0.41421353816986, -0.29289323091507, -1.2928931713104, 0.29289323091507, -1.4142135381699, 0.70710676908493 ]
Where it _should_ be:
[ 'b_setn', 0, 0, 16, -0.70710676908493, 0.70710676908493, 0.41421353816986, 0.29289323091507, 1.2928931713104, -0.29289323091507, 1.4142135381699, -0.70710676908493, 0.70710676908493, -0.70710676908493, -0.41421353816986, -0.29289323091507, -1.2928931713104, 0.29289323091507, -1.4142135381699, 0.70710676908493 ]
We can see that the Ctk is setting the numFrames arg to 15.0, rather than 16, which _is_ the size of the wavetable expected to be sent.
This ERROR could be generated by CTK.sc, line 259 <--
Question: as line 259 relates to "chunking" of larger arrays, is this a "chunking" error, or an edge case artifact??
Because we weren't observing this error previously (DXARTS 461 2022), I'm suspecting the observed error is a
result of Jul 23, 2022 commit: update for Ctk score renders with LOTS of buffer, and credit to Marcin
https://github.com/supercollider-quarks/Ctk/commit/c363f0a157a098b8bd4e2f8b76259ca945682fbc
Joseph Anderson
25 Jan 2023
@joshpar, @dyfer: My suspicion is this issue was introduced in c363f0a, as I wasn't seeing this behaviour previously.
Comments from linked reproducer: