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.
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:
----------begin_max5_patcher---------- 3052.3oc6b0saiiaE95jmBBcSyz0NiHo9yc6.jtWTr.KZuoWNYQfrDsi1QVR ijbl3cvDzml9f0mjd3exR1xRJINNJcm.DaIRJxuyGO7viNjze87yLlmdOqv. 8WPeDc1Ye87yNSjDOgyT2elwJ+6Ch8KDEyXdleYvsrbiIxLSVuJJIlUJx0ba hoqK0ohUoJSpbSFS1fFEQKS7iMP+pp.hpNJY4M4rfRYYrbsuzdBxx9RW3KBw 9RyInYNWZW8PQgBbkN+2lRnZT4muTIUFWcWZrwDzTJ7fFWsJMbcLCtWbWbZZ FbMtpxR7WI.mQHaUZQ55jvKAoGvkAO+uc947OlLPpJg8E.UZHUxtuTV09AOn SbQZRYQzuKZSL4Ry1HURqjp4g4LaWWNKYS4UHhJtgXdoYqTFoNTpD++VdDzw b7j4e3AD94KyOGEIrKgqHgoBMH4mGjTvmDRIC4mTBUYjeAf0oKhhK2NtZHrj 4iVyvyhK2VRcBrYmpFNcPB0aB.yRQWI6vCDEytikWDklTqaCFUlkUK4yp8Hb B62REUjyjpjhRjIgqRJmcWj94MqR0OGDzRPJWmKA48dNFxLgNoy0OplEbvJw WZLwRLLw0AukFfNzkwoAehEVugLRyXIQIY4rBVRoe4N3.rYrvecb4Ms200L+ E9ArC9vsR1mYrLOJLMgChFOIOYcyA54Bgh+4VgQThD+rVd3BPNVWL2Omyqyi Y0F7AZpoowMyppqDT38ShV4WxJijfkXVUoQqxxiRJazPrDenNtsHHOMNtQUI y4tVxID5sCXeIJr7VQcUmJghGko6BLp3nvnkrhxloU5KmLXaJMl0qtZX8QxM RemQzAoqVA5.5Jrwv5+4lOuNpnD8dDEACrCXnuvP25eGSbO2PUQ8m6.ZK6MX G2Li8GvKqs7kyaxUGxdHQXOj3JrHfmsmofcMGP81E0sXX7LswQ0XuW.58uNE AiB9Sknfa8SVxPk25W9e+2+mQ.kRrlI3Rk0UaydoTmSGkthUT3uj0JkFDy7y iS+xSgCIGjCqyt6MisQCNoMG+vb0SGrivUFoQMuCSkD6SGUFFETd4cQrF70S PwpEol5HFNZK8y01kHkaqNDb5wTzZ3oxNdqvXe5AjzIkfT1hEOIqXzml5xh3 TvG79zYnd0HOrItuweU94cBTZ5fYigYKVrNIgEebMh0IixazARnVyDVxr85k OMGE7YNHrLTfeQfeH63ZSizoMsICvtlhRkjomSeTJd1nfREl7h195ImBMzgR k3YRkzdoxSnCLyWWVBtldjYj4fCO8xJDhfVnlUuhaOzh6IRGZ95EKX4MmBAc Ug+prBz9Se+7TrH8OYxjAxmJGQnR+jco8xmzQwH12ibt7D5O2vlf1SNHURhT 4KfzEURFGF+Jx3ulL6giqNpUW7I+0mmTSUUcu3sp6gjg2nix+yAHWKgVqS+J siCOgxxYYrjPzhb1mWyRB1LlltQo7NS9Rd3d8tDON7FRZtMjU5GcX+KoOE5z oWmg18+ds0ZJHWp3yYBCuDbGu+7IjgyhSKaX.vecXT5hbnAqXQSh0PLqFltx GxweNSDtKi+tVaGcwO+6uy3Xn9txOeYThJDWRWM25Mf8tJsPyvEu8.5g6gbk Ujr9nVsUgofsJQMZiIGn6qwj947n4rkT9G9KShJWGxPWD9SMHkh0yqPqN9cM 53fxDjFKCc7GQlWZMQ+AeMj1QehOT41nfOkvjcz35iD3b.WNtonbiL.nFIoI 0emBnDwQIrZEfeqedyh.7wbVdm0hJ5+7L8KSCm2LWoJCTA94k6EKps4C1NE8 gDS6CThZ3LcYqsAn57IVdg1YRScXrf+jQJTegm9BW8EN5Kr0WXoufpufnu.q uPWy5JVWu5pUWq5JUWm5pjTCYZfowkFVZToAkFSZHoQjFPJ7nfiBMJvnvhBJ Jjn.hBGJXnPgBD0BJH1Ri.E.Tsup4kstrw2NZyoZvKugks61A0xG1bOkaUup XfktSUTTC9aqqwLbi5N0s+hQs9bH2ewXm5ULbcqBI31KYGMNYITpjlslY2iZ jkog9n.NSEy9ilRDN2LkJdI5oVBKbSkrzTYjylJWuqoyjEAa5oddU8vwbqxU c5RRAb5Q0vFBGS0suA7sQELLDA0UiFC3aiJPY.eaTgMC3aiJHZ.eaTgTC3ai s.1fegwVfyAfDOTMfnjc6fRyifo.t491XeUdaT4sMqsyO1oEUWtlFwi+Ic12 Mo9nLo1+3yQwHsdGVbbT2P+5QzGM+xx70QGWmbqmCu9kQXjUjklTzH3hO9Wn P.HXlA4aRnLl2g6t8EJv5NSw25JxUuluX2uE43LnEm6mDdSdTVV7QgpUgase l16Iyz67FX2Ts30Xa5ay9gT3cGyOJJ5zgR+N+gRQu0fczCIGFUjE6uYUZHa2 PIcX9WExBJtO929OT7eYZF3ayxGC8y2aP6VeGj2Gr8cqw.sOfHIw2DKnqzzF J3V17ME2xtaJFc0NVsgo6sQWILgfnnqzyahhS+Buj0aFteIAfXUt6xDeb612 qmkuzVQoI94aF3BNQU1wrIsFLk5A33wGdpsaZKNebf8nj.Z77au+rHccdfV7 TNNfZBRnSrLJoZKr8wJ7tS4tMJLr4NFSY8guksjtaNHcuGKh8dygXm2bH19M GhsdygXdDpGFjsGOXdnP1bfPdUT31nAy2R+h35SkKB3L4ZS07N4J5i8DEb1N FXGOL.g9lqSC6MZfLYnFfviGZlLzwy7sV1HAy3gN8Owb7f4g5.PKB2qFlcey M8jHN1ChlGQpF35mXqtvLY7fYySrpgJrp5S+hQg+crvafV.dWla3u4az70kx Wun9A244dBU5+Dv7HN1FsBhNZ7C0nKiSm6GqNpRUOaKmNjy2RhOxC3UQFvq4 oEAoYU6Rnm0AZqyixFwRt03mUasGEqZXqmkMGiQu.MS3nmsIcPBj83WfTG1P qAJQVGwCUXRZTA6Qc9RwG8yZI0UpgJ1ApVNccHCq1sjurG0xkrjivYtk1CmL okq5efL0EKWGnNOMly9+1SioZiUXI20ChQLtVdMOLlMV84YSp8w2O0le+Tad DhsMLjFQe4NCgssMc8DC6cjm7RZum+RuQwtIkySjSJOQmI9EfXv7j6nfmhRP 3mBMY9Bs4kU6sLqlaarCt0kGKbHYLwgpQrCkDImxyKcHiWxi548fNns28vT7 rELmqbSM5PeFqYVsbCTq9swpM+TzmW6GdALM+5x+k+prX1DjOzT9X3exDzb3 64j2ccxWuN45xeNpnLMeC5d7E.Rd2OdcBpVhjVRbSakbSUIutj+e4pLzGP0v .5OCf.8CP6vuByuhvuhflhtXCOw47D2vSDPmnhfR7A3AjWiaVehD2vKvFYA1 vK.zrUPHmAdcknR5aPJI+j3TWgVDbw0F0O4UWavaOsnDbKW.alBYuTnpTtNI ZABHan0+.x7c7FFp.AVIP1r3BFpVIvpRPNXIHpRPqJw0Iu+8HKjbkik3FUlh .E2nUfVMR+qlx04Wm.b7GP7im7EKB.uB4HzGWOIrHIR8jDr87FkhJRpQor3I IEsJcL31V0sDkjzrjjCWRZyRROTIaJb16KbN6Kbt6Kbd6Kbyd8EtqS.CKvcv mDwm7GTfAQ0CO4OdB8qAeR8qQZXbvt0XMR1KA7HTRFPjL8FUKM1PhWr6atEy yZ7rtXOh3aiGGgj+0Jh7GufZI1sTO.niBb5q7OuZpXRKOzJcFHqpiE4KaD+J 8y.43AwoF50MZnpfASME6WLObWji2ohahRdwoFnUBRSRD7P+zCw1QF4utnG2 SB8TvhAzkl+.h9XnGqWreyBcbjmWdRWbi0IgaB1DDyd.YYY9JauwktcIFb75 zfywkXZ9CoUse0YXErxWPRoS5vQbVooVjsGQv5+ZY0HrDyFFeHd1ldNJomcm oUQR66SPioN6vEFZUY1ap08mVcudqgBmYC.MjF6hyWb3f6CN1mT3P5CNVmL3 3MfNqlL3KIZbG.Z7NYbi0.Pi6ICMjYCrq5DAG7.M5bZfCdn1.ImF3XNp5rFD b1oG8EEOCry5oX0QNc5Nq4NGH6rV66rN66uF6GZ80g14am++.dxn1KB -----------end_max5_patcher-----------
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. :)
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!
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