Cool, that’s useful to see.
A couple differences and things to note (for @agustinissidoro) with the approach in SP Tools (and C-C-Combine).
In my approach I tend to load a single file (which is still possible in this example, but just replace-ing the buffer~ corpus instead of loading a folder) and then slice at a fixed interval, as opposed to onsets/slices. This is a large point of diversion as I end up with (usually (significantly)) more segments this way, as well as not necessarily having slices happening on “onsets”.
This approach also has the side effect of each grain/segment being the same size, which has ramifications further down the line for playback.
Another big point of divergence is in the playback/matching. Although it’s a relatively simple edit in the patch that @tremblap shared, this example is monophonic in that when a new match is found, it stops playing the current grain and immediately starts playing the next one. So even though the slices you are creating upstream are generally going to be of different sizes, each one is only played for amount of time based on your matching rate (which in this case looks like the signal vector size and/or @history amount in fluid.stats~).
I would drop my playback bit from SP Tools in, but it’s fundamentally different in that the example @tremblap posted presumes a single long (concatenated) buffer with variable start/end points. That small playback bit can be wrapped in a poly~ or made to use mc.play~ instead without much work.
Similarly to this last point, the match/playback rate is fixed based on the analysis pipeline. So you can also experiment with having periodic/aperiodic options here, as well as having different rates. A simple hack there would be to use zl reg and a metro to only send a match when you want:
This is kind of hacky as you’d ideally have your rate correlated with a similarly lengthed analysis length, but this could give you a different flavor of playback.