Non-realtime use of [buffer~]


    Sep 04 2008 | 12:52 pm
    Hello,
    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.
    Therefore, isn't there a better solution ? Of course Max is basically a "realtime" program, but it's something very simple to do from the computer's point of view so it should be possible to do this. Perhaps using a javascript module ? It would be interesting to have access to buffers~ with javascripts. Is it possible ?
    All this in Max 4.6 unfortunately ...
    Thanks for your help -j

    • Sep 04 2008 | 1:22 pm
      On 4 sept. 08, at 14:52, julienbreval wrote:
      > - copying the contents of B1 and B2 to B, using either [peek~] or > [poke~].
      Did you have a look at [mxj Buf.Op]? (while you're exploring buf.Op, look at f0's modifications : http://www.fredrikolofsson.com/ )
      > Perhaps using a javascript module ? It would be interesting to have > access to buffers~ with javascripts. Is it possible ?
      It is in Java.
      _____________________________ Patrick Delges
      Centre de Recherches et de Formation Musicales de Wallonie asbl http://www.crfmw.be/max
    • Sep 04 2008 | 2:25 pm
      Thank you Patrick
      It looks really interesting
      I am not a Java / Max specialist but I will have a look at it
      -j
    • Sep 05 2008 | 7:55 am
      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
    • Sep 19 2008 | 11:42 am
      julienbreval schrieb: > * [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...)
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Sep 19 2008 | 2:20 pm
      ok
      but as you say the uzi function "tries" to do something, it's not so reassuring :(
    • Sep 19 2008 | 7:50 pm
      > 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 > >
      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.
      Eric
    • Sep 20 2008 | 3:46 pm
      Thanks a lot Eric, I will try it for sure
    • Aug 04 2017 | 8:24 pm
      How exactly do the arguments of overdub work. Say, If I want to join buffer 'one' with buffer 'two' both with the same length. I can't get a message box with 'overdub one 0 0 1 1000 0 0' to work in the object el.buffet two
    • Aug 05 2017 | 5:49 am
      Overdub option was not a part of putpourri 2, custom version of el.buffet with overdub option was uploaded here some years ago. Putpourri 3 has the overdub built in, but help file does not reflect it. I have not tested version 3 as it is only for max 6.1 and 7,¨but version 2 works perfectly.
    • Aug 07 2017 | 9:24 am
      Hmm, I have potpourri 3 and only the reference is reflecting the overdub, you're right about that. My Max crashes anyway. here is the patch:
      Where is that Buff-Ovdb coming from?
    • Aug 07 2017 | 4:52 pm
      Ah I uploaded by mistake reference for el.buffet which I modified to accept samples as argument and 4 channels instead of just 2, but that is version 2, so only 32 bit. I renamed it to Buff-Ovd
    • Aug 07 2017 | 5:07 pm
      You could also use [jit.buffer~]:
    • Aug 07 2017 | 5:13 pm
      @Source Audio It still crashes my max. Do you know why? I use js for it in a for loop, but that takes at least 180 ms.
      @Jean-Francois Interesting idea with Jitter. The only thing is, I have the two buffers after one another, I need them at the same time, overdubbed. mxj buf.Op does something similar with merge, but it creates an additional track.
    • Aug 07 2017 | 7:07 pm
      In the patch I attached, you get both sounds in a 20-second buffer, that's what you want, right?
    • Aug 08 2017 | 7:17 am
      I think by Overdub is meant mix of 2 buffers, not copy the second at the end of the first one. jit.xfade~ can do the mix job, You need jit.buffers for all buffers, I still prefer el.buffet in old version
    • Aug 08 2017 | 10:20 am
      That is right, I meant mixing the two. The solution you propose with jitter is pretty good. Unfortunately, I can't get the old version (I guess version 2) of el.buffet to work.
    • Aug 08 2017 | 2:03 pm
      Indeed, to mix with a [jit.buffer~] solution, you could use [jit.xfade] or two [jit.op @op *], etc.
    • Aug 08 2017 | 4:13 pm
      Since I got into a lot of trouble with recording with overdubbing synced to the global transport, I thought copying buffers offline could give me a solution.
      (I have tried poke~ resulting to clicks and audio dropouts) (I have tried ipoke~ resulting to an error for infinity) (I have tried uzi, not fast enough) (el.buffet, overdub doesn't work) (karma~, not transport synced) (buf.Op, can't resize) etc.
      and now js, resulting to a gui freeze
      The original was with javascript:
      function list(nrofdubs, amount, delay) //add dubs { var dubzL = new Array(amount); var dubzR = new Array(amount);
      for(i=0;i<amount;i++){ dubzL[i] = 0; dubzR[i] = 0; for(j=0;j<nrofdubs;j++){ dubzL[i] += overbuf.peek(1,j*amount+(i-delay),1); dubzR[i] += overbuf.peek(2,j*amount+(i-delay),1); } } destinationbuf.poke(1,0,dubzL); destinationbuf.poke(2,0,dubzR);
      It didn't matter that this took some time to calculate, because I play the audio anyway and switch only to the new buffer after this js calculation. The problem lies within the fact that my gui freezes for at least 180 ms per for loop, so 20 overdubs gave me 2 s freeze of the whole gui.
      I will try to implement this jit.buffer to get the results I am looking for.
      any more ideas welcome :)
    • Aug 14 2017 | 11:51 am
      How does the jit.xfade work on a stereo buffer? It somehow crops the selected outputlength to half the size.
    • Aug 14 2017 | 12:13 pm
      Not for me, in Max 6 it copies/merges exactly the length set by outputlength message, mono or stereo, doesn't matter. 16 bit 44.1 Khz, I did not bother to test other hardware settings.
    • Aug 24 2017 | 5:18 pm
      The jit.op did the job!
    • Aug 25 2017 | 8:02 am
      you could look at the Mubu Buffer objects too