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
The results of slicers are meant not to depend on the host blocksize. The code in OnsetSliceClient (resp. NovelitySlice) that deals with positioning spikes into output frames doesn't handle the case where the hop size is smaller than the block size, and also doesn't divide neatly into the block size. IOW words, assuming a power-of-two block size, a hop of 32 would give consistent results, whereas a hop of 40 wouldn't.
Workaround
Um, don't use weirdass hop sizes.
A fix PR is hot on the heels of this issue. The solution is to make the frameOffset part of the client state so that it can correctly track across block boundaries that don't tessellate with analysis frame boundaries. However, it might be better if the affected clients were able to pull this information directly from their BufferedProcess objects, which already implement this behaviour correctly.
Reproduction
This supercollider code reproduces the problem
// Runs the same material through FluidOnsetSlice at different server block sizes// the results should be the same each time (varcondition=Condition();varresults=Dictionary();varsynthFunc={varsig=PlayBuf.ar(1,b,loop:1);FluidOnsetSlice.ar(sig,metric:8,threshold:0.3,hopSize:50)};varrecvFunc={|a|results.put(s.options.blockSize,a);condition.unhang;("Done"+s.options.blockSize).postln;};fork{s.options.blockSize=64;s.waitForBoot{b=Buffer.read(s,FluidFilesPath("Nicol-LoopE-M.wav"));s.sync;synthFunc.loadToFloatArray(1,s,action:recvFunc);};condition.hang;s.quit;s.options.blockSize=256;s.waitForBoot{b=Buffer.read(s,FluidFilesPath("Nicol-LoopE-M.wav"));s.sync;synthFunc.loadToFloatArray(1,s,action:recvFunc);};condition.hang;s.quit;results[64].indicesOfEqual(1.0).postln;results[256].indicesOfEqual(1.0).postln;})
The text was updated successfully, but these errors were encountered:
This probably goes for
NoveltySliceClient
too.Problem
The results of slicers are meant not to depend on the host blocksize. The code in
OnsetSliceClient
(resp. NovelitySlice) that deals with positioning spikes into output frames doesn't handle the case where the hop size is smaller than the block size, and also doesn't divide neatly into the block size. IOW words, assuming a power-of-two block size, a hop of 32 would give consistent results, whereas a hop of 40 wouldn't.Workaround
Um, don't use weirdass hop sizes.
A fix PR is hot on the heels of this issue. The solution is to make the
frameOffset
part of the client state so that it can correctly track across block boundaries that don't tessellate with analysis frame boundaries. However, it might be better if the affected clients were able to pull this information directly from theirBufferedProcess
objects, which already implement this behaviour correctly.Reproduction
This supercollider code reproduces the problem
The text was updated successfully, but these errors were encountered: