Forums > Java

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

April 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 1, 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 1, 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 1, 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 1, 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
>>
>


Viewing 5 posts - 1 through 5 (of 5 total)