Ollie Bown

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 

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.

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.

the-best-way-to-get-samples-from-a-buffer-in-mxj

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,

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.

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:

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

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.

> 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


it allows you to load an audio file into memory purely in java.

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:

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

>> using the same memory. However it doesn't look like we're going 

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

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

you could also look at
com.cycling74.msp.AudioFileBuffer.
it allows you to load an audio file into memory purely in java.
t

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


somehow i missed you mentioning that exactly!

On May 1, 2007, at 09:56 AM, topher lafata wrote:

> it allows you to load an audio file into memory purely in java.

> 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 

>> On 1 May 2007, at 04:35, Ben Nevile wrote:

>>> In the past there has been some talk amongst the mxj development 

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

>>> using the same memory. However it doesn't look like we're going 

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

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

sorry ollie.
somehow i missed you mentioning that exactly!
t

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


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