MacOS 10.13 (High Sierra) and serialosc

[zebra]

as workaround / sanity test you could try connecting SC directly to the serial port

catfact/catfact_sc/blob/master/catfact_util/CfGridRaw.sc

[capogreco]

cool - thanks for this. seems like it is working now for some reason

but yes. good to know that its possible to deal with comms at the serial port level.

[jemfiner]

No answers I’m afraid, only the same problem. As a matter of interest, in the MonoM.sc class what port number are you using for NetAddr.new ? Default is
NetAddr.new(“localhost”, 12002);

Are you using serialosc 1.4 and no FTDI driver ?

Trying to see I have everything configured right.

Thanks,

Jem

[capogreco]

As a matter of interest, in the MonoM.sc class what port number are you using for NetAddr.new ? Default is
NetAddr.new(“localhost”, 12002);

yup, 12002.

seroscnet = NetAddr.new("localhost", 12002);

Are you using serialosc 1.4

serialosc 1.4.1

no FTDI driver ?

mmm I don’t think so - I ran the bash code from here, so I think the FTDI driver has been removed?

[jemfiner]

Thanks, good to know. I have the same setup too. I’ll keep trying and see if I have any more luck.

[california2022]

Just signed up to say I haven’t been able to get my gs128 working - I was on 10.12 and saw that people were having luck on 10.13 so I finally upgraded after putting it off for months.

When I upgraded it went to 10.13.6, which I then saw was the version that also now does not work.

I have tried serialosc 1.4, 1.4.1 with various FTDI drivers (Apple’s included). So far the only consistent thing is that the monome only appears with ls /dev/tty.usbserial* when I boot the computer with the monome plugged in. This behavior is consistent when directly plugged in to the USB 3 port or a USB 2 hub -> USB 3 port.

My Mac is a 2015 Retina.

When I execute ls /dev/tty.usbserial* it shows that serialosc is detecting the device: /dev/tty.usbserial-m128_344.

The serial number matches that displayed in System Information:

No Max 7 apps show that there is a monome device available. The monome lights up with the start-up pattern when I plug it in.

[okyeron]

Could you check Activity Monitor app (in Applications/Utilities on your mac) and use the search i the top right for “serial” to see if the 3 serialosc processes show up?

If not, it’s possible serialosc is not running at startup. In which case you can enable this by doing launchctl load /Library/LaunchAgents/org.monome.serialosc.plist in Terminal.

FWIW - the ls /dev/tty.usbserial* is just showing that the USB system is seeing the device, not that Serialosc has seen it.

[california2022]

Hi okyeron, thanks for trying to help me figure this out.

I confirmed that serialosc-detector and serialoscd start running around 30 seconds after startup. I did not find that serialosc-devic was running, but maybe that process only launches when serialosc has connected to a device?

Not super useful, but running the command launchctl load /Library/LaunchAgents/org.monome.serialosc.plist just confirms that the service is running already with the message: /Library/LaunchAgents/org.monome.serialosc.plist: service already loaded.

If it helps, here is the kext that I have:

$ kextstat | grep FTDI
  132    0 0xffffff7f82bad000 0x3000     0x3000     com.apple.driver.AppleUSBFTDI (6.0.0) E9E38BB7-3AFB-36E7-B1AF-4AF171F8D985 <131 130 22 5 4 3 1>

This is the default apple one. Is it still the case that the default Apple kext is the correct one?

[okyeron]

IIRC - serialosc-device will come up once serialosc detects a device.

Did you try running the Monome-Home maxpat or test-gird.maxpat?

I’ve found those two to be the most useful for debugging.

[california2022]

Hi okyeron,

Thanks for linking those patches - I hadn’t heard of them. However, I get the same error with them that brought me here - that serialosc seemingly doesn’t recognize my gs128 and that as a result it does not show up in any Max patches or runtimes.

@tehn - do you have any idea as to whether it is something in serialosc that should be changed to fix this or something wrong with the FTDI driver? I am interested to fork serialosc and try if you think if it can be fixed there.

[junklight]

I made a separate thread about my issues but realise now they should have been in this thread.

I’ve got it working sometimes but here is a bit more information:

Things like Monome-home and mark eats sequencer - work consistently

I’ve now got Max 7 standalone working consistently - by deleting BEAP from inside the package

Max for Live - some devices work - I’ve got the Monome package working (flin etc), grain fields works well however grid lab doesn’t - sometimes opening a device to edit sometimes fixes it. Note that I also get the grid not being found inside the Max for Live editor too sometimes.

There is a max error when it doesn’t work - “wrong type for inlet” as far as I can see this is a port number with a #0 prefix passed to “p router” inside serialosc patch

no idea if any of that helps.

I have enough of the things I want working to be happy but wouldn’t mind having a poke at some of Strettas grid lab (even if it is not helping my desire for an arc - although that’s going to have to wait. Norns next )

[stevieraysean]

So I’ve also this i’ve had this issue when upgrading to High Sierra. 10.13.6

I was able to recover serialosc functionality follow this method from: https://superuser.com/questions/1135730/how-to-release-reset-serial-port-ftdi-devices-mac-osx

SOLUTION:

1. Download the 2.4.2 drivers from FTDI’s website http://www.ftdichip.com/Drivers/VCP.htm and install. The install will succeed, BUT due to Apples built-in FTDI drivers they will not work.

2. Reboot computer and enter recovery mode Via powering down and holding down CMD + R on reboot.

3. In recovery mode open terminal from utilities at the top of the screen and type the following to tempraily disable System Integrity Protection:

csrutil disable

The computer will prompt you to reboot to make changes take effect.

4. On reboot we now need to disable the Apple FTDI drivers (NOTE: this can be reversed at any time so do not worry). - open Terminal and type the following.

cd /System/Library/Extensions

sudo mv AppleUSBFTDI.kext AppleUSBFTDI.disabled

sudo touch /System/Library/Extensions

Now you will have successfuly have disabled Apple’s built-in FTDI drivers and replaced them with FTDI v2.4.

5. Restart your computer in recovery mode. Shutdown, hold Command + R and open terminal in the Utilities tab. Enter the following to reenable Apple’s System Integrity Protection

csrutil enable

AT LAST! One final restart and then your USB serial devices should all be loading properly!

They had some other steps which I didn’t need so I have taken them out. Follow the link above if you want to see those.

mainly:

chgrp -R wheel FTDIUSBSerialDriver.kext

which is actually in /Library/Extensions not /System/Library/Extensions, and i’m pretty certain the permissions don’t need changing. And:

sudo mv D2zzHelper.kext D2xxHelper.disabled

which I didn’t have because I don’t use the D2 drivers…

Now I am able to plug / unplug my grids and get apps working. Previously it was working only if the grid was plugged in on boot.

However it still feels broken compared with how it used to work on previous versions of OSX. It takes a reasonable amount of time (2-4 seconds) for the device to appear in max7 serialosc. If it appears at all. Around half of the time, max or the maxpatch, need to be closed and reopened.

[stevieraysean]

After getting fed up with intermittent performance I formatted my hard drive and reinstalling high sierra. Following the above steps got it working nicely. Then upon restart, intermittent issues persist.

It seems to me that serialosc-devic is quitting shortly after being launched by serialosc-detector.

The strange thing is it works fine on my newer 2012 64, the problem is with my series 256. I’ve even changed the serial-number to the new style and updated the serial protocol in the device to mext and it still seems to crash. The USB devices look identical in Apple system report. When it doesn’t crash it identifies correctly and works fine with serialosc in max/map.

[california2022]

I just got back to trying to get this to work, but it seems pretty hopeless.

[california2022]

I did have a minor success though: I wrote a python script to check if the serial was working at all. It is.

I’m not sure where in the chain of monome -> kext -> serialosc -> maxmsp that means the chain is broken though, but it seems like serialosc is not working since I’m getting serial output from the monome.

The only thing that you’ll need to do to get this script running on your own machine is to replace the /dev/tty… with whatever your device path is after plugging it in.

#!/usr/bin/env python
from datetime import datetime
import serial
import struct
ser = serial.Serial(
  port='/dev/tty.usbserial-m128_344',
  baudrate=9600,
  )
while ser.isOpen():
    datastring = ser.read(size=2)
    datastring = struct.unpack("H", datastring)[0]
    print(datastring)
ser.close()

This detects key pushes and releases. The int is offset by a few digits for each:

@tehn: do you have any bandwidth/plans to work on this or should we try to get it to work as a community? I am not familiar with your codebase and don’t know where to start.

[wader]

Hi Folks,

I have huge respect for anyone able to negotiate the technicalities required to actually setup a Monome on High Sierra (can it even be done?). I can follow instructions, but my coding skills fall far short of being able to code my way out of the problem I’m faced with (and I’m sure many others are too).

My goal: Monome 40h working as MIDI controller for articulation switching in my DAW (each button will send a configurable cc value on a fixed channel).

Nice to haves: Preferably without MAX (I only have Max for Live and don’t use Ableton Live so much anymore. Lights working for (exclusively) selected buttons.

The problem: Device is never consistently available since moving to High Sierra regardless of suggestions I follow (I think I tried everything, FTDI drivers swapped out etc, even using MonomeSerial app).

My humble request: A solution!

[california2022]

There’s a thread going on here: MacOS 10.13 (High Sierra) and serialosc

Might be helpful to join there with questions/solutions.

[wader]

Thanks for your response. I’ve been following that thread for a while. I hope there will be a nice solution at some point!

[stevieraysean]

After some more tinkering tonight, I’m pretty sure my system is completely reliable.

The only thing I’ve done further to installing the FTDI driver and disabling apples one as per my post above (post 195) is:

The chgrp -R wheel FTDI… command listed in that post. I don’t think this did anything though.

The other thing I did which I think may be the fix is delete the monome devices that showed up in device list in network preferences. When the system asks if you would like them added next time the device is plugged in select no. This was triggered by reading some FTDI docs where they mentioned that Apple asked them not to add their device into there anymore. For some reason they were still being added…perhaps being in this list causes some conflict when the device is plugged in and serialosc can’t get control of it

[california2022]

This command chgrp -R wheel FTDI shouldn’t do anything. You’re just telling the computer that the group of users called wheel now own the directory called FTDI and all of its contents. That seems like a misinterpretation of installing a python wheel or something.

I’ll have to give your method a try and update here if it works.