Max and CNMAT OSC help please

Arduino Mega 2560 (I have an old NG somewhere I can use also), Win 7, Arduino IDE 1.6.2, Max 6.1.10 32-bit. If that helps.

I'll try grabbing the latest latest version of CNMAT-Everything, but it appears to be MacOS only

Maybe it's been a long day, but. My own customised sketch works fine: 16 FSRs at 115200 bps. Admittedly, it's reading and sending chronologically, so I'm learning how to power digital pins in parallel, and I've had a suggestion to only send all the sensor values, once they've all been read. Might tighten things up a bit. Can't be bothered with troubleshooting a new encoding/protocol, because of perceived enhancements. Preemptive optimisation indeed.

But I really would like to learn OSC all the same.

Tired little bunny

OPEN Sound Control? Really? More like Secret Arcane Unsupported Language Implementation Mystery. Three days of research and I'm still friggin none the wiser.

F*ck it, serial-USB serves me well, anyone wanna buy some ethernet chips?

(did you try contacting people at CNMAT directly ?...)

it's off topic, but you've got 16 fsrs hooked up to an arduino? Sounds like a great project! I've been meaning to convert my Trigger Finger into something a bit more... hacky :D

Which fsrs are you using? The sparkfun ones?

Keep your ethernet chips! There is no need for OSC to communicate with an arduino over ethernet (there are udp examples in the arduino's IDE). Instead of [udpreceive], use [mxj net.udp.recv ] or sadam's library to receive the UDP packets in Max.

urgh, mxj net.udp.recv is pretty ugly though, it binds to the port, so you basically have to reserve special ports for special destinations... that's pretty limiting, don't you think? IIRC the s adam lib does the same thing?

Hi guys, thanks for responding to my ugly little rant there.

@vichug, I've signed up to CNMAT, but 3 days later and still no response. There's a paper by Dave Wessel from 2004 that's really relevant, and might help clarify things, but I can't access it yet. I've heard that Adrian Freed is quite apporachable, so once my subscription to CNMAT goes live, I'll consult him.

@Wetterberg, at the moment the interface consists of 16 x DIY FSR (copper fabric and Velostat sandwich) embedded below a small DIY silicone disc/pad, each with an embedded LED. It's being reworked at the moment though, in light of a better solution I have devised. Top secret hush hush.

@Patrick/everyone. I need to get a handle on the whole UDP protocol/system first I think, but the udpsend/receive helpfiles will make a good start.

I just find it very frustrating that for a beginner, the whole CNMAT-Everything package is a bit daunting, and not very clearly laid out. Might just put it to one side for the moment. As I keep saying though, I'd still like to become OSC_fluent, as it seems to be growing in popularity.

Brendan

Hi Brendan,

I'm sort of in the same boat with OSC, so here's some of the things I've encountered that might be of help for you.

- I've been wrestling with the SlipEncodedSerial OSC message building from Arduino to Max as well, and thought it wasn't worth the trouble. I don't see an advantage in encoding to slip OSC and decoding slip OSC again at the Max side of things. So whatever an Arduino sends to Max is a plain old serial string or number. If I want to turn that into OSC, Max will take care of it.

Here's how to make life so much easier:

If you want a sensor value to enter Max from the Arduino, turn it into an 8 bit number. For most purposes, that's more than adequate. For instance, if I want analog sensor 0 to become an OSC message, this is my Arduino code:

void setup()
{
Serial.begin(9600);
}

void loop()
{
// read the input on analog pin 0:
int sensorValue = analogRead(A0);
char c = map(sensorValue, 0, 1023, 0, 255);
Serial.write(c);
delay(1); // delay in between reads for stability
}

The advantage is that you can have a really simple serial receiver in Max. No need to flush out line ends etc. Not a gazillion numbers that represent a slip OSC message. So [0..255] travels to Max, and there you will scale it further to a floating point message in the range [0.0 .. 1.0], which is the default for just about every OSC parameter.

Again, I see little reason to use the CNMat packages, when you can create your OSC addresses simply with a Max message box as in the above example. In this example I [udpsend] to two devices, one being Reaktor running on the same machine and listening to port 8000 and the other being my iPad running TouchOSC listening to port 9000.

The cool thing about UDP/OSC is that you can have everything happening simultaneously. So you can have an Arduino parameter entering Max via serial and going out to several devices on whatever networked machine they happen to be running. And another process can even transmit the same OSC message and it'll still work.

Which brings me to another point: it's more fun experimenting with OSC if you have at least a few things that work great. I happen to be on OSX, but here's a few things I really enjoy using with OSC:

- Reaktor. It's super easy to map a parameter to OSC. Right click on any control and choose OSC learn.

- TouchOSC on my iPad is also gold. You can create your own layouts with custom addresses. It can also transmit accelerometer data via OSC.

- Python. I'm using python-osc (pip3 install python-osc). It's super reliable, e.g.:

import time

from pythonosc import osc_message_builder
from pythonosc import udp_client

client = udp_client.UDPClient('192.168.178.26', 1234)

for idx in range(0, 100):
msg = osc_message_builder.OscMessageBuilder(address = '/hey')
msg.add_arg(idx)
msg = msg.build()
client.send(msg)
print(idx)
time.sleep(1)

Then have Max listen to port 1234:

Have fun!