Monome-grid node js library: overhauled and updated

[infovore]

@phortran and I have taken a reasonable fast pass at overhauling the monome-grid node.js library. (This is exactly the sort of thing I do during the hoildays).

Obvious changes: it works again. (It was not working for me when I first downloaded it). We’ve updated the syntax and style to use ‘modern’ Javascript (eg ES2016), in particular initialising the grid with a Promise, and everything works out of the box with Node 8.9.x.

To go along with that, I’ve rewritten the node.js grid studies to reflect the syntax changes - the text documentation and all sample files are now updated to work with the new library. I can confirm it’s definitely very pleasant and quick to work with.

Finally, as an example, here’s what simple code to receive keypresses and toggle the associated LED on and off with each press looks like:

const monomeGrid = require('monome-grid');

async function run() {
  let grid = await monomeGrid(); // optionally pass in grid identifier

  // initialize 2-dimensional led array
  let led = [];
  for (let y=0;y<8;y++) {
    led[y] = [];
    for (let x=0;x<16;x++)
      led[y][x] = 0;
  }

  let dirty = true;

  // refresh leds with a pattern
  let refresh = function() {
    if(dirty) {
      grid.refresh(led);
      dirty = false;
    }
  }

  // call refresh() function 60 times per second
  setInterval(refresh, 1000 / 60);

  // set up key handler
  grid.key((x, y, s) => {
    if(s == 1) led[y][x] ^= 15;
    dirty = true;
  });
}

run();

[atomboyd]

This is super interesting. I’m using node at work, and am relatively new to monome over the past year. I’ve been eyeing that node.js library and I think I may check out your updates since you’ve brought it back into view.

I have an older 64 (40h) and a walnut 128, hopefully I can still take advantage.

Thanks for your holiday work and I hope you have a great rest of the year.

ps dinchakdood?

[infovore]

Yeah, you should be able to - I’ve only tested it with latest 128, but it’s all just serialosc under the hood anyhow.

The real work for me in some ways was less patching the library - which @phortran did most of - and more updating and checking the grid-studies tutorial. grid-studies is a really good way to walk through a few basics of how we talk to grids, and get into coding a sequencer, whilst also learning the, like, five features of the library. You’ll end up with a nicely capable midi step sequencer by the end - and the extra-credit features are not hard to add at all, and worth trying.

I also find the idea of writing javascript much more soothing than battling Max, and idiom that’s never felt fully native to me.

Also: if you run into problems with the studies or library, flag them up - always good to have more eyes on it.

[phortran]

@atomboyd i just facebook-stalked you, i guess you were a bbser in phoenix back in the day? we have a few friends in common from that era. small world i guess!

[unity2k]

Hmmmm another Monome user in Phoenix? I’m out not far from Desert Ridge area!

[phortran]

right on! always nice to meet a fellow phoenician. there’s not a lot of us out here i think. i’m down in queen creek.

[atomboyd]

Hahah, I’m actually in SF these days. But I still hang out with Kris Gale (beefalo) who used to be on Phantom’s Universe back when.

Playing catch up with code and all things that make sounds electronically.

SO MUCH TO COVER.

Breathe.

[Andrew_Sblendorio]

Gonna ask about the most basic question I can here: what’s the reason for using node.js?

I guess my imagination is somewhat limited to programming languages with their own sound servers like max or supercollider. Is the idea generally that you would create a midi device to send midi info to a sound program that takes midi in? After scrolling through the grid study that was the only thing I could come up with. Any other applied ideas? Is an advantage to skip using something like max or pure data without having to use something like SuperCollider/sclang? Any other big advantages?

[jasonw22]

Yes, MIDI is the most likely output.

Some people really like writing modern JavaScript, and node.js is a great choice for event driven programming, which is a good description of the type of thing you are likely to want to do if you working with MIDI.

Also, this is a thing that exists:
https://crucialfelix.github.io/supercolliderjs/

Or if you like to do things in browsers
https://tonejs.github.io

[infovore]

Gonna ask about the most basic question I can here: what’s the reason for using node.js?

Well, same reason as the Python library (to use another example of something that exists already) - because it’s there. A lot of people know a little Javascript. And also because it’s actually a nice fit for doing realtime programming: it handles asynchronicity well, thanks to first-class functions and promises and the like.

I guess my imagination is somewhat limited to programming languages with their own sound servers like max or supercollider. Is the idea generally that you would create a midi device to send midi info to a sound program that takes midi in? After scrolling through the grid study that was the only thing I could come up with. Any other applied ideas? Is an advantage to skip using something like max or pure data without having to use something like SuperCollider/sclang? Any other big advantages?

So to pull focus a little wider: sure, you can make an application that emits MIDI. Or OSC, if that’s your bag. Or talks UDP over a network, or spits websockets at a browser. I’m not strictly imagining musical applications here.

I think it’s likely that your node app is not the only part of the chain. But you could also do things that go beyond that, given a grid is just some buttons and LEDs; you could make a 128-key clipboard for your text editors; something that visualises data sent to it from the computer; honestly, whatever you’d like.

(I also think node not being the only part of the chain is a good thing: rather than having to generate audio in whatever platform I’m working within, forcing myself not to means all of a sudden I can spit data from my note-generating app into, I don’t know, an Ableton Live Instrument Rack that I really like, and which is a great environment for designing sound in for me).

From my perspective, the advantage is that my brain does not work like Max or pd. At all; I find them unintuitive and hard to think in. This is not an absolute - it’s entirely subjective - but it’s also true. Programming languages are tools for humans, and we cleave to ones that allow us to express ourselves, that enable us to think. Sometimes, a language maps to our mental model; sometimes, our model has been shaped by langauges; that’s what I mean by ‘enable us to think’. So, personally, in order to express myself: I’d like functions and variables, ideally that I can pass around; control structures; a text-based language; classes, sometimes; a language I can write mainly in vim and a terminal; a fast REPL loop; tests, if you’ve got 'em.

And whilst I’m not a huge javascript fan, it’s really well suited to this, especially with the rich node library environment that makes integrating with other systems more straightforward.

So: a combination of “because it’s there”, “because we can”, but really the key one for me is “because (subjective) expressiveness”.

[Andrew_Sblendorio]

Thanks for you’re thorough response! I have a better understanding now.

Also, this is a thing that exists:

https://crucialfelix.github.io/supercolliderjs/

I didn’t know about that either! Interesting. I’m not sure what the advantages would be of using that library, since SuperCollider has its own language…maybe to combine with some features of other node.js libraries?

[jasonw22]

Yeah, or just because you are a person who likes JavaScript.

[shreeswifty]

I have not gotten supercollidejs to work yet though i have tonejs working fine of course
This is super interesting

[damon]

Is there a way to cancel a grid connection? That is clear everything out so the port is not bound anymore so I can try to run() again after recovering from a problem.

[infovore]

I… thiiink so? I’ll be honest and say I’ve not used this library for ages, and there have been rumours it’s not the most suitable thing for working with grids.

@neauoire has a nice grid-as-linnstrument-layout script (see here for code) that talks directly to serialosc, and you can see how he binds grid on connection. It should be doable to unlink grid on disconnect, and then you could rebind just by pulling/reconnecting the cable?

A thought. I’d have to start trying to code it myself if I wanted to do it with this library, though.

[damon]

Thanks for the link to that script. A quick glance through the code suggests that it looks to be pretty easy to cut out the middle man (i.e. monome-grid module). I’ll give it a try.

[Nordseele]

Hi,
I am trying one of the scripts proposed on the “grid-studies” page on a Raspberry Pi Zero. (The example shown in the first post of this thread actually).

I usually use a 12.x version of node.js for armv6

I noticed a very important lag/latency between a keypress and the LED refresh. Half a second or so…

But after something like a hundred keypress, or after a few tens of seconds I don’t know, the behavior of the app becomes normal, without any latency.
console.log(x, y, s) prints the id of a key in the terminal without delay but the problem seems to be with the LED redraw/refresh. Reducing the frame rate didn’t help.

Unable to find the cause, I downgraded to the version 8.9 of node.js, and this time no latency issue, the script behaves normally.

Any idea what may cause this partial incompatibility or bug between monome-grid and the latest version of node.js?

I also tried with a modified version of “Linn” mentioned above, that is with node-serialosc only on node.js 12.x and this one was working without noticeable latency.

Thanks.

Edit:
It seems the 12.x versions of node.js for armv6 are no longer officially supported so this might be the cause too…