1 hour long tapin~? Very long delay lines needed!

Feb 22, 2013 at 8:41pm

1 hour long tapin~? Very long delay lines needed!

For an upcoming internet based performance, we need the ability to delay 3 incoming audio signals by up to one hour.

I am concerned that simply using tapin & tapout which uses RAM buffers will require roughly 1.5gb of RAM for each channel for an hour (44.1, 32). We require three channels for the performance. This seems too intense for some of the computers to handle and I am looking for a hard drive based solution.

Is there the ability to have a hard drive based buffer? Or the ability to write and read the same file at the same time from the Hard Drive?

Any wild suggestions appreciated!

#66666
Feb 23, 2013 at 1:31am

I’d suggest a combination of [sfrecord~] and [sfplay~] where you trigger the play object(s) one hour after starting the record object(s).

#239949
Feb 23, 2013 at 9:53am

32 bit computers which wont allow files in RAM over 4gb length will also not allow files on disk over 4gb length.

#239950
Feb 23, 2013 at 10:47am

what Steven said, and then bumping it down to 44.1, 16 bit. That way you’re looking at, what, maximum 2 gigs in total.

#239951
Feb 23, 2013 at 4:20pm

Just for the maths: 44100 (sr) * 60 (seconds) * 60 (minutes) * 3 (channels) * 8 (bytes per sample) that’s 6413904000 bytes or 6,4 GB of RAM that you need to make a delay line of 1 hour with 3 channels. So you just can’t do that with Max 6.0.x but you will be able to do that (if you have the physical RAM on your machine of course) with the forthcoming Max 6.1 in 64 bit mode.

#239952
Feb 23, 2013 at 7:13pm

To respond to what Roman said: I have an old PPC Mac mini (32-bit) here working as a file server, and it has plenty of files greater than 4GB. The file length limit is related to the OS and the type of filesystem, rather than the address space.

(If I had a dollar for everyone I’ve met who bought an external hard drive formatted FAT32 and then found that they couldn’t copy their video files onto it…)

#239953
Feb 23, 2013 at 8:21pm

yeah of course, but you wont be able to fully load them into RAM again. :)
(reading back i see that i actually wrote something different)

#239954
Feb 23, 2013 at 11:48pm

Is there no hard drive based buffer/disk streaming in Max that could work for this idea?
I’m thinking that perhaps Supercollider might have the capability to simultaneously write and read an audio file from the hard drive, but would love to keep this in Max.

Or just make a physical hour long tape delay. Aww yea.

#239955
Feb 23, 2013 at 11:51pm

did you try sfrecord+sfplay? If so, why doesn’t it work for you?

#239956
Feb 24, 2013 at 2:25am

“Is there no hard drive based buffer/disk streaming in Max that could work for this idea?
I’m thinking that perhaps Supercollider might have the capability to simultaneously write and read an audio file from the hard drive, but would love to keep this in Max.”

This is exactly the solution I suggested above.

#239957
Feb 24, 2013 at 11:48am

Emmanuel’s arithmetic is obviously correct. But, if you’re not obsessed about CD sampling rates, you might consider working lowering SR. Halve the sample rate and you’ll halve the memory requirements. I’m old enough to remember when 10 kHz was considered a pretty decent SR. That would get you down to a “mere” ~1 GB/hour for three channels.

It depends on what you want to do with the signal and how much fidelity you require for sounds an hour after the last time anyone heard them.

#239958
Feb 24, 2013 at 12:19pm

or just skip recording to ram altogether. It really depends on what kind of processing OP wants to do. We haven’t really been told.

#239959
Feb 24, 2013 at 8:46pm

I would be reluctant to reduce SR…

I should probably elaborate, this patch is being made for a multi-location performance across the states.
4 different locations are going to be transmitting audio via Jacktrip to each location.

We want to simulate the speed of sound by adding in realistic delay times (for example a sound in Chicago would take roughly an hour to be heard in New York (if it were loud enough)… so each location will be receiving three channels of audio and implementing the various delay times on each incoming signal.

No signal processing other than simply delaying the incoming streams is needed.

As for sfrecord & sfplay unless im missing something super easy and obvious, I cannot playback a file from the hard drive as it is still being written/recorded.
– Steven, the nature of the performance means that we can’t simply record three minutes of audio for example and then play it an hour later; it needs to be a continuous stream of audio (for roughly a 3/4 hour performance) that gets delayed. Is it possible to simultaneously record and playback the same file or have some sort of rolling buffer?

#239960
Feb 24, 2013 at 9:25pm

They could play really loudly perhaps… :) this is an awesome idea, I’m racking my brains for you…

#239961
Feb 24, 2013 at 9:34pm

A slightly crude solution to get round not being able to simaltaneously read/write the same file could be to have two 30 minute files, and every half hour swap round which file is being read from by sfplay~ and which one is being written to by sfrecord~

#239962
Feb 24, 2013 at 9:45pm

Willy’s suggestion is a standard approach (sort of). It’s basically a kind of double-buffer, which is a standard topic in CS. You’d have to implement it yourself with multiple soundfiles with a bit of overlap, crossfades at appropriate times, etc. Maybe not a rose garden, but should be doable.

#239963
Feb 25, 2013 at 12:14am

yeah, now we’re getting somewhere! :)

#239964
Feb 25, 2013 at 1:01am

I like the file writing idea. You could make it pretty solid with not too much effort.

Maybe you could write a bunch of 1 minute, or n-minute files into dropbox or some other kind of network synced folder, and add time stamp metadata to the filenames or something.Overlap the files, so you could crossfade.Then set up something on TCP so you could talk to your locations and organise the playback.

-A

#239965
Feb 25, 2013 at 7:52am

yeah that was also my first idea, one could roll through 2-3 buffer/recording processes and create files of 30 minutes of lenght.

but somehow i feel that writing to and reading from disk is not the most stable solution for a permanent installation application, anyway, i´d prefer a buffer solution.

one more idea, not sure if it fits here: if you need to read out 3 different delays, you know that you can do that from the same tapping buffer, do you?
4 GB will be enough for a max delay of some 50 minutes (at 32 bit).

#239966
Feb 26, 2013 at 5:41pm

Just for the fun, reducing the sample rate and applying some filter to remove the aliasing:

– Pasted Max Patch, click to expand. –
#239967
Feb 27, 2013 at 3:35pm

Im glad to hear the ideas for the double-buffering technique. It looks pretty darn intense for a performance with 12 different delay lines going on but hey.. it’ll all be worth it if it works.

I completely overlooked the fact that you can have multiple tap-outs from a single tap-in buffer… thats a bit of a game changer Roman…
Combined with some sample rate deduction ala Emmanuel (Thank you sir!!) I can test out those two techniques to see if it sounds decent…

Thank you all for your input thus far… this forum never ceases to amaze me with your enthusiasm….

#239968
Feb 27, 2013 at 9:41pm

You could try the new 64bit Max 6.1 beta, we just released:

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

Though there are many other limitations in 64bit which may make this solution impractical for your purposes (e.g. if you have lots of Jitter or 3rd party externals in the same project), I’d be interested to hear how this specific use case works for you.

#239969
Mar 6, 2013 at 2:04am

Thanks for all of your help with this project.

In the end we used the ‘Beads’ library in Processing to achieve the double buffering technique that many of you suggested.
It works a charm and is quite reliable, even by using dropbox as the server to which all sounds are uploaded and downloaded.

#239970
Mar 10, 2013 at 6:35pm

A quick related question: Are tapin~, tapout~, delay~ and buffer~ all using 64 bit floats per sample in Max 6.1 (as opposed to 32 bits per sample as it used to be before)? If so it could be a future feature to be able to choose between single precision (32 bit) and double precision (64 bit) buffering for these specific objects.

#239971
Mar 10, 2013 at 11:14pm

audio signals should have a 64 bit resolution since max v6.0

multirate and multiresolution would be a great feature indeed. :)

-110

#239972
Mar 10, 2013 at 11:24pm

While MSP signals and tapin/out/delay~ are 64bit as of Max 6, buffer~ objects only ever use 32bits for internal storage. We could consider a 32bit mode for tapin/out/delay~, but not likely happening anytime soon.

#239973
Mar 11, 2013 at 4:46pm

That makes things clear!

Thanks, Edwin

#239975
May 30, 2013 at 9:07am

Just to be the audio guy weenie:
44.1k/16bit audio is 317.52 MB an hour for a mono channel
*3 = 952.56 megs
So, not as huge, memory wise. LARGE but not 4 gigs
even at 32 bit…

If you did this as a 64 bit stand-alone you could patch in/out to anything

#251231

You must be logged in to reply to this topic.