Arc2 and 128 Connectivity Issues on Windows

Hey there,

It’s nice to see the Monome community thriving on this new platform! It’s been a few years, but I’ve brushed off the dust and gotten my Arc2 and 128 out for a performance I’m doing. I was able to setup both controllers successfully on my MacPro running Yosemite, however, I’m back at my studio and want to connect the two to my ASUS Windows 10 PC.

I followed the guidelines (the serialosc installer is great cause it downloads the FTDI drivers for you!). I see serialoscd.exe running and a new process spawns when I plug in my 128 as depicted below:

However when I run the basic Monome MaxPatch as well as run my custom node.js OSC server it throws an error that sounds like serialosc isn’t running correctly…?

Have I diagnosed the issue correctly? Is anyone else having this issue?

that monome_intro patch is simply a banner. try running test_grid.maxpat

also-- i’d suggest getting the newest FTDI drivers directly from FTDI. the bundled ones are likely out of date.

That fixed it. Thanks so much! Also, good to know about the different patches. I’m not a Max user so was a bit confused, but then looked at monome in the filebrowser and saw all the different patches.

1 Like

Got my Arc today, thanks! (had to pick it up at customs because either US or Deutsche Post didn’t put the product category number on the customs form and then I had to explain to the customs guy what an Arc does :thinking::joy:). I’m having an issue where the Arc keeps loosing its connection to the m4l device (win 10, latest ftdi, live 10, serialosc 1.4.1b. Grid 256 has been working fine since August). Should I write you through mail or here?
Also is there a reason why no usb-c?

1 Like

hi @Markus,

by lose connection do you mean lose focus to serialosc? or lose USB connection?

we’ve been using USB-mini for years now and migrating to USB-C would be a big step, though we’re hoping to do that soon. also hoping that USB-C cables come down in price.

1 Like

Hi @tehn ,
I think I lose the serialosc connection. Device mananger still shows com6 connected (the arc), but while playing strum the arc suddenly vanishes and, when opening “setup” of the devices is not listed anymore (Grid still is). Replugging fixes that. (BTW it’s a 256, not a 128. Varibright, alu edge exposed). Oh and I just remembered that when I got my grid in August the official 1.4.1a showed the same symptoms, but the 1.4.1b fixed that. Maybe a similar problem?

Re USB-C I can understand that, but from a “do I have everything I need, oh no I forgot my USB cable, can I borrow yours” perspective, USB-C has advantages and also stability and reliability of the plugs is a lot better. But that’s just a constructively meant side thing. Main focus right now is getting this to work :slight_smile:

Hi @tehn,
Don’t wanna too pushy, but eager to get the ARC going :wink:. Any news on this problem? Anything I can do to help? Is there a debug log I can activate?
Best regards, Markus

I apologize, just finished assembly and shipping and shifting hard to norns 2 update.

have you tested with Max, perhaps returns.maxpat? wondering if serialosc is the problem.

do you see any pattern to the dropouts? like amount of use? does it drop if connected but not animated or touched?

Thanks for getting back to me on this!
Haven’t tested with Max, mainly because I don’t have a clue about it. Does is circumvent serialosc / uses a different way of talking to the ARC?

Yes, pattern seems to be: lots of action = drops it
I tried strum, rhythm generator, both Dharma Wheels, umicrolooper
Also tried a different USB port that uses a different USB chipset, makes no difference and as I wrote earlier, the COM connection is NOT dropping.
Serialosc-connector run on command line doesn’t report a drop of the COM6 either, only when I reconnect it. Anywhere else to look?

if you download max you can get the monome package through the max package manager. try “returns” and see if it similarly drops. just trying to narrow down the source of the issue (ie, max for live, or serialosc, or ftdi driver.)

sounds like serialosc right now. some sort of OSC bottleneck perhaps, but i have no idea why this new unit would exhibit the behavior and not the old.

ok, took me a while to figure Max out (what to load where) :-), but managed to run returns, where when I wildly start twisting arc knobs, it will drop within 5 seconds. So it’s not m4l

I took a video of Max and returns, maybe will help showing the problem. In Max it takes a little bit longer to drop, I suspect because there is less light action when just turning knobs. Link: (Google is still processing the file, so might be low res, but can be downloaded high res)

@Markus, just to make sure - are you running the 1.4.1b serialosc binary?

@artfwo Yes," a" didn’t even work with one grid, similar symptoms at that time

1 Like

Cool, I’m gonna have a look at the problem this week.

1 Like

Ok, let me know if there’s anything I can do to help

To anyone having issues with arc on Windows 10, please use the following serialosc binary as temporary solution (64-bit systems only):

Uninstall any previous versions of serialosc, before installing the above binary.

Please do not use this binary if you don’t experience any issues, as it is a preliminary fix, a proper release will follow. Thanks to @Markus for the help with testing the fix!


Thank you @artfwo! This version of serialosc seems to fix the problems I was having with my Grid 128 on Windows 10. I just ran Polygome in Max4Live with 1.4.2-pre for over an hour with the grid remaining responsive and lights working. With the previous versions (1.4.1a and b), the grid lights would always freeze after 5 to 15 minutes, requiring a power cycle to work again. Hope everyone else with issues finds this and tries it.

1 Like

Hi @artfwo - I’ve recently acquired a 2018 arc4 and am experiencing the same problem. By connecting to serial osc from TouchDesigner, I can confirm that this appears to be an issue with serialosc itself. Installing serialosc-1.4.2-pre (subjectively) seemed to improve the situation, but definitely didn’t completely solve the issue. There are still dropouts where the serialosc appears to drop communication bidirectionally.

Is serial-osc open sourced? I’d be happy to help bug hunt if so - I want to use arc as the primary interface of a new creative application I am developing (I haven’t found a more precise commercially available controller!), but am being limited by these frequent disconnects. Is there an open source implementation of a raw serial connection? That might end up being better for my needs anyways.

serialosc is free software, see

the problem with windows 10 happens because the ftdi driver buffers the output from device differently and serialosc gets less data from the port than it expects.

with the 1.4.2-pre fix above this particular problem shouldn’t happen, because serialosc loops until the input buffer is complete. are you sure you have uninstalled the previous version?