// pymonome // python applications made easy

robbie · 2019-09-02T21:19:13.838Z

If you’re using the latest version of pymonome, you can fix that error by changing instances of asyncio.async in the tutorials to asyncio.ensure_future.

axiom · 2019-09-06T19:04:23.122Z

omg you guys are the best.

I went and got max 8 and was able to realize that serialosc wasn’t running in the background because i needed to restart (turn off my computer? is that even possible?). after restarting max was able to pick it up

after that i just had to change asyncio.async in a few places and update the python grid tutorial download files to match what’s actually in the online documentation

7C3C60AB-848B-4113-AD17-3BE73C7F6D04.jpeg1440×2560 309 KB

artfwo · 2019-10-06T13:19:12.782Z

the master branch of pymonome now has arc support.

the api has also changed a bit to cover a few additional use-cases, so i am going to update the examples and grid studies for python shortly.

nexnex · 2020-04-07T07:42:13.396Z

Hi all!

I have two 40h laying around and am thinking of getting a norns, and doing my research beforehand.

Any ideas around combining two 64/40h into one 128? Dan told me it is not supported as such, but would be a script-level change.

JaggedNZ · 2020-04-07T07:56:57.117Z

Yes, I’ve been working on a new version of midigrid and I am currently using two 64* button launchpad mini’s as a 128. I’ve been on a bit of a development hiatus though. I would like to support dual 64 grids, but I’m not sure what the best way to attack this is, and it’s right at the bottom of the feature list TBH.

What’s your coding ability?

nexnex · 2020-06-03T20:46:42.874Z

Coding ability is moderate when it comes to this type of stuff - I decided to build a neotrellis_monome_teensy (still trying to get it to talk to serialosc on the PC), but still it would be fun to play around with the two 40h’s as well. Right now it is a bit on the backburner here as well (sorry for the late response), because I’m still waiting for the Fates PCB to arrive.

FigrHed · 2020-06-08T13:53:58.814Z

Hey @artfwo,
the pip version of pymonome library no longer works, it doesn’t have the add_handler function that the git version has. Just thought I’d let you know, keep up the great work!

artfwo · 2020-06-08T18:25:35.221Z

What version is installed by pip exactly? I’ve just checked pypi and it has version 0.10 which is identical to git master.

FigrHed · 2020-06-10T11:15:44.051Z

pip version 20.1.1

sorry, forgot to mention the problem was with the aiosc module which I believe is 1.4 but the pip version is 1.3

I might be doing something wrong…

//edit
Just double checked and its definitely 1.4… sorry to waste your time.

BJG · 2020-12-11T11:48:47.873Z

I’m trying to get the Python grid studies working with a 40h on the latest Ubuntu Studio (Groovy), with Python 3.8 and the latest versions of the study files and Pymonome.

It recognises button presses, but I can’t get the LEDs working. I’m guessing the code only works with varibright models and I’m not sure what needs changing…any thoughts…?

(I’ve seen a note about varibright translation being done via serialosc; it’s on the latest version, 141.)

chailight · 2020-12-11T13:27:33.378Z

I have a 40h - I’ve previously got pymonome code working with it - not sure if it was the studies that you’re looking at but one thing to check is that you may need to set the led level to 15 for the LEDs to come on

I’m not at home at the moment but I can check some of your code on my 40h in a few days if you’re still stuck.

BJG · 2020-12-11T13:33:18.414Z

…thanks, useful to know it can be made to work. I was using 15, but I’ll do some more experimenting…

artfwo · 2020-12-13T13:48:31.920Z

BJG:

It recognises button presses, but I can’t get the LEDs working. I’m guessing the code only works with varibright models and I’m not sure what needs changing…any thoughts…?

Both pymonome and serialosc independently support varibright → monobright translation.

Does you grid work with other apps and implementations (max/pd)? Have you tried using monobright methods in your code, i.e. led_set instead of led_level_set?

BJG · 2020-12-14T14:34:36.738Z

Thanks for the reply…I found it worked straight away with my monobright walnut 128, so I’ve switched to using that.

blipson · 2021-07-29T13:57:03.785Z

n00b here, especially Python n00b. I just got my grid, went through serialosc docs and Grid Studies. I can press buttons on my grid and control the printout and led behavior in on_grid_key in the Grid Studies. Now I want to send an osc message to a port on the localhost when I press a button, and this is where I’m in over my head. The studies don’t seem to deal with that. I did install osc4py3 for OSC communications, put its import statements into the first grid study in a way that looked logical, and do its osc_send function right after the grid study prints the key info. OSC Data Monitor shows no activity on the port, so I conclude trying to do this with educated guesses didn’t work out.

Am I on the right track by using the first grid study to send OSC? Do I need to add on a package like osc4py3, or is there already some way that serialosc can be made to send an OSC message? I don’t actually comprehend from the serialosc docs how it could be used to send a message to another port on the localhost.

blipson · 2021-07-29T15:41:44.772Z

More detail: the problem is that I don’t understand the syntax of the Python in Grid Studies. I tried to mesh the code for osc4py3 from the section called 1.3.1.2 Sending OSC Messages like this:

#! /usr/bin/env python3

import asyncio
import monome

# Import needed modules from osc4py3
from osc4py3.as_eventloop import *
from osc4py3 import oscbuildparse

# Start theosc4py3 system.
osc_startup()

# Make client channels to send packets.
osc_udp_client("127.0.0.1", 4560, "SonicPi")

# Build a message with autodetection of data types, and send it.
msg = oscbuildparse.OSCMessage("/flag1", None, ["text", 672, 8.871])

class GridStudies(monome.GridApp):
    def __init__(self):
        super().__init__()

    def on_grid_key(self, x, y, s):
        print("key:", x, y, s)
        osc_send(msg, "SonicPi")
        self.grid.led_level_set(x, y, s*15)

if __name__ == '__main__':
    loop = asyncio.get_event_loop()
    grid_studies = GridStudies()

    def serialosc_device_added(id, type, port):
        print('connecting to {} ({})'.format(id, type))
        asyncio.ensure_future(grid_studies.grid.connect('127.0.0.1', port))

    serialosc = monome.SerialOsc()
    serialosc.device_added_event.add_handler(serialosc_device_added)

    loop.run_until_complete(serialosc.connect())
    loop.run_forever()

except I now realize there should be a osc_process() somewhere (I think).

artfwo · 2021-07-29T16:13:29.928Z

you can use aiosc for sending OSC in asyncio event loops. pymonome is built on top of aiosc, so it should already be installed on your system.

to send osc using aiosc, modify your grid key handler like this:

import aiosc
...
class GridStudies(monome.GridApp):
...
    def on_grid_key(self, x, y, s):
        print("key:", x, y, s)
        asyncio.ensure_future(aiosc.send(('127.0.0.1', 4560), '/flag1', 'text', 672, 8.871))
        self.grid.led_level_set(x, y, s*15)

or create a wrapper for the Sonic Pi client as follows:

class GridStudies(monome.GridApp):
    def __init__(self, sonic_pi):
        super().__init__()
        self.sonic_pi = sonic_pi

    def on_grid_key(self, x, y, s):
        self.sonic_pi.flag1(...)

class SonicPi(aiosc.OSCProtocol):
    def flag1(self, *args):
        self.send('/flag1', *args)

if __name__ == '__main__':
    loop = asyncio.get_event_loop()

    coro = loop.create_datagram_endpoint(SonicPi, local_addr=('127.0.0.1', 0), remote_addr=('127.0.0.1', 4560))
    transport, sonic_pi = loop.run_until_complete(coro)

    grid_studies = GridStudies(sonic_pi)
    ....

blipson · 2021-07-30T03:04:43.592Z

This is fantastic, thank you so much for spoonfeeding. Looking at this part of the Python Tutorial, I see my minimal experience with object oriented programming was making the Grid Studies code almost impossible for me to follow. All I really need to do (for now) is send simple OSC messages to one port so that simply hacking if statements into on_grid_key() based on key values will provide all the control of Sonic Pi that I can currently imagine. In that case, spending the hours it would take to comprehend Python classes would hardly pay off because I’ll surely have forgotten it all by the next time I need to know it.

I’ve verified that Sonic Pi receives the OSC messages. OSCDataMonitor, on the other hand, does not, which is unfortunate because it has been such a good tool in previous applications. For interest, I’ve attached a screenshot showing the data coming through in Sonic Pi and Terminal, but nothing in OSCDataMonitor:

OSCDataMonitor1432×1208 295 KB

artfwo · 2021-07-30T05:41:01.090Z

It’s usually not possible for 2 applications to listen on the same port, so if Sonic Pi is launched first, it will occupy the port and OSC Data Monitor will not get any messages (and should fail to open the socket, i wonder why it didn’t).

If you really want to have 2 receiving apps, so you can monitor the messages - run OSC Data Monitor on a separate port and send the messages to both.

blipson · 2021-07-30T06:58:46.835Z

Yes, thanks, I just verified that OSC Data Monitor works when Sonic Pi isn’t running.