Having this issue as well. Test app shows pattern on one half of the grid.
Using the 2015 128.

A snippet of what was produced in the connection test app:

[2016-02-19 19:16:02] Raw OSC: <OSCMessage '/serialosc/device'-'( "<OSCVal s m1000275>", "<OSCVal s monome i2c>", "<OSCVal i 13461>" )'> [2016-02-19 19:16:02] Raw OSC: <OSCMessage '/serialosc/device'-'( "<OSCVal s m1000275>", "<OSCVal s monome i2c>", "<OSCVal i 13461>" )'> [2016-02-19 19:16:15] Selected OSC out address 127.0.0.1 [2016-02-19 19:16:15] Selected OSC out port 13461 [2016-02-19 19:16:15] Trying to connect... [2016-02-19 19:16:15] Raw OSC: <OSCMessage '/sys/port', '<OSCVal i 12234>'> [2016-02-19 19:16:15] Raw OSC: <OSCMessage '/sys/prefix', '<OSCVal s /markeatsseq>'> [2016-02-19 19:16:15] Raw OSC: <OSCMessage '/sys/id', '<OSCVal s m1000275>'> [2016-02-19 19:16:15] Raw OSC: <OSCMessage '/sys/size'-'( "<OSCVal i 0>", "<OSCVal i 0>" )'> [2016-02-19 19:16:15] Width is 0, using default of 8 [2016-02-19 19:16:15] Height is 0, using default of 8 [2016-02-19 19:16:15] Grid size set to 8x8 [2016-02-19 19:16:15] Connected OK to monome! [2016-02-19 19:16:15] Raw OSC: <OSCMessage '/sys/host', '<OSCVal s localhost>'> [2016-02-19 19:16:15] Raw OSC: <OSCMessage '/sys/port', '<OSCVal i 12234>'> [2016-02-19 19:16:15] Raw OSC: <OSCMessage '/sys/prefix', '<OSCVal s /markeatsseq>'> [2016-02-19 19:16:15] Raw OSC: <OSCMessage '/sys/rotation', '<OSCVal i 0>'> [2016-02-19 19:16:19] Raw OSC: <OSCMessage '/markeatsseq/grid/key'-'( "<OSCVal i 0>", "<OSCVal i 3>", "<OSCVal i 1>" )'> [2016-02-19 19:16:20] Raw OSC: <OSCMessage '/markeatsseq/grid/key'-'( "<OSCVal i 0>", "<OSCVal i 3>", "<OSCVal i 0>" )'> [2016-02-19 19:16:20] Raw OSC: <OSCMessage '/markeatsseq/grid/key'-'( "<OSCVal i 9>", "<OSCVal i 5>", "<OSCVal i 1>" )'> [2016-02-19 19:16:21] Raw OSC: <OSCMessage '/markeatsseq/grid/key'-'( "<OSCVal i 9>", "<OSCVal i 5>", "<OSCVal i 0>" )'>

Think this is actually a serialosc bug (have mentioned it to tehn already). New Sequencer build has a work-around though, give it a go and see if it works for you guys.

First I must say that I love this app. It’s the first app for monomer grid that I could understand and actually predict in less than 5 minutes (I’m new to this grid thing…), however, I have a problem:
When I have a sequence running my grids buttons sometimes stop working. The leds are still updated and the midi signal is just fine. It’s just that it doesn’t respond to pushes. After a couple of seconds it gets responsive again. I haven’t yet found a pattern how to trigger this behaviour. Any tips for debugging?
I’m using 1.0 (20 beta) with a gs 64.

hmm not heard of that before. a few starter questions:

  • what version of serialosc are you using?
  • have you double checked this doesn’t happen with other monome apps?
  • is the desktop UI, or the computer in general, unresponsive when this happens?

I don’t know which version of serialOSC. All I know is that I have only installed the package from the grid getting started page. The one that also includes the sum app.
The sum app works fine. I have also played around with processing and have not experienced any problems.
The system works fine during hiccups. I use some software synths and they continue to play midi from the sequencer via an IAC driver. I’ve also sent the sequence to my Korg SQ-1 used as usb-cv and usb-midi interface.
My initial thought was that the communication line was filled with tilt-data but then I got the same problem when I try to hold the device still. (I don’t even know if the tilt is working).
I will do some more testing tonight and see if I can find a common parameter.

I was mainly wondering if you could click things in the desktop app, if the UI is responsive not just the MIDI is sending.
You can try disabling tilt in the preferences.
And I think this is the latest serialosc: https://github.com/monome/serialosc/releases/tag/v1.4
Another thing to mess around with is USB hub vs direct to computer.

That is the most recent version of serialosc. I believe the version that comes with monome_sum is v1.2. Good idea to go ahead and update.

1 Like

It’s not related to my USB hub. I get the same locks when it’s connected directly to my mac.
It’s not related to the tilt. It’s the same when tilt is off (but it’s easier to detect when tilt is on because it also stops sending tilt CC values)
The app window is as responsive as ever when the unresponsiveness occurs.

I will install seraialOSC 1.4 later and test with that. My installed version is from before june 2014…

I got the same problem with serialOSC 1.4
I also spotted this in the console:
19/04/16 18:57:48,000 kernel[0]: process Sequencer[26282] caught causing excessive wakeups. EXC_RESOURCE supressed due to audio playback
I have no idea what it means.

Ok. I have some updates on my issue. Since installing 1.4 It got worse. I have noticed that the sequencer loses the connection to the grid completely. If I have the preferences window open and leave the device alone for a couple of seconds. When I push a button it will go away (the grid controller dropdown list starts to display ā€˜None’).
I have also noticed a lot of crash reports from serialOSC 1.4 in the console. I’ll put the crash reports in a github issue

You can safely ignore the ā€˜excessive wakeups’ log, thats unrelated.

From that last bit of info I’d suspect hardware or SerialOSC problems. I’d need to double check but I think the dropdown would only change to ā€˜None’ (with no monomes listed) if SerialOSC explicitly tells Sequencer the device has been removed.

Are you still not having problems with other apps? That’s the bit that seems surprising.

I’ve rebooted my computer (and destroyed 25 days of uptime) and the problem seems to have vanished. But I don’t think it’s related to the reboot.
I’ve noticed that if I don’t select any device in the Sequencer Output preferences it still sends midi to MainStage.
If I enable my IPC midi port as output in the sequencer the problem appears again. I have at least reproduced one serialOSC crash that way. How is the midi send handled? Why does MainStage receive data when I don’t have an output enabled in the sequencer? Mark Eats Sequencer show up as an extra MIDI port in MainStage. Is it some kind of IPC compatibility issue?
I’ve also played around with sampling of the serialosc-device process and found that there are a lot of ā€˜handle_tilt’ calls, even if I have tilt disabled (it’s at least not mapped to a CC).

MIDI out is unrelated to the monome communication. Sequencer creates an output port, so probably MainStage is listening to that port – MIDI is a bit weird in that A can send to B’s input, and/or B can listen to A’s output if that makes sense. I’m not familiar with IPC at all sorry.

I did get a new midi interface for my computer and tried with an all hardware setup. Same problem so all software midi port problems ruled out. Libmonome hangs after a couple of minutes with a regular midi port too.
This is the only app I have problem with.
Do you have the source code online somewhere? In that case I can debug the crashes with Xcode (I have several years of mac/ios development experience).

I don’t have the code up and public, honestly think that might be a can of worms. If I understand correctly the crashes/hangs you’re getting are in serialosc not Sequencer though right? In which case I doubt compiling Sequencer will help much.

Here’s a thought: I make heavy use of the /grid/led/map message to refresh the grid at 60hz and I know many apps don’t do it that way, I wonder if you tested just firing some test map messages if you’d get a similar result?

Otherwise if you have crash logs or any other info, happy to help.

I think it might be in libmonome since that is what’s on top of the call stack.
My strategy is to build my own minimal app on that stack to see if I can reproduce the problem that way.
I’ve forked the libmonome repo, but could not build it because of some kind of liblo dependency that was unmet. I have liblo installed via homebrew. I have opened an issue about that on github.