SerialOSC not updating on monome connect/disconnect

Been having this problem for a while here and wondering if there’s a solution already out there.

I’m finding that if I connect a monome to the computer, serialosc always fails to detect it. I see ‘serialosc-detector’ and ‘serialoscd’ running but no ‘serialosc-devic’ appears. If I then restart the computer with the monome plugged in then all is well.
Unplugging the monome, serialosc usually won’t update (the device is still listed) and when plugging it back in again it will no longer work until another restart.

I’m on a clean install of OSX 10.12 and had the same problems on a different laptop running 10.11. I tried installing the FTDI VCP driver just for kicks, but am now back to having removed FTDIUSBSerialDriver.kext

Anyone else have the same, got any solutions?
Is there at least a way of refreshing serialosc so I don’t have to restart the computer?

Thx!

Well, not sure what I did since writing that message but I now can’t get this new machine to ever detect a monome grid even after restarting :anguished:

@markeats I just received a new MBPro a few days ago, with Mac os sierra 10.12.1 and I am experiencing the same problems, you described with my grid 128 and arc.

This is kind of frustrating because I thought working with Mac OS would solve the problems I had with Win10.

Hope someone can help us out.

@mheton I emailed Brian about this, will report back with progress…

What’s weird is that it’s exactly the same problem I and a lot of people experienced on Win10 (basically, hotplugging not working at all, and no way to refresh without restarting computer) is there a fundamental flaw with SerialOSC’s current version or are both OS updates fucking up with the service?

i have this problem also using win7 and linux (ubuntu/raspian) –
just can’t use my switch to alternate between ww and linux or windows 7.

OS upgrades are always a nightmare, across all technologies. so let’s figure this out (again, and again)

first it’s important to figure out if the FTDI driver is working, which is the main point of failure.

on Mac there are two drivers-- the built-in default one by Apple, and the FTDI-VCP driver supplied from the manufacturer: http://www.ftdichip.com/Drivers/VCP.htm

to check (on Mac) if your device is being detected, open a Terminal and type:

ls -lrt /dev

and towards the bottom, if it worked, you should see something resembling

tty.usbserial-m0000000

until you get to this step, serialosc will absolutely not work.

if you want to go deep and test the FTDI-supplied driver: http://www.ftdichip.com/Support/Documents/AppNotes/AN_134_FTDI_Drivers_Installation_Guide_for_MAC_OSX.pdf

i’m upgrading to 10.12 right now, will share my results later this afternoon.

if you’re experiencing full failure, please post here with your OS version, machine used, monome device and edition.

1 Like

thanks for looking into this!

when running ls -lrt /dev I see my devices listed but only if they have been connected when the computer starts up. If I unplug/reconnect them then they are not listed. Either way, SerialOSC doesn’t seem to be listing them.

I’m on 10.12.1, new MacBook Pro 15" with touchbar, with gs128 and 256 varibright grids.

1 Like

this is an FTDI issue then, first and foremost. do you get the exact behavior with both FTDI drivers?

1 Like

The test I just ran then was with the default apple driver. I tried installing the VCP driver but I’m not sure I’m doing it right - can I somehow check it’s being used? I wasn’t sure how to disable the apple driver on 10.12

If there’s a similar way to test that behaviour on Win10 64bits with a 128 Vari 2012 I’d be very interested.

check your system profiler (device manager?) and you should be able to find a monome entry in the USB device tree

has anyone e-mailed FTDI? i’m writing their tech support now to see if 10.12 is officially supported.

i’m on 10.12. i initially had some very similar issues (though only on apple’s driver, never ftdi’s).

it turns out that macOS was secretly trying to use the grid as a usb networking device, and sometimes showed up as a thunderbolt–interface networking dongle. i had to open up the network preferences panel, add a formal device entry for the grid, and then tell macOS to not use that device, and further disable the entry i’d made.

at the time, i put it down to the serialosc interface conflicting with the host’s attempt to categorize the grid differently than intended. had to resort to the same workarounds when plugging in the arc for the first time. otherwise it was being hogged when hotplugged; was fine when connected at boot.

1 Like

so, it works as expected after this workaround?

yes, no further issues with arc or grid after performing the workaround for each.

the OS had been grabbing the device, conflicting with serialosc, attempting to use it as a networking interface. would often pop up windows asking to add it as such. but until i added an actual preferences entry, with instructions to ignore/disable that “network” device, i kept getting popup prompts that interfered with using it with serialosc apps. macOS needed to be told what to do with it, rather than leave it hanging.

2 Likes

from FTDI support:

The version 2.3 FTDI VCP driver should work well with OS 10.12

Keep in mind you also have the option of using Apple’s own version of the FTDI VCP driver – AppleUSBFTDI

i halted my install of 10.12 earlier today because i couldn’t risk disabling my only mac (during production particularly) but i’ll get it installed tonight and confirm this fix.

1 Like

@ioflow is this what you mean in terms of disabling (see screenshot)?
just tried this but seeing no difference, still on the apple driver for now.

that looks right, but i also went through dropdown menu (at bottom left) and right-click options on both monome devices to rearrange the service order. i have both the “monome” and “monome-” at the top, followed by the “real” networking services. i rebooted a couple of times to make it stick.

also, i don’t even have a “test” configuration listed; i keep it at the defaults in an attempt to make sure macOS doesn’t actually try to do anything with the device. the whole arrangement is pretty hand-wavy. the OS goes out of its way to hide things; what it’s doing and why it’s doing it. makes it very hard to troubleshoot and reconfigure.

2 Likes

hmm thanks for the info :slight_smile: seems like my problems run deeper though :confused: