Skip to content
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

Open
dtsmarin opened this issue May 5, 2022 · 6 comments
Open

OSC.js RGBA type bug #198

dtsmarin opened this issue May 5, 2022 · 6 comments

Comments

@dtsmarin
Copy link

dtsmarin commented May 5, 2022

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

@colinbdclark
Copy link
Owner

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!

@dtsmarin
Copy link
Author

dtsmarin commented May 6, 2022

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:
{
address: '/TrackList/0/Color/Get',
args: [ { type: 'r', value: { r: 44, g: 114, b: 0, a: 0 } } ]
}

@colinbdclark
Copy link
Owner

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?

@dtsmarin
Copy link
Author

dtsmarin commented May 6, 2022

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.
He mentioned:
''Looks like the OSC library is misinterpreting that data. Not sure where it’s getting those numbers from but they don’t appear anywhere in that buffer.
0x2c72 would be the 44 and 114 you see. 0x72 / 144 is also the ASCII code for the letter ‘r’ which is needed to indicate the type. So I think it’s just a bug where it’s misinterpreting the wrong part of the buffer as the color. And that part will also be the same across all the messages hence why you’re getting the same result for all of them. The color is actually in the next part of the buffer."

Give me some time to make the minimal example If this doesn't help at all. I'm sorry.

@dtsmarin
Copy link
Author

dtsmarin commented May 8, 2022

oscjs_rgba_bug.zip
The structure is a bit flipped because I don't know how to send OSC messages when a specific message is received but the problem is still there. I hope this is helpful.

@dtsmarin
Copy link
Author

dtsmarin commented May 8, 2022

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 }));

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants