njh / node-red-contrib-osc Goto Github PK

@natcl maybe this is a crazy idea, but is crossed my mind that SLIP encapsulation may have other use cases, other than OSC?

• Would it be weird to have a seperate SLIP node?
• Would it be possible to detect encodes and decodes? String v. Buffer? Or perhaps check for 0xC0 on the beginning/end?

Hello,

I use for a few days your OSC node Red Flow and it's really a great great thing for me!

I have a problem to send to my mixer behringer X32 all the commands that haven't any args. I tried to set the payload null or "" but no way :(

I therefore can't achieve to receive the OSC commands from my mixer because it needs to be activated with the /xremote command withou args. You can find information there : https://sites.google.com/site/patrickmaillot/docs/X32-OSC.pdf

Can you help me find how to encode the OSC message /xremote ou /info or /status

Hi there. I've got a pre-release version of node-red-contrib-music on npmjs, which relies on node-red-contrib-osc. For best functionality, particularly on a Raspberry Pi, it needs to use OSC bundling, which I added in my pull request. I'm using this for a workshop in a school on 5/6th July so it would be great to have it by then.

I can send OSC messages over the network, but not receive them, if they are coming from a different machine. If I send them from the same machine everything is fine.

I don't have a firewall on, and was wondering how to diagnose this problem.
MacBook Pro 2017
Thanks.

It is currently unclear what the purpose/impact for checking the of the 'Metadata' box.

The osc.js README states:

Type-annotated argument objects contain two properties: type, which contains the OSC type tag character (e.g. "i", "f", "t", etc.) and the raw value.

{
    type: "f", // OSC type tag string
    value: 444.4
}

If you are using type-annotated arguments, you should also set the metadata option to true when you instantiate your OSCPort instance (or in the options argument to osc.writeMessage if you're using the low-level API).

It seems like the osc node makes node-red crash if you attempt to use a port that is already in use, see this error log:

15 Feb 13:05:34 - [red] Uncaught Exception:
15 Feb 13:05:34 - Error: bind EADDRINUSE
    at exports._errnoException (util.js:746:11)
    at dgram.js:224:28
    at dns.js:85:18
    at process._tickCallback (node.js:355:11)

21 Jun 11:14:27 - [info] Installed module: node-red-contrib-osc
21 Jun 11:14:27 - [info] Added node types:
21 Jun 11:14:27 - [info] - node-red-contrib-osc:osc : Error: %1 is not a valid Win32 application.
[...] \node_modules\serialport\build\Release\serialport.node

I am not sure why i need to support serial to handle osc?

Hi!
I installed locally via "npm install node-red-contrib-osc" and in the console I get:

[osc] Error: Module version mismatch. Expected 48, got 46.

Then the node doesn't appear in the editor. Tried on 2 different machines, same result.
Thanks!

Hello !
It looks like osc did update its version on npm.
As you rely on it, the current version somehow breaks your node and node red complains on startup.
we fixed by specifying osc: "2.2.3" in our package.json.

Best regards.

This error appears on RaspberryPi "Error: Bad socket type specified. Valid types are: udp4, udp6" when sending on OSC.
This can be fixed by updating node-osc to version 2.0.3 from 1.0.2.
Maintainer therefore should update node-osc dependency to 2.0.3.
Thanks!

Like @nfavrod I am also trying to control a Behringer X32 with this node.

Some commands need the response defined as an integer - e.g.:
/ch/01/mix/on ,i 0

It seems to fail with the ,f number type. Is there any way to force the ,i prefix when outputting data from the OSC node?

Possibility of race condition / wrong message id in output messages

Hello,
I'm new to Node-RED and so this is probably a very elementary question. Right now I'm just trying to learn how to properly format msg.payload so it can carry multiple strings. My use case is to send OSC commands to ZoomOSC. I am using [Protokol] (https://hexler.net/protokol) to get visibility into how my OSC is formatted. I have successfully used TouchOSC to send OSC commands that do what I want them to. For my testing purposes, I am trying to send a chat to Bob that says "Hello world". This is what Protokol looks like when the command is formatted properly from TouchOSC:

You can see that there are multiple strings, marked in purple. I have so far been unable to figure out how to do the same with the node from node-red-contrib-osc. I have been able to successfully send OSC messages to ZoomOSC that do not have any strings, only an address, so I know my networking is correct, etc. It's the strings part that I'm not able to get right. Here's what I have in my flow:

with my injected syntax as this:

Could someone help me understand how to format msg.payload properly, so the end result is what is seen in my first image? Should the object be a string, JSON, etc.? Do I use quotation marks, curly braces, etc.? I'd appreciate any help. Thank you so much!

Hello, I have installed a required osc dependency using npm install with the package.json:

{
    "name": "node-red-project",
    "description": "A Node-RED Project",
    "version": "0.0.1",
    "dependencies": {
        "install": "^0.10.1",
        "node-red-contrib-osc": "^1.0.0",
        "node-red-dashboard": "^2.5.1",
        "npm": "^5.5.1",
        "osc": "^2.2.0",
        "serialport": "^6.0.3"
    }
}

and confirmed that it does exist in the node_modules (under .node-red folder):

eight_io-MacBook-Pro:.node-red eight_io$ ls node_modules/osc
GPL-LICENSE.txt		Vagrantfile		clean-npm.sh		provisioning
Gruntfile.js		bower.json		dist			src
MIT-LICENSE.txt		bower_components	node_modules		tests
README.md		build-support		package.json		yarn.lock
eight_io-MacBook-Pro:.node-red eight_io$ 

Yet when I use an osc example from the menu, it immediately complains about missing osc module:

Separately, I can run fine osc module in a pure nodejs app.

Help would be much appreciated.

Hi there.
I was thinking about starting work on a transport independant osc node for Node-RED and was wondering if you would be interested in merging my code eventually ?

The reason I want to do this is that I would rather use Node-RED's builtin transports (udp, tcp, serial, websockets) rather than having UDP as the only option. This would obviously not be backwards compatible with your current implementation.
This would also fix the issue of broadcast not working over UDP.

Let me know if you'd be interested in this, if not I would create a separate osc object but I think it's always better to have a single one for clarity.