Forums > Java

[BUG] outletHigh(int outletIdx, java.lang.String message, float[] values)

September 1, 2011 | 11:19 am

There seems to be a bug with outletHigh(int outletIdx, java.lang.String message, float[] values) and outletHigh(int outletIdx, java.lang.String message, int[] values).

It appears when calling outletHigh(int outletIdx, java.lang.String message, float[] values), the float values are being passed to C as *int because integers values (that I’m guessing have the same bit values as the floats we are trying to output) are being sent to Max. I’m guessing that this is also happening with outletHigh(int outletIdx, java.lang.String message, int[] values) because of the conversion from int to float when using DataTypes.ALL.

Below is an example patch and Java class that demonstrates the bug. The two red message boxes (testOutletHighWithMessageAndFloatArray and testOutletHighWithMessageAndIntArray demonstrate the bug. The other messages demonstrate expected behavior.

– Pasted Max Patch, click to expand. –

// OutletTest.java

package junk;

import com.cycling74.max.Atom;
import com.cycling74.max.MaxObject;

public class OutletTest extends MaxObject {

private static final float myFloatArray[] = {3.2f, 1.9f, 0.0f, -2.5f, -3.1f};
private static final float myIntArray[] = {1, 2, 3, 4, 5};

public void testOutletHighWithFloat() {
outletHigh(0,myFloatArray[0]);
}

public void testOutletWithFloat() {
outlet(0,myFloatArray[0]);
}

public void testOutletHighWithFloatArray() {
outletHigh(0,myFloatArray);
}

public void testOutletWithFloatArray() {
outlet(0,myFloatArray);
}

public void testOutletHighWithMessageAndFloatArray() {
outletHigh(0,"testOutletHighWithMessageAndFloatArray",myFloatArray);
}

public void testOutletWithMessageAndFloatArray() {
outlet(0,"testOutletWithMessageAndFloatArray",myFloatArray);
}

public void testOutletHighWithFloatToAtomArray() {
outletHigh(0, Atom.newAtom(myFloatArray));
}

public void testOutletWithFloatToAtomArray() {
outlet(0, Atom.newAtom(myFloatArray));
}

public void testOutletHighWithMessageAndFloatToAtomArray() {
outletHigh(0,"testOutletHighWithMessageAndFloatToAtomArray", Atom.newAtom(myFloatArray));
}

public void testOutletWithMessageAndFloatToAtomArray() {
outlet(0,"testOutletWithMessageAndFloatToAtomArray", Atom.newAtom(myFloatArray));
}

public void testOutletHighWithInt() {
outletHigh(0,myIntArray[0]);
}

public void testOutletWithInt() {
outlet(0,myIntArray[0]);
}

public void testOutletHighWithIntArray() {
outletHigh(0,myIntArray);
}

public void testOutletWithIntArray() {
outlet(0,myIntArray);
}

public void testOutletHighWithMessageAndIntArray() {
outletHigh(0,"testOutletHighWithMessageAndIntArray",myIntArray);
}

public void testOutletWithMessageAndIntArray() {
outlet(0,"testOutletWithMessageAndIntArray",myIntArray);
}

public void testOutletHighWithIntToAtomArray() {
outletHigh(0, Atom.newAtom(myIntArray));
}

public void testOutletWithIntToAtomArray() {
outlet(0, Atom.newAtom(myIntArray));
}

public void testOutletHighWithMessageAndIntToAtomArray() {
outletHigh(0,"testOutletHighWithMessageAndIntToAtomArray", Atom.newAtom(myIntArray));
}

public void testOutletWithMessageAndIntToAtomArray() {
outlet(0,"testOutletWithMessageAndIntToAtomArray", Atom.newAtom(myIntArray));
}
}


October 29, 2011 | 10:44 am

Hi, just wanted to mention this bug still exists in Max6.

I made a C external to test my theory about the float bytes being treated as int bytes (or being assigned to floats before being treated as ints in the case of outletHigh(int outletIdx, java.lang.String message, int[] values).

I’ve attached the external, the source code, and an updated example patch using the external in case that is useful in getting this bug fixed or if anyone needed to use this external to work around this bug.

Right now this external was quickly made to test my theory about the bug, so you will notice that it only appropriately handles output from the mxj when outletHigh(int outletIdx, java.lang.String message, float[] values) or outletHigh(int outletIdx, java.lang.String message, int[] values) are used and I have not tested it for performance at all. I will upload another version later when I add code to handle all possible outlet(...) and outletHigh(...) calls.

Let me know if there is anything else I can do to help squash this bug.


October 29, 2011 | 6:23 pm

Thanks for being patient and persistent. This is fixed in a forthcoming 6.0.1


October 30, 2011 | 11:16 am

Cool, thanks! Liking Max6 so far and I’m sure it will only be getting better.

I’m not in any particular rush for it, but would it be possible at some point to get more of the overloaded methods we have for outlet(...) written for outletHigh(...)? All of the char, long, double stuff doesn’t really seem important since we don’t have multiple integer and floating point types in Max, but versions that send single values instead of arrays could be useful.

I suppose these would be the methods on my wish list:


outletHigh(int outletIdx, Atom value)
outletHigh(int outletIdx, java.lang.String message, Atom value)
outletHigh(int outletIdx, java.lang.String message, float value)
outletHigh(int outletIdx, java.lang.String message, int value)


November 7, 2011 | 11:25 pm

Sorry I didn’t notice this before (don’t know if you did when checking the bug—my original post shows this problem), but when using the C external to I posted above to fix the bugged output I noticed that these two bugged methods also output on the main thread, not the scheduler thread as the other outletHIgh(...) methods do when overdrive is on.


November 21, 2011 | 9:06 pm

I just had a chance to try this with 6.0.1. The float output from these messages works correctly now, but outletHigh(int outletIdx, java.lang.String message, float[] values) and outletHigh(int outletIdx, java.lang.String message, int[] values) seem to still output to the main thread not the scheduler thread.

Again, sorry I didn’t notice this in my original bug report.


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