if not, you at least have to change the device string if you don’t want to use serialosc.
i’ll dig out a mac and sanity-check real quick. i think i have 10.14.6 somewhere.
… yeah, working for me. 2016 MBP with the adapter, macOS 10.14.6, a relatively recent m128.
(i have some kind of waf/cython problem that seems obnoxious to fix, so built this with gcc and whatever build of libmonome i already had installed… so i guess that doesn’t technically rule out some recently-introduced problem with the lib.)
here’s the test, takes a device string instead of hardcoded UDP address, and doesn’t initialize with a port number.
or wait… do you just mean that the program never exits and is always in select waiting for monome events? that’s all it’s supposed to do - it’s a very basic example.
you would want to run this in a thread, handle disconnect/reconnect events, yadda yadda.
sorry right. that is the default dev path for linux, it just counts up with more ttyUSB devices.
on macos you get a string related to the device serial number (or something.)
e.g. on mine it’s /dev/tty.usbserial-m1000364 right now but yours will be something different.
Well I rebooted, and loaded/unloaded serialosc, and the /dev/tty.usbserial-m******* appeared. The example now works. So that’s progress
How can I auto-detect that path?
I suppose I’m not clear on how I should go about writing a macOS app that interfaces with the grid as simply and automatically as possible.
It seems at first glance that the Apple-recommended way to this would be to write an application-space driver using IOKit. OTOH, perhaps I should just assume that any grid user will have serialosc running? (For example Mark Eats Sequencer seems to assume serialosc is running. It also doesn’t use libmonome as best I can tell.)
serialosc is heavily multi-processed. e.g. spawns server process for each device.
again i didn’t author it but i can think of several reasons:
fault tolerance (this is why e.g. chrome is multi-process)
precisely b/c it’s platform-specific (libudev and windows versions are totally different)
easy ‘big-hammer’ lifecycle mgmt from the supervisor daemon
i dunno, it’s not an uncommon pattern in systems development, love it or hate it.
but anyways, i typically don’t want to use OSC either for applications talking to grid, and just roll my own monitor thread. serialosc detector is a fine example and the architecture makes it very easy to re-use.
[mod hat] i’ve changed the title of the topic; assuming we’ve addressed the original question and are moving on to more general questions.