Forums > Java

BUG: wrong channel indexing in buf.Op.dataMove


monohusche
Mar 11 2009 | 2:08 pm

dataMove drops the last channel during copying as the channel indexing is wrong (first channel = 1 instead of 0).

for (int c=0;c

needs to be changed to:








for (int c=1;c< =channels;c++)
		{
			MSPBuffer.poke(tobuf, c, 0, MSPBuffer.peek(frombuf, c, 0, size));
		}

R∑N∑G∆D∑ R∆J∆
Mar 12 2009 | 2:15 am

ah, got it, cool, glad you figured it out!

on a sidenote, you could also try removing the "copyInto" method from its MaxSystem.deferlow executable wrapper(as long as you’re not copying hours of data from one buffer~ to another).


monohusche
Mar 12 2009 | 6:55 am

Hi RabidRaja,

firsz of all, thx for your valuable comments all the time.

Regarding the "bug" above, did you change your post later on ? I had an email notifying me of one post of yours where you stated that the channel indexing does indeed start with 0, rather than 1 as indicated by me.

But I couldn’t find that post anymore. I would certainly like me being wrong rather than having found a bug, just let me know.

cheers, nick


R∑N∑G∆D∑ R∆J∆
Mar 12 2009 | 8:30 am

sorry, i changed it because i got confused. basically, indexing starts at 0 when writing externals in C, but apparently not for Java.

although the Java-docs do state that the indexing starts at 0, because i finally got your code to work, i’m thinking you’re right and maybe the original source and docs are wrong.

in any case, check this within your Max folder for class definitions, etc.:

Max5/java-doc/api/index.html

check the classes "AudioFileBuffer" and "MSPBuffer" (look on the index page and then at the frame to the right "All Classes" should be displayed)

AudioFileBuffer refers to audio-files but i was thinking that it wouldn’t be different for audio-buffers since the two need to work together. The "buf" entry on the page describing "AudioFileBuffer" states that buf[0][0….frames-1] is how the channels and samples are referred to(2-dimensional-float-array) and to refer to channel one it states that it would be buf[0](meaning a channel index of 0 for channel 1).

Then I checked the class "MSPBuffer" because dataInto uses MSPBuffer.poke. when looking at the method, "peek" it says, "Indexing starts at 0." for sample-index(this would probably apply to poke, too, it isn’t written in probably because it was already in the peek definition).

But all in all, I read those entries and then tried your code and your code worked when i eventually got it to compile(got confused as to which code i was compiling at first, too). So that makes me think the docs are wrong and you were right.

Either way, I’m glad to hear about the "dataInto" solution and to be able to recompile the source so it works better(i’m just having a strange problem that half the length of the recorded data gets truncated but that’s probably another problem). Anyways, great work!

Viewing 4 posts - 1 through 4 (of 4 total)
Forums > Java