Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OnsetSliceClient: results can depend on host blocksize #95

Closed
weefuzzy opened this issue Feb 11, 2022 · 0 comments · Fixed by #96
Closed

OnsetSliceClient: results can depend on host blocksize #95

weefuzzy opened this issue Feb 11, 2022 · 0 comments · Fixed by #96
Assignees
Labels
bug Something isn't working

Comments

@weefuzzy
Copy link
Member

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 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 
(
var condition = Condition(); 
var results = Dictionary();
var synthFunc = {
    var sig = PlayBuf.ar(1,b,loop:1);
    FluidOnsetSlice.ar(sig,metric:8,threshold:0.3,hopSize:50)    
}; 

var recvFunc = {|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; 
}
)
@weefuzzy weefuzzy added the bug Something isn't working label Feb 11, 2022
@weefuzzy weefuzzy self-assigned this Feb 11, 2022
@weefuzzy weefuzzy linked a pull request Feb 11, 2022 that will close this issue
fearn-e pushed a commit to fearn-e/flucoma-core that referenced this issue Aug 15, 2023
Fix CI references to spaces in package names
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants