#25

Hi @artfwo

am making progress - have got a virtual grid talking to two physical grids and almost running the hello app.

The guts of the connection is done in the SpanningSerialOsc class like this:

def on_device_added(self, id, type, port):
        if id == "m40h-001":
            asyncio.async(self.connect_physical_grid(1, port))
        if id == "m40h-002":
            asyncio.async(self.connect_physical_grid(2, port))

async def connect_physical_grid(self, grid_reference, grid_port):
        transport, physical_grid = await self.loop.create_datagram_endpoint(monome.Grid, local_addr=('127.0.0.1', 0), remote_addr=('127.0.0.1', grid_port))
        if grid_reference == 1:
            self.physical_grid1 = physical_grid
            self.physical_grid1.connect()
        if grid_reference == 2:
            self.physical_grid2 = physical_grid
            self.physical_grid2.connect()
            self.grid = VirtualGridWrapper(self.physical_grid1, self.physical_grid2)
            self.autoconnect_app.attach(self.grid)

So far I can correctly address leds with led_set from 0 to 16. The VirtualGridWrapper led_set method handles the translation of position to the underlying physical grid (if x < 8, send it to grid1, else send it to grid2).

One challenge is correctly apply an offset to an incoming grid_key message, as with the code above I don’t know which grid the key press is coming from.

I’ve kludged my way around this by creating another version of monome.Grid called OffsetGrid which modifies the __on_grid_key message to apply the offset. All the other code is the same. This way the correct grid_key coordinate gets passed up to the VirtualGrid without any other wrangling at that level.

Copying the whole Grid class seems like a terrible hack right now, as all I want to do is override the __on_grid_key handler, but I don’t really know how to register that correctly. I got a bunch of errors when I tried to have a subclass with constructor which registered all the parent handler except for the __on_grid_key method, so I ended up just copying the whole grid class, which does work.

If you have any suggestions for how to make this more elegant, I’d be interested. Perhaps I should just get the code for the spanned Hello example as tidy and possible and then send it across - might be easier than discussing here…

In any case, thanks again - overall this is looking much cleaner than the previous spanning solution I had pulled together. I’m hoping that this means I can even make use of things like Pages on top of the spanned Virtual Grid, which may make my sequencer app much easier to manage.

But for now, one step at a time :slight_smile:

#26

Good job! But yeah, this is non-trivial thing to implement elegantly with the current state of things. To create OffsetGrid you could try inheriting GridWrapper (it’s there for the sole purpose of simplifying implementing custom grid handlers).

This has never been requested, but I’d certainly welcome that.

1 Like
#27

Good idea @artfwo - I’ll can see how a custom GridWrapper might be a bit nicer. Just trying to think of how to make this as maintainable as possible - always hate doing big cut and pastes of code.

BTW - I did notice one odd thing. I call grid.connect() on the physical grids after I’ve created them, but they don’t seem to pick up their width. I only noticed because in the VirtualGridWrapper I was intending to set the width by adding the two physical grid widths together. I was getting a type error because the width values were None. Maybe this is a timing thing? In any case I’ve worked around it by hard coding the dimensions. I’ll probably make a small config file so that the physical grid ids and things are not hard coded - like the original griddle config - so I can set the dimensions there.

Along the way, I noticed that in the Grid, the connect() method (on line 60) sets the state to CONNECTING, but in the GridWrapper, the connect() method checks (one line 172) to see if the underlying grid object has a state of CONNECTED. CONNECTED is not declared, so it should trigger an error - this is how I discovered the issue - but I guess in “normal” operation, that branch of the code never fires, so the undeclared state value is never checked. Not sure if that is an actual bug, but thought I’d let you know.

@FigrHed - I’d be happy to have a go at adding arc support, but I don’t have an arc handy… I’m sure there would be someone here in Melbourne that has one, but I’d be surprised if anyone who has one would want to let it out of their sight!

2 Likes
#30

Sorry I never saw that for some reason. I actually live in Melbourne and could potentially give up my arc for a period for something that would benefit the community.

1 Like
#31

How do I get rays.py to make sound? And why do the python grid studies throw this error? :

class GridStudies(monome.Monome):
AttributeError: module 'monome' has no attribute 'Monome'
#32

I think the monome.github.io page in the first post of this thread is (up to 4 years!) out of date, the monome.org grid studies page and (most of) the examples from the repo use monome.App. It looks like rays.py uses a midi-over-OSC client to send note commands to Renoise, which I haven’t used, but maybe there is some kind of debugging terminal for incoming OSC messages in Renoise?

#33

Renoise the tracking app? Have not used that in ages. Love it though. https://www.renoise.com/.

Ok… spent some time and got it working.

It was Renoise the tracking app. I opened it up, fiddled around with it, double checked the the Python script wondering why it might not be working and noticed the script uses port 8001 for osc. So I enabled osc in Renoise after loading some demo song (‘Bears’) and made sure to change the port to 8001.

The 00 instrument ‘Drum Machine’ worked with the first two colums for rays.py.

Checking out more sounds here. Works great. Hope to post about it later.

Sweet!

#34

Right, the only working synth implementation in pymonome-apps is Renoise, but it’s easy to add your own by inheriting synths.Synth.

And for some reason I can’t edit the original post to link to the new grid studies. Mods, any ideas?

UPD: thanks, @ioflow :slight_smile:

1 Like
#35

For what it’s worth, I just ordered an Arc last week with the goal of using it in Python.
I’ll start looking at what is need to get it working with pymonome once it arrives (assuming the import taxes don’t bankrupt me first).

#36

Hey, I dug out my monome from 2012, and I can’t seem to get it to play nice with the current tutorial. Does anyone have compatible modules and code?

#37

Which version of Python are you using?
As the tutorial notes, it only supports Python3.5…

Are you getting a specific error message?

#38

I’ve tried using 3.7 at first and i got this error:

So I downgraded to 3.5 to avoid that, but the software totally doesn’t interact with my monome at all.

The code and tutorials were completely different when I bought this so, I think maybe that’s the issue?

#39

Python 3.7 syntax support has landed recently on github. Do other monome apps (Max, etc.) work with your grid?

#40

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.

#41

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

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

2 Likes
#42

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.

4 Likes
Modern alternative to Griddle for merging monomes/arduinomes?
#44

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.

#45

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?

#46

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.

#47

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!