buffer snap to peak in sample?
hello all,
been messing around with [record~] and [poly~] on a new granular looping path and was thinking on being able to snap the peak of the audio signal to the start of [buffer~]
say when you are recording and you let the timer go for a second or two you then start playing, depending whether you are using a foot controller [which i am, its the behringer fcb1010].
but when you start recording and then finsh, is it possible for the sample to be processed and 'snap' the buffer to the highest peak to when the sound is played.
so instead of having a silence when you first play and it loop with the silence, it gets rid of the silence and snaps the peak to the beginning sample to [buffer~]
if not that is fair enough but just was thinking about this when recording to [buffer~]
best regards
lewis edwards
------
smokingbunny.co.uk
Hi Lewis,
The guy in this thread is asking the same question I think. I didn't look at it but he seems pretty happy with the patch in the penultimate post!
Hope it's what you're after, I'm also in need of something like it so I'll take a look!
EDIT: Yep, that patch trims the silence at the beginning of the recording.
alright james man,
that is great, exactly what i needed
cheers
lewis
As far as I can tell from looking at the example dickmedd linked, I think that will not be the most accurate way to trim your buffer for two reasons. 1) By looking for peaks you will trim to a high point when what you should do is find a peak and then find the first zero crossing before the peak. 2) Using snaphot is also going to have some slop converting from the MSP thread to one of the Max threads and is going to report a value close to where the peak was but not necessarily the real peak.
I'd recommend checking out this code Volker Böhm posted a while ago. It is a Max implementation of Nao Tokui's slice~ object (I haven't seen that available online in a few years): https://cycling74.com/forums/beat-slicing
Since Volker's patch runs all in Max messages, it can be pretty slow. I made an mxj based on the same algorithm a few years ago. I just found it on my computer, if you are interested, I can post it after I have a chance to double check it for bugs (I noticed there is a bug in the helpfile I made and I noticed one unnecessary setting I included, so I want to find the source and look it over again before I send it out into the wild).
@Roth I'd be interested in seeing that!
same here
Sorry for the delay, here it is.
In a couple weeks when I'm back home I'll find the source code for this and make a few modifications. As you will see in the help patch, you need to manually input the sampling rate (I think it defaults to 44100). At the time I wrote this I couldn't decide how to handle sampling rate because I wanted to object to be useable without MSP on. Also, right now it only outputs the list of slice indices in ms (which is why it needs the sampling rate)—I would like to add an option for outputting indices in samples as well.
You will see a warning printed to the Max window when opening the help patch, I think this may be something stupid I did regarding the typed in buffer name argument (which should not be necessary, you can send it a message with a buffer name and channel (defaults to channel 1 if only a buffer name is given) to slice.
I also plan to work on an algorithm to handle choosing slice points based on all channels in a buffer, not just one at a time (need to add some sort of threshold since all four channels probably won't have common zero crossings).
Let me know if you have any questions.
thats great roth, thank you very much
Thanks so much Roth. So far it's sensational and fits right where it needed to in a patch I'm sorting out. I've only noticed a couple of things:
The Max window always outputs that the buffer specified in the argument may not exist (as long as I know it does it's no real bother!)
It also warns me that the channel I've specified doesn't exist. So far I've only tried with one channel so the default is fine, I'll explore it further later.
Yeah, that warning doesn't seem to be working as intended, ignore that. I'm busy working on getting my some more of my old externals documented for publishing and trying to get some new externals stable and ready for an upcoming gig, but I hope to have time over the next few days to release a new version of rm.slice with that warning fixed maybe add some features. Let me know if you have any suggestions/requests for the next version.
Hi ROTH !
Is any new version of rm.slice ready?
I'm getting some strange behaviour i guess when it slices buffer reaching maximum Amplitude.
thanks
a.