A collection of pure data objects designed for connecting to and communicating with monome devices.
Puredata (built and tested on 0.51, probably works with [or can be made compatible with] older versions — let me know if you run into compat issues)
A monome grid or arc, or similar compatible device e.g. an Arc Clone. Known incompatible devices will either be fixed or listed here.
Documentation + Download
Download instructions and getting started information can be found at github:
Refer to the built-in example and help patches, and ask here for help if you’re having issues.
[This was the original announcement post before the thread got moved to the Library category]
I just released a collection of puredata objects for easily connecting to and communicating with monome grids and arcs.
The [monome] object handles discovery and connection, and I started working on a collection of utilities and UI elements such as faders, radio buttons, multipurpose keys, and chromatic keyboard rows — only for the grid right now, but I will work on some similar arc utilities when I get around to it.
It seems like the cutting edge of grid/arc development is happening in lua/sc over on the norns, but pd on a computer is still a great choice for quickly having fun with electronic audio, and I wanted to make it easier for myself and others to involve grids and arcs in that.
Feedback very much appreciated, especially from people with experience working with grids and OSC. Please let me know either here or in gh issues if something is suboptimal or unclear.
A demo of all the grid UI elements I made so far (more details in the demo patch):
thanks for posting! i tried it out with my grid 128 and haven’t been able to get it to work, running latest purr data on osx… I can see correct keypress messages from the grid coming out of print with the debug on but nothing else seems to work. Is there something i’m missing?
I just tested the patches with purr data, and all the main functionality seems to work fine.* Which patch are you trying to use exactly, and what’s not working? The demos in the [monome] help patch sadly don’t really work live due to the grid already having been “claimed” by one of the demo [monome] objects. Try opening only examples/grid-kb.pd or examples/grid-ui-demo.pd and see if you get feedback on the grid.
btw, I just pushed an update which adds a simple synth to grid-kb to make it useful without connecting a separate MIDI synth. It’s much more fun this way!
*I did make a small compatibility change, but it’s to a utility object which wasn’t released before I posted this reply, so can’t have been causing problems for you
hmm, yeah just opening grid-kb.pd, latest pull from your repo… no joy, if I enable debugging I see keypresses fine though. just no visual feedback and no audio. other pd patches working as usual, sound, etc…
Bravo @barnaby! I’ve downloaded your most recent push (with the simple synth) and so far everything is working for me.
For what it’s worth, I’m currently testing it on Windows 10 with Pd 0.52.1.
It may be worth linking to or mentioning the serialosc dependency in the docs? The machine I’m testing on is not my usual machine, so I didn’t have serialosc installed at first.
I think I’ve found a bug in grid-kb.pd, where if I quickly press one button followed by another, the second button I press gets stuck and stays lit, and the sound continues. As soon as I press another button it clears itself up. I’ll poke around and see if I can tweak that.
@forrest Have you confirmed that everything is in your path? I added the top level folder to my path first, but I didn’t add the util subfolder and so Pd couldn’t find some of the abstractions needed to get things working. It may also be worth trying with vanilla just to see how that goes?
What OS are you on? I’ve also got one of the new grids–from the 2020 batch, which is identical to my understanding.
Looking at your debug log there, the only difference compared to what I’m seeing is the “sys prefix /control” line–on my end I see “sys prefix /monome”. Everything you’re seeing is what I see. What I don’t know is if that sys prefix is something that will differ between OS platforms?
I’m trying to dig through the patches right now to see if I can find if that differing sys prefix is causing some OSC message not to be routed properly. Haven’t found anything yet…
Good to see you managed to find the issue! I should probably make the warning about prefixes more prominent in the documentation. I really tried to make the [monome] object prefix-agnostic, but due to the poor OSC support in vanilla pd I would have to implement an OSC string padding algorithm myself. I got half way through before deciding to wait for someone to complain about the prefixes
Did you change the prefix to /control yourself, or is that how grids come configured these days? I couldn’t really find any current information about how to deal with device prefixes so I feel like I’m fumbling around in the dark a bit here.
 now that I re-read your comment, I see what you mean. Good point, I’ll mention that in the documentation.
I’ve encountered a similar bug a few times but didn’t take the time to debug it yet. Let me know if you figure out what’s causing it!
Glad you figured out what I meant! I was writing in haste and I realize now I was being kind of vague It is reasonable to expect most folks to already know about that dependency or, as in my case, remember that they need it when things aren’t working. But I figure in case someone who hasn’t done anything before with serialosc comes along, this will be helpful!
EDIT: I was wrong–these stuck keys are happening at the source. I logged the raw output of [netreceive] in the server-setup subpatch, and I can see it happening there. For some reason some keyup events are not passing through until any other button is pressed. Once any button is pressed, that lost keyup event comes through, followed by the keydown event for the button pressed. So, the problem is either between serialosc and Pd, or within serialosc itself.
Hmm, interesting. Perhaps @tehn could give us some insight into what prefix factory grids are shipped with? (also, it seems like there’s enough to discuss for pd-monome to have its own thread in the Library category — could you move these posts to a new Library thread, or should I make one myself?)
Oh that’s really weird, and sounds like a different problem to the one I’ve seen. Doesn’t sound like there’s much I can do about it, but I’ll keep an eye out. Perhaps there’s some sort of OSC message bundling going on somewhere which I can configure away.
btw, I just pushed some updates including improvements to how [monome] objects handle device connection and hotplugging, and a simple arc example.
Glad you like it! Out of interest, what fiddling was necessary? Part of my goal with this library is to optimise the “first 30 minutes of pd+grid” experience, so I want to know about any roadblocks people run into, no matter how trivial.
Have you looked at the Max Monome-Home patch? The edit mode there is very well documented (see below for potentially relevant info)
this bit might be important to the prefix situation?
Use /sys/id to prepend other sys/info messages as it is the first message received
FWIW - I can’t make this work with my neotrellis grid. Most likelt because of the prefix thing - but I don’t understand where that is in the pd code.
EDIT: I seem to get “example” as the prefix (when I look in Max it’s the same)
oscformat sys info prints this for me: From grid: list serialosc device m4676051 neo-monome 11628
neo-monome in my case is what the “device ID string” is set to and read as /sys/id
Also FWIW - you should be able to use /sys/size x y to get the grid size and not have to worry about specifying 64/128.
Update monome info process:
- Initiate update
- Send serialosc/list message
- Wait amount of time for list to arrive (100ms? hopefully end message will be added)
- List received into dict serialosc-devices, stored by device id.
- When sure full list has arrived send getkeys message to dict to get list of devices.
- Get length of list (number of devices)
- If 0 devices send "update 0" message
- If there are device send on device list and count
- Get receive-port of each stored device from dict
- Send a /sys/info request to each connected device using each devices receive port.
- Use /sys/id to prepend other sys/info messages as it is the first message received
- Use /sys/rotation to cound how many /sys/info requests have been received as it is the last message received
- When the number of connected devices is equal to the number of /sys/rotation messages received the update is done.
This is really cool, I need to test it a bit more on linux but key presses worked fine. For some reason led messages weren’t landing on my grid. Some older PD apps I have work fine with grid so it’s probably something on my end with recreating the patch, I’ll let you know if I end up sorting it out.
Followup on testing with my neotrellis gird (on MacOS).
I can get the test patch to connect and work with my grid if I do the following:
set the monome grid object to use the device serial number
change the pd-identify sub-patch to use oscformat example grid led level all
At which point things work and I get the following from list devices:
From grid: list serialosc device m4676051 neo-monome 11628
From grid: sys port 10000
From grid: sys port 10000
From grid: sys id m4676051
From grid: sys size 16 8
From grid: sys host 127.0.0.1
From grid: sys port 10000
From grid: sys prefix /example
From grid: sys size 16 8
From grid: sys rotation 0
Is there a good way to set/send just the the prefix part of that oscformat box? for the moment I added the following at the top of monome.pd
with a receive into the pd-identify oscformat
Curiously - the prefix for the same grid on linux (Raspberry Pi with most recent SerialOSC) shows up as prefix /monome. It took a bunch of poking at the patches + disconnecting/connecting the grid a bunch of times before it would consistently show up.