Monobright 64 ideas

Grids are merely buttons and LEDs. These can do whatever you want them to, that’s the exciting part !
I’m currently trying to sell the grid 64 I recently acquired (I’m in need of money because of a stupid - but harmless - car accident), but if no one wants the grid then I’m definitely going to build one (or more) musical app(s).

1 Like

Although I really agree with you I think this is also sometimes part of a problem. While it could certainly be a very inspiring and refreshing tool for making music it could also just seem like buttons and LEDs.

I’ve never owned a monome but do have a Livid Block (similar in terms of the monobrightness aspect to your monome) and a Livid Code that I got quite a few years back thinking that I could do some things with it that fits inside of the monome sensibility. Getting a monome where I am from wasn’t really a viable option at the time. I used it quite extensively for a period but it has been collecting dust for the past couple of years.

Recently I’ve also though about what I could still do with them since I now work with a small modular system and homemade sound machines. I still don’t really know the answer but the exploration itself is for me a creative act. I would probably also suggest that you dig into the programming side of things if you are at all interested but like I said I really think that it becomes a creative process in its own right that can either become very separate from musical practice or perhaps enhance it.

For what it’s worth, I am currently exploring using either the grid device or the Livid Code with an iPad running MobMuPlat (essentially an app that can run Pure Data patches on the iPad) to see if I can create a little self contained ‘instrument/environment’ with just the iPad and the controller.

Just curious, what exactly is your setup?

1 Like

FWIW. I only use 8x8 grids (40h and 64) and mostly in mono-bright since I primarily use apps built with SuperCollider and my Grrr-sc library. Grrr-sc widgets are mono-bright only atm.


Thanks all. I’m not struggling so much with technical issues around m4l or the theoretical idea of an open grid, more looking for creative inspiration: the “what” rather than the “how” if that makes sense.

In terms of my in-the-box setup, it’s pretty standard: I work solely in Ableton, composing / controlling with Push. I’ve been working separately with hardware for a while (Digitakt, modular, Blofeld) but I’ve found I quite like keeping those two systems distinct.

In thinking about moving back to the laptop, I guess I’m hoping the grid can be a more open-ended / generative / abstract tool than Push, but I’m not sure what that would look like yet, and was after examples to spark my own ideas.

1 Like

daemon, arpshift, fourths, decisions, wolves, xor, parc… there were so many fabulous apps running on the monobright and grayscale 64. i never used them myself, having only linux installed, but i recall i loved watching the demo videos :slight_smile:


i would like that some of these fantastic apps (i really like meadowphysics/ decisions/ flin/ xor/ parc/ boiingg/ corners…) could be ported to sc/linux. all these works very well on monobright 64/128. on modular side, ww/mp/kria work with monobright also.

i use supercollider and i am very grateful for everyone’s work is this direction, especially @jah with and @Andrew_Sblendorio for Animalation- live-sampler for Grid, Arc, and SuperCollider:pray: !!!

a dream is something like sum for these. i know Grrr can work to build all these apps, i just dont have enough knowledge to implement this! something like animalation/mlr + GrrrSeq + meadowphysics/decisions + flin/boiingg + some nice fx(grainfields/cocolase) :smiley:


mlr, parc, monolase :grinning:

1 Like

I always thought that @Rodrigo’s Party Van was one of the best apps for turning the 8x8 grid into a fully functional instrument.


Whilst I’d love some Linux native options as well the majority of the max 5 patches work without issues in Max 5. I have a list of the ones I tested, will add it to the Linux docs.
Max 7 crashes when clicking on a drop-down, so is effectively useless at the moment.

One of the main reasons I wanted to make Animalation in SuperCollider was to make it portable, and hopefully maintainable for a long period of time.

Pure data seemed like a nightmare in this regard, and max seems somewhat better, but sounds like there are still many issues with keeping things running for a long period of time.

Xor x1000! (and 20 characters)

Would you mind to elaborate a little ?

As I’m interested in using PD for new apps I’m really curious about these “non-maintainable for a long period of time” issues…

For some examples see this reply and the follow up replies. It’s about Max but Pd isn’t really different in this regard. Kinda Frustrated with Apps? Anyone else?

1 Like

Really? When did Pd break backwards compatibility?

Sorry, I should’ve been more clear, I meant the maintainability part of tehn’s message, see below

Yeah, I’m sorry but the situation just isn’t the same with Pd.

It’s just that nobody ever built anything like mlrv in Pd. Perhaps it would have been a better choice than Max.

Or Supercollider. That also seems like a good choice.

One major weakness that both Pd and Supercollider share, is with GUI programming. And it’s GUI programming where Max breaks backwards compatibility. Perhaps the problem with mlrv was such heavy reliance on custom GUI.

(Zero grid experience here but…) I would be tempted to do something like a circadian rhythms clone?

Try a note map of 5ths (to compare with Push’s 4ths)?

Use it as an x/y pad? Have the position of the x/y pad change when some kind of clock comes in?

Set up a step sequencer? Have each row of the sequencer cycle through a set of notes? Have each set of notes be a different length?

Set up something like the game of life/cellular automata?

I’ve done all of these (except the last one) on a launchpad mini.

1 Like

I agree with @Andrew_Sblendorio.

For building future proofed apps nothing beats well adopted open source tools.

I consider Pd very well adopted. SuperCollider is a niche environment for people willing to invest time in learning its language and mindset.

I was into Max/MSP and Pd before moving to SuperCollider. I’m a programmer and while dataflow languages are nice for audio patching IMO such languages do not scale well for non-audio stuff (persistance, logic, UI). Refactoring in dataflow languages is a nightmare, at least for me coming from a programming background.

Recently, however, as my Ruby port of Grrr has matured I’ve considered Pd as audio backend for Ruby apps with some kind of asynchronous UI approach (there is a lot of work to get there).

As a side note: the SuperCollider language (SCLang) is basically just Ruby with a C-syntax. SCLang compiles classes and is more suited to realtime work, though.

Now, to get back to the original question “How are people using their old grids nowadays?”

A work-in-progress app I’m using is mono-bright even though the device I’m using is vari. This is due to me using Grrr. I’ve found that instead of varying led brightness I’ve had to flash leds (shut them off and then on after a short delay) to provide necessary feedback.

I think mono-bright grids are great. There is even a charm to mono-brightness. I still hook up my monome 40h to a 9 year old MacBook running Snow Leopard from time to time. If I get the time to add vari-brightness support to Grrr I will definitely keep mono-support.


Vanilla Pd GUI is terrible. I have hopes in improved Pd GUI in Purr Data.

SuperCollider is just fine, I think. What are you missing in SuperCollider’s GUI framework? Qt-based, crossplatform, rapid scripting once you get the SCLang.

1 Like