-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OSC.js RGBA type bug #198
Comments
Hi @dtsmarin, sorry to hear about the trouble. I am having difficulty making sense of the specific issue you think might be happening here. Can you put together a simplified test case that shows the issue, which I can use to examine this more closely? Thanks! |
Hi Colin, I'm trying to read RGBA values sent from Digital Performer. DP appears to sent those values correctly as you can see in the raw buffer. But when I try to decode the message with osc.js I always get a wrong rgba value because OSC.js confuses the type with the red value. I assume that's what is happening. I don't really know what's wrong here. <Buffer 2f 54 72 61 63 6b 4c 69 73 74 2f 30 2f 43 6f 6c 6f 72 2f 47 65 74 00 00 2c 72 00 00 9c ea 32 00, framePos: 0, frameLength: 32, frameEnd: true> 9cea32 (last 00s are the alpha channel) should be { r: 156, g: 234, b: 50, a: 0 } not { r: 44, g: 114, b: 0, a: 0 } No matter what color DP sends I always get this value: |
I'm really sorry, I can't fix this without some kind of a test case. Trying to interpret the issue from a random string of bytes from a Node.js buffer isn't enough to go on. Is there some way you can help me reproduce this? |
I'll try to send a minimal server-client setup in case I manage to replicate the issue with that. The tricky thing is that I'm using frame-stream because of DP's TCP 1.0 spec which does't use SLIP. I only use the low level API of osc.js to send OSC messages and decode the incoming buffers. I don't know if frame-stream complicates things but I tested a lot of other messages and all of them worked fine. I messaged someone familiar with DP's OSC in case DP was the fault but I think that's not the case. Give me some time to make the minimal example If this doesn't help at all. I'm sorry. |
oscjs_rgba_bug.zip |
I threw together a super sketchy manual decoding just for those messages. I only need to read them so I don't have to worry about sending RGBA values to DP. I tested a few examples and it worked comma = buf.indexOf(",");
oscaddress = buf.slice(0, comma).toString();
oscaddress = oscaddress.split('\x00',1)[0]
oscargs = buf.slice(comma + 1, comma + 2);
red = buf.slice(buf.length - 4, buf.length - 3).toString("hex");
green = buf.slice(buf.length - 3, buf.length - 2).toString("hex");
blue = buf.slice(buf.length - 2, buf.length - 1).toString("hex");
alpha = (parseInt(buf.slice(buf.length - 1, buf.length).toString("hex"), 16) / 255).toFixed(1)
let diyosc = {
address: oscaddress,
args: [
{
type: oscargs,
value: {
r: parseInt(red, 16),
g: parseInt(green, 16),
b: parseInt(blue, 16),
a: Number(alpha)
},
},
],
};
console.log(util.inspect(diyosc, { showHidden: false, depth: null, colors: true })); |
I'm getting wrong RGBA values because the library confused the ASCII code for the r type with the red value in the RGBA arg
Here the raw buffer. The last 4 bytes are the RGBA value which is 9cea32
<Buffer 2f 54 72 61 63 6b 4c 69 73 74 2f 30 2f 43 6f 6c 6f 72 2f 47 65 74 00 00 2c 72 00 00 9c ea 32 00, framePos: 0, frameLength: 32, frameEnd: true>
Here is the same packet as decoded by OSC.js
{
address: '/TrackList/0/Color/Get',
args: [ { type: 'r', value: { r: 44, g: 114, b: 0, a: 0 } } ]
}
0x2c72 is the 44 and 114 but 0x72 / 144 is also the ASCII code for the letter ‘r’ which is needed to indicate the type
The text was updated successfully, but these errors were encountered: