Buffer~ crop problem
Hello!
I am trying to copy the contents of a buffer~to another buffer and crop it to a certain length. The problem is that I cannot crop to certain lengths in samples. See attached patch. The actual length is nearly always a bit diffferent than the one I whished to crop to, and eg. I can not crop to a length of 4 samples. I am using the 32-bit version, and I guess this might be the problem.
Is there a possibility to crop to a number of samples directly instead of ms? (not only resize, I'd like to trim the biginning of the data too.. and doesn't "sizeinsamps" also clear the contents anyway?)
Thanks for any help!
running into this also and seems like the only solution is to go back to manually peek poking stuff into another buffer or make some kind of RNBO contraption external
*** helpful tip from Discord : CROP will accept fractional values.
I've tested a converted number and the result matches the recorded buffer
samples to ms conversion will never work to copy or crop buffer
sample exactly, because of rounding.
try to convert 123 samples in 44100 sr to ms and crop buffer.
then read samps attr.
or set buffer size in samps and get ms from info~
hm, i do not understand the problem. when you properly convert samples to ms, you will always get back the correct values in samples, no?
No
…………………
works fine for me. as you know, in max 4 everything can only be sent in milliseconds to buffer. for whatever reason.
so i do int(samples/(441.)+0.5) and get exactly what i want.
a precision of e.g. the 6 digits behind the comma which 32 bit max displays to you are already enough to always get the integer number of samples you entered.
?
Makes me nostalgic to see this 10 year old thread revived. Good to see you are still here and still on max 4 roman!
And yes, the 10 year old younger me assuming that 32 bit version has something to do with this definitely was wrong. Not quite sure what i messed up back then :*
yep nostalgic times, in which I had trouble copying buffers
using ms, which often ended in missing or extra sample
which caused clicks in layered loops.
Max 4 had no way to query size in samples, till buff.op,
which again is not really usable for copying.
At the end I modified el.buffet~ from Lyon potpourri
to use samples for all operations insead of ms.
Worked very well for live looping, I was for example storing every overdub into extra buffer,so that one could undo recording by copying back inverted buffer on the fly, and many such things.
el.buffet is unbeatable when it comes to buffer manipulaion, has even overdub function, but unfortunatelly help files are outdated and useless.
@Roman , look at this
adding 0.5 works for some, and then not for other input values
Hi, setting the size in ms floats to get a desired length in samples works reliably, it seems. Just letting the buffer~ do the rounding on it's own
For cropping: are you sure it's not simply endsample + 1. Couldn't create another case yet .?
it is not about setting size, but to crop buffer using samples.
122 ok, 123 not .. that is ony 1 exampe
not for me, I get +1 in all cases
Another difference of Win and Mac buffer~ ?
could be, I will check it and report,
I am using max 8.1.11 mostly, have no need for higher versions.
but, for me this is not really important, because I use that exernal for the job directly in samples.
In fact it is strange that setting size in samples has been added to buffer
functions, but crop remains ms only
same problem on windows 10, max 8.5.5
both 21 and 22 at input produce 22
seems to be related to the samplerate. my buffer~ was at 48000. When I set the buffer to 44100, I can reproduce it..
can´t tell you offhand now what i actually do, but it would make sense that buffer truncates down to the next full sample value.
the only thing what does not make sens is that the crop message now is the only one left which does not allow sample values.
to test how long a buffer is, just index~ from it.
as I said I use different means of buffer manipulation since years,
only reason I posted is to show the bug.
at that time I found no solution to keep
sample count based looping buffers intact when cropping.
waveform~ was the only max tool that could crop the buffer,
problem was exacty the same, even that one could use samples and grid
1 for selection, but only for mouse.
1 sample difference caused clicks, and any ducking or whatever is no solution at all for sustaining loops.
isn´t it a relatively rare scenario that somebody wants to crop a buffer and then use the sample as is in max (apart from exporting things as sample material on disk, of course... IRs, drumsets, that kind of thing.)
when you want to play 99 samples from the buffer you can crop down from 10000 to 100 and then use wave~ or play~ to play 99 samples, if you want to crop stuff for a wavetable set you have to copy between different buffers anyway, and so on.