Ok, gave it a quick test.
So I tested with a slightly longer chunk of audio from the same recording (12s) and with your default settings got 51 transients. I compared to my settings (posted above) and only got 42, so I was wondering what was up. Turns out the @debounce 25
is too short, so I’m sure a bunch of those transients were samples long because as soon as I turned your default settings up to @debounce 1103
I only got 36 transients.
(with your audio example, changing the @debounce
time goes from 25 slices to 19)
To test, I also padded the start of my file with silence too, and yours captures that initial 0.
as a transient. So I think regardless the first one should be thrown out, however, there is a possible @debounce
issue here (which I’ll also make a separate thread for) in that the approach used always returns 0.
as a boundary, but if you set your @debounce
to something reasonable (> 1000 samps
) then you run the risk of ignoring a transient that happens at the start of the file that happens at time 0 + debounce time
.
Also noticed that you’re calculating the resynthbuf
and envbuf
, which aren’t needed unless you want them. (unless I’m missing something, you only need filterbuf
for this kind of matching)
Onto the actual matching.
So initial test with my longer bit of audio, and it’s a fantastic (and actually fast) match slice 22
machine! In my test it literally only spat out the highest slice.
(on further inspection, it was fluid.nmfmatch~
spitting out tasty tasty nan
bread)
Ok, something weird is happening. I managed to get the patch working one time (while testing with different settings). It wasn’t super accurate, but it was producing somewhat useful results. Since that point, I can’t seem to recreate it working. With your default patch I can’t get it working either (from a fresh download). fluid.nmfmatch~
returns lists of 0.
.
I also think the “red error message” you’re getting is related to the short debounce time I mentioned earlier. I think it’s happening because you’re analyzing a buffer that is > 25samps
but < 30ms
. So I guess the debounce time has to be, at minimum, larger than your analysis window. (when testing with my settings, and my longer audio sample, I don’t get any error messages)
Ok, in testing further, I think the problem has to do with the filterbuf
buffer~ size. Because you’re doing this via peek~
you need to know how many channels there will be, whereas with fluid.bufcompose~
you don’t (and dynamically/manually changing the amount of channels results in a crash)
I tried refactoring your p write_master_buffer
subpatch, but I can’t seem to get fluid.bufcompose~
working right (due to the confusion mentioned above and here).
The refactoring should be super easy, and this bit of code is just adapted from my batch processing file, it’s just hard to tell why it isn’t working here.
----------begin_max5_patcher----------
918.3ocuWssiaBCD84juBKK02XirM26uRUUDPbR8J.i.S61V09s2wClbYWRV
RJs4AGyvLdlybFO17y0qn45WjcTxGIehrZ0OWuZEJxJXk64UzprWJJy5P0nE
5pJYsg5M7Ni7ECJOqR2WaH58jtRUArlNEp6qT0kRCZM2IrIyT7EU8gssxByf
2EL1FlGIHzNlhiBPB4ymVGcuYbgXNopcny04O+jHgZk8q0qsCdyDNvxlKau2
fkGDfAK2NFhAtPb0fU3jNHx78F4vpPodDZdV8A5QCOGOQziAPaVkzHa2Jqyx
KQqYOBVkeCV32vbOQ3ShewMvuevFQnGgKRQrmtI7lY.90x.JnRZRv6+HjYdu
wnquaxjKPvLvlhfww6EKWmIE+mXx9enHh6mLc3OI9TM8M3R+aheuS+eUtkQW
NHaHJh5tY7wx2X1rJeE2p78FHkmrfHsoUcps6bQZjCfga3QAQwhjPdXjE59h
2glmnCKOdAgCbNRtpVR.PQ1VWse6dUo4JchmQmHAGqaGaH8fMimlEiVPX2gz
3dRSqFNjri7gNBi7DGF3D63G1QNkL110W8pGe37Sn+FNKLIMLMMhk5GaqABC
emj0U60M8F6ELOsurWsaSd+dnNoQ2I+8itGehZeNK4Qw8U6w6GdN3QMnkP88
qtaEFnV4WlQ5z8sEi9X7vexonamrynpyLJ3zsyThAJwIedxr9r8j+L7DzHCU
5uyS1vU7dXxeA7DeVYukvQIyI4EsDIOwbKHVDLwmQx6utxaN4t3KTR2tCNhv
tA8etmgMzS5Y1a1lm0z7UYamybzoPKtm0n5Id3ip5gGwSUosxupF0G6cSyZg
9WFn4UeKFnzWhBnClpAGW2qbnFfK3xNy2KecqkZ3lknoP60HaOWLxAzsOquz
bYFw1lsPWpa2ppswtK4fWV3z.+r9i4GP8c8Vcu0Mv1DdTurhB3qCOSW1lDqF
I9oBdjcVLKMgE3V8gjomi8ZASQng3vAfJH5UiY9yY6K.Ldlvsf7EgTfvOTjZ
iF+XQX.NSDGDxW5vpBNiO6fbo4B39.kGAzpiqErXtipnGZy1oN8c5N7yOxIQ
vuXuImclqblIFMKNIAxbdSN6slMZkHkwSQt22w81YfH9qrBNbcHIKvKl6jBW
UpQ2Nt8DLM8n98F8QfNt2bXy4UouK2cLOVb3Z.yt5B4r.nrhIvY.lgX9QqrF
ZxfWXxFTcMYC8xv6Us9Wq+yV3Jwg
-----------end_max5_patcher-----------