BUG: wrong channel indexing in buf.Op.dataMove
dataMove drops the last channel during copying as the channel indexing is wrong (first channel = 1 instead of 0).
for (int c=0;cneeds to be changed to:
for (int c=1;c< =channels;c++) { MSPBuffer.poke(tobuf, c, 0, MSPBuffer.peek(frombuf, c, 0, size)); }
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).
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
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!