buffer snap to peak in sample?

Nov 1, 2011 at 8:45pm

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

#59728
Nov 1, 2011 at 8:53pm

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!

http://cycling74.com/forums/topic.php?id=29645

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.

#214928
Nov 1, 2011 at 9:37pm

alright james man,

that is great, exactly what i needed

cheers

lewis

#214929
Nov 1, 2011 at 9:45pm

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): http://cycling74.com/forums/topic.php?id=24094

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).

#214930
Nov 1, 2011 at 11:13pm

@Roth I’d be interested in seeing that!

#214931
Nov 1, 2011 at 11:16pm

same here

#214932
Nov 9, 2011 at 1:12pm

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.

#214933
Nov 9, 2011 at 1:13pm

Oops, hit “Send Post” instead of “Choose File”.

Attachments:
  1. rm.slice.zip
#214934
Nov 9, 2011 at 2:32pm

thats great roth, thank you very much

#214935
Nov 10, 2011 at 9:02am

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.

#214936
Nov 17, 2011 at 8:39pm

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.

#214937

You must be logged in to reply to this topic.