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 >> >