You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
I haven't done further testing, but if there is a chunking issue, loading filter kernels will also likely be affected...
... actually, on further review, larger collections, > 1024 (sizeLimit), seem to be fine.
@joshpar, @dyfer: My suspicion is this issue was introduced in c363f0a, as I wasn't seeing this behaviour previously.
Comments from linked reproducer:
The text was updated successfully, but these errors were encountered: