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.

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.

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 :wink: )

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.

  1. 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.

  1. 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.

3 Likes

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.

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

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.

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!

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

Might be helpful to join there with questions/solutions.

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

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

3 Likes

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.

1 Like

I think wheel is a group of users who have access to super user. Something left over from Unix. If you ls -l in /Library/Extensions you see the files already have wheel associated with them.

I think getting rid of the devices from the system preferences / network is of more importance to getting serialosc going well. That and disabling the Apple driver.

I went through the steps, but my 40h still doesn’t show up in any max patch. I also removed it from the network devices. It’s visible in About this Mac > System Report > Hardware > USB > … I even tried it directly in a USB port on the machine, instead of through a hub … nothing.

i’m on a macbook pro early 2011 (i7), 10.13.6, latest sc and serialosc.
i have no problem with it if i start SC with the grid already attached.
so no hotswap but the rest is working properly

EDIT: no, i can unplug it and plug it back IF it was plugged the first time SC is run. then i can remove it and plug it back with no problem.

@artfwo recently did some fixes to get 10.13 working well, but then apple hit 10.13.6 and it seems they changed something minor again

i’ll get mine upgraded to 10.13.6 and see what happens. thanks everyone for the suggestions here.

3 Likes

Cheers Tehn… I switched back to MonomeSerial again, but it’s fussy and doesn’t like the device being unplugged.

Actually I really like the functionality of MonomeSerial and would be super-interested if it were possible to assign every button with a MIDI note or CC event with specific value. I can’t imagine needing anything else for basic switching purposes.

Connection with monome and SerialOSC is very inconsistent. I’ve read a number of threads about FTDI drivers and tried various combinations, but it still the same. Sometimes monome shows up in serialOSC, sometimes it doesn’t until I restart CPU. If I unplug and re-plug monome, sometimes it flashes LEDs, but often it doesn’t.

Is there a set of steps to trouble shoot? Running this on a mid-2012 macbook pro, OSX 10.13.6

Part of the issue seems to be that the USB connection to the monome itself is touchy. Is there any type of cleaning that might be helpful?

that’s actually probably the main problem unfortunately. not likely something that can be cleaned, but the USB port should probably be replaced because the contacts are bad (ie, the plastic housing internally is broken). e-mail info@monome.org if you want to send it in

or, have you tried another usb cable?

So far mine works as expected in 10.13.6, but I’ve really only opened a Max patch or two, so I’ve hardly stress-tested it. (edit – my mistake, I thought sum was M4L, but that’s terms or something)

When I have time I’ll try to give some of the M4L stuff a whirl and see if that is also working for me.