To better understand the timing between ‘parallel’ processes, I made a very simple test patch. It repeats the same piano sample, tracks the onset with onsetslice~ and fires after a delay the collected output from nmfmatch. To observe the values, I’m just summing the vector of the 61 activations. To my surprise, I’m getting very different values at each repetition. Any guru’s explanation would be helpful.
analysis-timing?.zip (567.0 KB)
Hi Hans,
I’ve only had a quick look so far, but I think what you’re seeing is less to do with the parallelness, and more connected to how the periodicity of the analyses tessellate with the input.
- To try and discount the unavoidable timing variability of switching from signal to message domains, I put a sample counter on the onsets to see what was happening there: occasionally it is one hop size later. This is because the peak of the input isn’t going to repeat at exactly the same rate as the period of analysis (i.e. the hop size)
- Then, looking at the nmfmatch~, I used zl stream (with zl change) to get an idea of the values in the temporal neighbourhood of the onsets. Something similar is happening: on those frames where the onset has jumped by a hop, the upswings levels of the activations are observable over two frames, rather than one. It seems a bit confusing that in this case the reported peak seems to be larger, but I think that because the nmfmatch is reporting (sort of) how the input correlates with the supplied bases, the variability we’re seeing is again due to (sort of) the relative phase between the analysis period and the playback period
- Then I noticed that you have no overlap for nmfmatch, and different analysis settings in each process. I think having no overlap will certainly exacerbate this problem, because it makes it a kind of winner-takes-all between analysis windows (in the same way that with the onset detector the output is quantised down to either
yes
orno
)
Short version: if I put some overlap into your FFT settings, and make sure that nmfmatch and onsetslice are using the same analysis settings, I see considerably less variation even with overdrive off (which would be the pathological case with respect to the thread switch).
How much variability you can actually tolerate depends on what you’re trying to do. If you want to give me a bit more detail on the task at hand, we can see if we can devise something usefully robust.
thank you, that’s a good explanation. Indeed when putting overlap, I’m getting more equal results.