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!
I'd suggest a combination of [sfrecord~] and [sfplay~] where you trigger the play object(s) one hour after starting the record object(s).
32 bit computers which wont allow files in RAM over 4gb length will also not allow files on disk over 4gb length.
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.
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.
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...)
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)
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.
did you try sfrecord+sfplay? If so, why doesn't it work for you?
"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.
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.
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.
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?
They could play really loudly perhaps... :) this is an awesome idea, I'm racking my brains for you...
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~
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.
yeah, now we're getting somewhere! :)
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
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).
Just for the fun, reducing the sample rate and applying some filter to remove the aliasing:
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....
You could try the new 64bit Max 6.1 beta, we just released:
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.
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.
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.
audio signals should have a 64 bit resolution since max v6.0
multirate and multiresolution would be a great feature indeed. :)
-110
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.
That makes things clear!
Thanks, Edwin
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