Ben Gottesman

I am a MAXMSP beginner, and could really use your help.

My goal is to write a script that condenses a long duration ( > ten hours) hour nature recording into a 6 minutes (approximate) sound file. One way to do this would be to take a 5 second portion every 20 minutes and crossfade-stitch those 5 second clips in a way that minimizes clicking and maximizes seamlessness. An added wrinkle could be staggering the crossfading between the L and R so that the transitions are not as apparent.

Does anybody have an idea on how to do this? If so, I would appreciate your help, and will definitely share the final product once I am done!

I am a MAXMSP beginner, and could really use your help.  

My goal is to write a script that condenses a long duration ( > ten hours) hour nature recording into a 6 minutes (approximate) sound file. One way to do this would be to take a 5 second portion every 20 minutes and crossfade-stitch those 5 second clips in a way that minimizes clicking and maximizes seamlessness. An added wrinkle could be staggering the crossfading between the L and R so that the transitions are not as apparent. 

nature-sound-timelapse

I've got some ideas on how you could do this. What you're describing is a bit like a macro scale granular process, so shouldn't be too hard. One thing though, is it a single ten hour wav? If so, how big is that file?

Which way u will choose for the final effect ,it will be part of an aesthetics . When i think of it , splitting it up into equal range clips will let u keep some of the characteristics from the original recording but at the same time i think u wont really notice them because compressing such long take its a huge compromise over the audio information that it consist of .

The second solution i can think of now is to interpolate between given points in audio table . 6 minutes is about 15876000 samples of a audio data . if u divide whole length over 6 minutes u will get the factor over which u would jump within the original data . These new points will complete your new output .

For the sake of curiosity i would try both approaches , Your first idea and interpolation . may sound interesting depending on data looseness . Also waiting for others with what they will come up with .

its a Karlheinz Stockhausen school :))))))

Hi Ben . Very interesting .
Which way u will choose for the final effect ,it will be part of an aesthetics . When i think of it , splitting it up into equal range clips will let u keep some of the characteristics from the original recording but at the same time i think u wont really notice them because compressing such long take its a huge compromise over the audio information that it consist of . 

The second solution i can think of now is to interpolate between given points in audio table . 6 minutes is about 15876000 samples of a audio data . if u divide whole length over 6 minutes u will get the factor over which u would jump within the original data . These new points will complete your new output . 

#EDIT
its a Karlheinz Stockhausen school :))))))


also, just in case this is lost on me, is there a particular reason to actually use a 10-hour long recording, rather than simply taking little recordings at fixed intervals?

What I is similar to what you are saying, taking periodic clips from a long recording. I have several applications for this type of nature sound time-lapse, and almost all of them begin with a pre-existing long-duration recording, inhibiting me from simply taking little recordings at intervals. In fact, the most urgent application is creating a sonic timelapse to accompany months of continuous audio and visual data, and so '10 hours' was just an example / starting point.

Any ideas or patches / objects would be super helpful.

What I is similar to what you are saying, taking periodic clips from a long recording. I have several applications for this type of nature sound time-lapse, and almost all of them begin with a pre-existing long-duration recording, inhibiting me from simply taking little recordings at intervals. In fact, the most urgent application is creating a sonic timelapse to accompany months of continuous audio  and visual data, and so '10 hours' was just an example / starting point.

Any ideas or patches / objects would be super helpful.


Could any of you provide me a rough patch to illustrate what you are envisioning? That will help me have something that I could then refine, but seeing how this concept could be roughly sketched out in max would be a big help to me.

Could any of you provide me a rough patch to illustrate what you are envisioning? That will help me have something that I could then refine, but seeing how this concept could be roughly sketched out in max would be a big help to me.
Thanks,

I'd split the patch up into two sections. First you will need some kind of control structure for the device - the bit deciding which piece of the file to play, and for how long. You could either do the maths for this before you press play, so analysing the length of file plotting points and creating a list of slices to play. Alternatively you could create a machine that just 'runs', playing say a 5 second slice from every 1 minute of your file till it runs out of file to play. They would both work, the first is perhaps more elegant and would take a little more work, but could give you more control and some visual feedback such as marking sections on a waveform image.

Think before you start about which controls you need.

The other section will be the playback bit. Here you need at least two sample players which the patch will alternate playback between. They will need an envelope applied for volume, so whilst one is fading up, the other is fading down. As if the patch is constantly crossfading from one section to another.

I'm assuming that the file is too big to be loaded into memory, so the sfplay~ object will be the way to go. sfinfo~ can provide details of file length. You will need something to trigger each slice, probably the metro object. For an envelope I'd probably fill a buffer~ with half a sine wave, then use line~ and wave~ to create the control signal.

I'd be happy to sketch this out in rough if you get stuck.

Think before you start about which controls you need. 

I'd be happy to sketch this out in rough if you get stuck.


get two sfplay~s and one m4l.bal2~, that should do it, right? Then we don't need envelopes at all, but rather a simple "fade this way, fade that way" thing.

True enough... I was following the granular approach too closely there.

One thing I'm not sure of - is there a way of displaying a waveform image in the patch (like waveform~ does) if the file is not in a buffer? Thinking it would be nice to have some visual feedback of where in the file each section was from.

Could you scrap together a "sketch patch." I've been trying but am not really even close. I am able to load the file in, and play it for a certain amount of time (eg: 5 seconds), but then to write a program that says, ok, now the next file you play is going to be X amount of time ahead of this one is what is messing me up.

@Mark draw a waveform for sfplay... stumbled upon this.

@Stephane - That looks good. Will investigate.

@Ben - Here is a rough version which appears to be working:

I've taken the approach of calculating the slice positions before pressing play, so the left part of the patch does all that stuff. The other part plays the audio back. I've put some comments in the patch and left a few extra message boxes around so you can see the messages as they happen.

I expect there's a few small things still to fix, but the core is there. See if it does what you want it to do, and feel free to ask about any of it if it doesn't make sense!

@Stephane - That looks good. Will investigate. 

I expect there's a few small things still to fix, but the core is there. See if it does what you want it to do, and feel free to ask about any of it if it doesn't make sense!


you might also try up sampling non real time to shrink your file to the length you want then changing pitch down w/o changing speed. might even work to upsample to a much, much shorter time than you want, process it and downsample to slow it to the correct length and pitch.

Ben here again. I've been working on Mark Durham's patch (who I hope is sipping free drinks on a sunny island as a karma reward for helping me out).

The main thing I have tried to add is the ability of the timelapse to work not just for one file, but all the files in one folder, AND crossfading between these files in succession.

I have hundreds of 10 minutes files that I want to do timelapses for. I think I am close to getting this right, but it is still not playing. I figured I could show you guys where I'm at and see if you can fix it.

The main thing I have tried to add is the ability of the timelapse to work not just for one file, but all the files in one folder, AND crossfading between these files in succession. 

I have hundreds of 10 minutes files that I want to do timelapses for. I think I am close to getting this right, but it is still not playing. I figured I could show you guys where I'm at and see if you can fix it. 

The patch is attached at the bottom. Sorry, I didn't realize copy pasting would result in this giant mess.

Interesting thread, BTW, It reminds me phonolapse by Andrew Spitz:

Interesting thread, BTW, It reminds me phonolapse by Andrew Spitz:
http://www.soundplusdesign.com/?p=5059


Hey LSKA, thanks. I will do that next time. Did you check out the patch? I would love some advice. It is a lot like Andrew Spitz' phono lapse. I'm hoping that these crossfades will make it a little less clippy sounding, and enable me to do timelapses for months of semi-continious nature sounds. Would really appreciate anyone's help!

About your [sfinfo~] question: you can assign different names to [sfplay~]s and corresponding [sfinfo~]s:

Will definitely check this out when I've got some time, just pretty busy right now.

Probably quite a bit will need to change to support folders as the current implementation is very focused on one file - because of the way it divides that file up into slices.

For the folder version would you want it to just trigger random slices endlessly? That should be easy enough using the [folder] object, filling a [umenu], counting the entries and triggering a random number to play the files.

Strangely enough, I built a patch which pretty much does that here:

http://sounddesignwithmax.blogspot.co.uk/2014/11/sound-design-toolbox-part-3-random.html

The only potential issue is that it uses [polybuffer~] so is restricted to how much ram you can use.

Will definitely check this out when I've got some time, just pretty busy right now. 

Probably quite a bit will need to change to support folders as the current implementation is very focused on one file - because of the way it divides that file up into slices. 

Strangely enough, I built a patch which pretty much does that here: 

http://sounddesignwithmax.blogspot.co.uk/2014/11/sound-design-toolbox-part-3-random.html
The only potential issue is that it uses [polybuffer~] so is restricted to how much ram you can use.


You'll the the patch has changed a bit since you posted it. Right now it is not working, but it's closer to what I need. This iteration has three parts...

1. UMENU with a boatload of .WAV files in it.

2. Cross-fading system between sequential files. This enables individual .WAV files that are timelapsed in Part 3 to get stitched together in order to form 1 long, seamless time-lapse.

3. The timelapse program, which you designed. There are some alterations I plan on making, but we can talk about that later.

Thanks a lot for your help. I'll definitely give you a shoutout when this project is finished!

1. UMENU with a boatload of .WAV files in it.
2. Cross-fading system between sequential files. This enables individual .WAV files that are timelapsed in Part 3 to get stitched together in order to form 1 long, seamless time-lapse.
3. The timelapse program, which you designed. There are some alterations I plan on making, but we can talk about that later. 

Here is an updated version. As you will see, the patch you made is not in this patch. What I am sending you is just a patch that can sequentially advance through many files loaded into a umenu, and then crossfade between each of the files. Then, the two patches will be combined so that the timelapse component is applied to each file.

This patch is a work in progress, but is much better than my previous attempt above. However, there are still things that don't work. It does advance sequentially, but for some reason the crossfade isn't being applied to the files.

Just wanted to give you an updated version if you decide to work on this. I'd still very much appreciate your help.

Here is an updated version. As you will see, the patch you made is not in this patch. What I am sending you is just a patch that can sequentially advance through many files loaded into a umenu, and then crossfade between each of the files. Then, the two patches will be combined so that the timelapse component is applied to each file. 

This patch is a work in progress, but is much better than my previous attempt above. However, there are still things that don't work. It does advance sequentially, but for some reason the crossfade isn't being applied to the files. 

I've not tried to actually get the patch running, but it appears that you are triggering both sfplay~ objects at the same time. This would account for the click. If you look back at my original contribution there is a gate and counter system alternating between players.

Maybe I'm unclear of how M4L.bal2~ works, but wouldn't both sfplay~ objects need to be running in order to crossfade between two different files, one file routed to one sfplay~ object? Mustn't there be some period of overlap?

I could understand how it works in the original patch, because both sfplay~s are reading from the same file. But that is not the case in this instance. Maybe I need to set up a coll to crossfade between files, too.

Maybe I'm unclear of how M4L.bal2~ works, but wouldn't both sfplay~ objects need to be running in order to crossfade between two different files, one file routed to one sfplay~ object? Mustn't there be some period of overlap? 

I could understand how it works in the original patch, because both sfplay~s are reading from the same file. But that is not the case in this instance. Maybe I need to set up a coll to crossfade between files, too.


They do indeed need to be running, but the triggering needs to be staggered. So when one player is 50% through its section, the other is at 0%. The crossfade follows this pattern, being fully over to one player when it is 50% through playback of a slice.

It's a bit difficult to describe in words, but have a look at this as a graphic explanation:

As your sfplay~ objects both receive a 1 message (play) at the same time they are doing this:

So you will hear a click every time the player which is faded up starts a new slice.

They do indeed need to be running, but the triggering needs to be staggered. So when one player is 50% through its section, the other is at 0%. The crossfade follows this pattern, being fully over to one player when it is 50% through playback of a slice. 

So you will hear a click every time the player which is faded up starts a new slice.


Right, Mark. Given the nature of this crossfade, I think it would be best to employ a different type of CF when crossfading between files, so that the overlap is less than half the file length. Instead of M4L.bal2~, I am going to look for a crossfader that acts more like line~, with some specified crossfade time that blends together the first and last N slice(s) of the two files, respectively.

I am still not where I want to be with this program. The project it is for is really cool, and I would love for you to help us with the MAXMSP code. Is there some way to direct message you so I can tell you more about the project?

Yes, I could be interested. I think I ended up not quite knowing exactly what you wanted, so perhaps best to have a chat.

Nature sound timelapse