Non-realtime use of [buffer~]
This message has to do with audio buffer managing, copying, moving, etc. in "non realtime" (at least from the user’s point of view). If the topic has already been discussed, please give me a link to it.
The basic problem is really simple: we want to load TWO audio files into ONE buffer~. The classic [read( and [replace( messages first clear the buffer so it's perhaps not the right solution.
Example with "File1" (10 seconds) and "File2" (5 seconds).
We should be able to create a 20-second buffer (for example), containing:
- nothing (silence) from 0 s to 1 s
- "File1" from 1 s to 11 s
- nothing (silence) from 11 s to 13 s
- "File2" from 13 s to 18 s
- nothing (silence) from 18 s to 20 s
The only solution I know is the following one:
- creating two buffers (B1 and B2) for storing "File1" and "File2"
- creating a third buffer (B)
- copying the contents of B1 and B2 to B, using either [peek~] or [poke~].
The trouble start here, as [peek~] and [poke~] are way too slow (or, say, adapted to realtime use):
* [peek~] works at the message scheduler speed, so I don’t know the maximum speed at which you can copy information from a buffer to another, but it’s not something reliable anyway
* [poke~] works at signal speed, so you can copy 44100 samples per second. Then is it possible to read faster than the sample rate ? Of course, 4x oversampling (which should be possible in a subpatch, if the sound cards supports it) is still way too slow.
All this in Max 4.6 unfortunately …
Thanks for your help
On 4 sept. 08, at 14:52, julienbreval wrote:
> – copying the contents of B1 and B2 to B, using either [peek~] or
Did you have a look at [mxj Buf.Op]? (while you’re exploring buf.Op,
look at f0′s modifications : http://www.fredrikolofsson.com/ )
It is in Java.
Centre de Recherches et de Formation Musicales de Wallonie asbl
Thank you Patrick
It looks really interesting
I am not a Java / Max specialist but I will have a look at it
On Max 4.6
Eric Lyon’s el.buffet~ external could be useful as it allows fast copying from one buffer to another, but i don’t think it’s possible to merge buffers using el.buffet~? so i’m also using mxj buf.op
> * [peek~] works at the message scheduler speed, so I don’t know the
> maximum speed at which you can copy information from a buffer to
> another, but it’s not something reliable anyway
It is reliable, and fast if you just hook up uzi to bang the values in
and out. It is so fast, that it might block your UI for a second…
(uzi will try to bang all out within one scheduler tick…)
but as you say the uzi function "tries" to do something, it’s not so reassuring :(
> On Max 4.6
> Eric Lyon’s el.buffet~ external could be useful as it allows
> fast copying from one buffer to another, but i don’t think it’s
> possible to merge buffers using el.buffet~? so i’m also using mxj
Actually buffet~ can do this too, with the "overdub" message. For the current example, load both soundfiles into their own buffers. Then make an empty 20 second buffer. Then overdub the first soundfile at 1 second into the empty buffer, with a 10 second duration. Then overdub the second soundfile buffer to the no longer empty receiving buffer, skipping in 13 seconds with a duration of 5 seconds. All buffers need to have the same number of channels. The message is self-documenting. Just say "overdub" to any buffet~ object, with no arguments.
Thanks a lot Eric, I will try it for sure