The best way to get samples from a buffer in mxj~


    Apr 30 2007 | 10:44 am
    Greetings Java list, I am a great fan of mxj.
    I'm working on an mxj~ that plays sounds from preloaded buffer~s and
    I want to be able to chose which buffer~ the mxj~ reads samples from
    at the point of triggering the sound. In C that means grabbing a
    pointer to the buffer and immediately being able to access the
    samples in the perform routine, easy and very fast. But in Java the
    equivalent seems to involve calling MSPBuffer.peek() every time you
    want a sample, which seems to be incredibly heavy. Grabbing all of
    the samples at the start of the operation (also using MSPBuffer.peek
    ()) speeds up the perform routine, but means you can't access large
    buffers instantaneously. Previous posts on this list suggest that the
    problem simply comes down to the unavoidable overhead of the
    interaction between C and Java.
    I don't know anything about JNI, but I imagine that the bottom line
    is that accessing a C array as quickly as possible means copying it
    into a Java array first. Is that right? Are there any clever ways to
    get the data more quickly (whilst still having access to the whole
    buffer)? Perhaps it's best to make my own Java buffers.
    Thanks,
    Ollie Bown

    • May 01 2007 | 3:35 am
      Hi Ollie,
      In the past there has been some talk amongst the mxj development team
      about trying to figure out a way to "wrap" a C buffer~ inside a java
      array data container in order to trick Java and C buffer~ objects into
      using the same memory. However it doesn't look like we're going to be
      able to devote any energy towards that end for quite some time. If
      memory is not at a premium, you could perhaps make an abstraction that
      contains both a regular buffer~ object and a paired mxj object whose
      sole job is to move the buffer~ data into a Java array for quick
      access by your playback objects. It's not a very elegant solution,
      but it may do the trick.
      Ben
    • May 01 2007 | 8:30 am
      Thanks Ben, that's a neat idea which I'd love to see implemented.
      Presumably there are other contexts (beyond Max/MSP) where developers
      would be interested in this dual memory access for one reason or
      another. In the meantime, space IS an issue so I guess I'm going to
      take the leap into the Java void and use AudioFileBuffer.
      On 1 May 2007, at 04:35, Ben Nevile wrote:
      > Hi Ollie,
      >
      > In the past there has been some talk amongst the mxj development team
      > about trying to figure out a way to "wrap" a C buffer~ inside a java
      > array data container in order to trick Java and C buffer~ objects into
      > using the same memory. However it doesn't look like we're going to be
      > able to devote any energy towards that end for quite some time. If
      > memory is not at a premium, you could perhaps make an abstraction that
      > contains both a regular buffer~ object and a paired mxj object whose
      > sole job is to move the buffer~ data into a Java array for quick
      > access by your playback objects. It's not a very elegant solution,
      > but it may do the trick.
      >
      > Ben
    • May 01 2007 | 4:56 pm
      you could also look at
      com.cycling74.msp.AudioFileBuffer.
      it allows you to load an audio file into memory purely in java.
      t
      On May 1, 2007, at 01:30 AM, Oliver Bown wrote:
      > Thanks Ben, that's a neat idea which I'd love to see implemented.
      > Presumably there are other contexts (beyond Max/MSP) where
      > developers would be interested in this dual memory access for one
      > reason or another. In the meantime, space IS an issue so I guess
      > I'm going to take the leap into the Java void and use AudioFileBuffer.
      >
      > On 1 May 2007, at 04:35, Ben Nevile wrote:
      >
      >> Hi Ollie,
      >>
      >> In the past there has been some talk amongst the mxj development team
      >> about trying to figure out a way to "wrap" a C buffer~ inside a java
      >> array data container in order to trick Java and C buffer~ objects
      >> into
      >> using the same memory. However it doesn't look like we're going
      >> to be
      >> able to devote any energy towards that end for quite some time. If
      >> memory is not at a premium, you could perhaps make an abstraction
      >> that
      >> contains both a regular buffer~ object and a paired mxj object whose
      >> sole job is to move the buffer~ data into a Java array for quick
      >> access by your playback objects. It's not a very elegant solution,
      >> but it may do the trick.
      >>
      >> Ben
      >
    • May 01 2007 | 5:14 pm
      sorry ollie.
      somehow i missed you mentioning that exactly!
      t
      On May 1, 2007, at 09:56 AM, topher lafata wrote:
      > you could also look at
      > com.cycling74.msp.AudioFileBuffer.
      > it allows you to load an audio file into memory purely in java.
      > t
      >
      > On May 1, 2007, at 01:30 AM, Oliver Bown wrote:
      >
      >> Thanks Ben, that's a neat idea which I'd love to see implemented.
      >> Presumably there are other contexts (beyond Max/MSP) where
      >> developers would be interested in this dual memory access for one
      >> reason or another. In the meantime, space IS an issue so I guess
      >> I'm going to take the leap into the Java void and use
      >> AudioFileBuffer.
      >>
      >> On 1 May 2007, at 04:35, Ben Nevile wrote:
      >>
      >>> Hi Ollie,
      >>>
      >>> In the past there has been some talk amongst the mxj development
      >>> team
      >>> about trying to figure out a way to "wrap" a C buffer~ inside a java
      >>> array data container in order to trick Java and C buffer~ objects
      >>> into
      >>> using the same memory. However it doesn't look like we're going
      >>> to be
      >>> able to devote any energy towards that end for quite some time. If
      >>> memory is not at a premium, you could perhaps make an abstraction
      >>> that
      >>> contains both a regular buffer~ object and a paired mxj object whose
      >>> sole job is to move the buffer~ data into a Java array for quick
      >>> access by your playback objects. It's not a very elegant solution,
      >>> but it may do the trick.
      >>>
      >>> Ben
      >>
      >