I think you actually want to remove the VCP FTDI and keep the default apple driver

you need to delete the FTDI driver. in 10.12.1 the apple one works correctly, and the FTDI one interferes.

Thank you both. I seemed to be having issues before I even installed the FTDI driver, but maybe some magic combination of the networking sorted it out. Seems to be working now, cheers.

@tehn I have this exact issue where I have to restart to use monome and I see the monomes listed in the network options, but I’m on OSX 10.11.6 (Mac Pro Late 2013). The Monome (Grayscale 64) works fine, but if I unplug it and plug it back in I have to restart.

I see serialosc-detector and serialoscd in my activity monitor. If I restart and have the monome plugged in, that will show up addionally as monome-devic. If I unplug it “monome-devic” stays on the list but seemed to dissappear right when I plugged in the monome again.

I also see monomes in the network like in the screenshot someone posted. Making this inactive and putting them at the top of that set list didnt seem to fix it for me. I also do not have any .kext files that start with FTDI but I do have the AppleFTDI one that you said should be there.

The monome shows up in the System Information for the USB devices when it is plugged in, even when Activity Monitor doesn’t show the monome-devic and monome home does not detect it.

Using the Terminal command I do not get anything like “tty.usbserial-m0000000” (at least when the monome is not detected by monome home / been replugged in. I have not tried this command while it is functioning)

…this sounds like the exact behavior I saw when a non-Apple FTDI driver was installed (I’ve also found the USB3 ports on the Mac Pro Late 2013 to be more finicky than any other machine I use).

To verify you are using the Apple driver and not something else:

  1. disconnect your grid and reboot the machine
  2. connect the grid, wait 5 seconds, and enter the following command in the terminal:

kextstat -l | grep -i ftdi

…the output should be one line which contains com.apple.driver.AppleUSBFTDI - if it doesn’t you have another FTDI driver installed. Find it, remove it, and reboot (see instructions above).

I’ve been using the Apple supplied FTDI driver and serialosc 1.4 on a Mac Pro 2013 under both 10.11 and 10.12 without issue.

Yes it is showing up as “com.apple.driver.AppleUSBFTDI (5.0.0)” when I do that kextstat command. So apparently the FTDI is setup correctly?

EDIT: Wait that was during its fresh restart, functioning phase. Now I have unplugged the monome and replugged it in and tried it and it is showing the apple drive, but then another line of text showing the FTDIUSBSerialDriver (2.3). But I just checked the extensions folder again and there are no files that begin with FTDI… so I’m not sure where it is finding that file…

Sounds like you have another driver installed in either /Library/Extensions or /System/Library/Extensions - the file name might not start with FTDI. Does mdfind -name FTDIUSBSerialDriver return eanything?

Do you have any other USB serial devices connected like one of these? https://www.tripplite.com/keyspan-high-speed-usb-to-serial-adapter~USA19HS/

hmm… not that I know of…

I’ve been talking about my mac pro, but also have a different mac, my laptop (running OSX 10.11.5), that has the same issue where I have to restart if the monome gets unplugged. Not to confuse things by talking about two computers at once, but I just checked and the laptop and it has the issue you mentioned where I run that kext line but on that computer it ONLY shows the FTDIUSBSerialDriver file and it doesnt show that AppleUSBFTDI file. Whats more is that the FTDIUSBSerialDriver.kext file shows up in the Extensions folder as expected (and the AppleUSBFTDI file is in there also).
I renamed the file to FTDIUSBSerialDriver.disabled.kext and restarted, but the issue persisted and the same message read when I did your kext terminal command (Terminal not displaying the Apple file in there).

This laptop issue sounds like it might be easier to troubleshoot (sounds closer to what you were describing in your original solution) and honestly its the main computer I would use with the monome. I was thinking they both had the same issue which is why I mentioned my desktop mac originally (although it would be cool if they both worked of course ha)

You’ll almost certainly have to rename the file such that it doesn’t end in .kext (that is what the kernel is looking for). Try renaming it FTDIUSBSerialDriver.kext-disabled instead, then it should get skipped.

I actually named it to “.disabled” but the OSX seemed to have added the .kext suffix again on its own so I figured you just had to have that suffix. I can try again…

EDIT: Yep, just tried it again. I can change the file type suffix and have to enter my administrator password, but then it just adds the .kext again on its own. This is OSX 10.11.5

…that behavior is a preference which can be turned off (don’t remember where) - I’m surprised that Finder didn’t pop up a dialog box asking you if you wanted to use .disabled or keep the existing extension. I’d recommend just using the Terminal in this case to bypass that behavior. Try this in the Terminal:

  • cd /System/Library/Extensions
  • sudo mv -v FTDIUSBSerial* FTDIUSBSerial.kext-disabled (and type your password)

…then reboot. Given what you’ve said I think both the laptop and the mac pro have the same third party FTDI driver installed so this should be done on both machines.

Okay I will try that but wanted to ask a little bit about it first because it says I could delete important system files and I just want to make sure I know what I am doing.
What does command line do? I know the first one just gets the terminal in the correct path, and I think the second one is renaming any file with the word “FTDIUSBSerial” to “FTDIUSBSerial.kext-disabled”?
And if this is true do I need to name the file back to “FTDIUSBSerial.kext” first? Because currently it is “FTDIUSBSerial.disabled.kext2.kext” from all my experiements in renaming it.

Thats for the laptop, but for the desktop computer I dont even had any files that start with “FTDI” in the extension folder and the only file with that acronym in it is the Apple file; the FTDIUSBSerial.kext does not exist on this computer. If the command is to force-rename the file, would it still work if that file doesnt exist?

Sorry for the extra questions, I just want to make sure I know what I am doing and do it correctly so I dont mess anything up!

you won’t mess anything up here-- you can always simply reinstall the driver with the ftdi installer-- but it’s the ftdi driver causing the problem.

it’s more of an issue to accidentally delete drivers that ship with the os x install.

The first command is cd which “changes directory” to put you in the right place.

The second command is mv which “moves (or renames)” files. The “sudo” part on the front tells the OS to increase your permissions level before running the mv command (likely needed because of the permissions on the file in question). The first argument to the mv command ends with the ‘*’ symbol to have it match any file name which starts with that name (I was trying to account for whatever might be left over from previous rename attempts).

Just reintalled the FTDI VCP Driver 2.3 for OSX and rebooted my desktop computer. The problem still persists; once unplugged the device doesnt show up in activity monitor when replugged in.

EDIT: Also tried installing this on my laptop and no change there either. The funky “FTDIUSBSerial.kext-disabled.kext” file is still in that folder and a new one wasnt created (in case that was supposed to change during the install)

I followed tehns advice on the reinstall, and after that didnt solve it I tried your terminal command on the laptop which did successfully rename that FTDIUSBSerial file to end with “disabled” (and now it is actually interpretted as an empty folder). However the issue of not being able replug-in the monome still persists…

any more ideas?

did you reboot after renaming the file? if not the driver is still loaded and likely causing issue.

just to eliminate another potential issue, is it possible to upgrade 10.12, which is proven (sortof) to work?

yeah I reboot after each new attempt