#1

I’m very interested in the norns, but I find the price of the monome grid to be kind of untenable given that it’s a “dumb” panel. I already have a Push 2 and a launchpad - is there any way to use these instead?

2 Likes
#2

Sorry if this question comes across as rude:
Have you searched any norns threads about this?

The simple answer is yes but i imagine features of certain apps designed for a 128 (w/ 16 level led brightness) might not be exactly the same.

If you write your own scripts in lua you can use any usb controller you want…

3 Likes
#3

I think its a good question…
the topic of ‘does norns work well with other controllers?’ is often asked, and is often glossed over a bit.

I’ll try to summarise:
(perhaps others can add details/correct me if ive missed something)

  • norns supports external midi input/output, but requires that the ‘patch’ implements its use.
    (there is no generic implementation that is present on all patches)
  • many patches do support note on/off, and some support midi clock, some might support a few CCs…
  • there is no support for the menus or any of the ‘norns’ functionality to be operated via midi (e.g. start/stop tape)

beyond that it comes down to the owner either writing their own patches or modifying existing ones (*), this is easy for some patches, and not so easy for more complex ones - and the ability to do this, of course depends on the users programming experience - fortunately its all LUA which is pretty straightforward, and Brian has been releasing some nice tutorials (aka studies)

(*) or other community members doing this, and sharing

so whats this mean for launchpad and push2

launchpad,
its class compliant so the notes will work for some patches, and you’ll be able to use its standard layouts for note input, but you wont have any support for things usually exposed on the outer buttons.
(launchpad pro is a bit different, as its a bit more versatile)

it will also not act as monome grid, so things like MLR you would have to do a reasonable amount of code to change, but its possible (and not that difficult) , and you could emulating a 8x16 grid by flipping between two pages. (bit more work)

(Im not sure if anyone has done this yet)

push 2,
from Lua, you would be in a similar situation as the launchpad, but a bit worst off as there are not ‘layout’ modes, and you’d miss a whole bunch of other functionality like the screen (which cannot be accessed via lua).

thats why i did this:

this is a fork of the norns software, emulates the norn hardware, grid and midi controller
it does this at a low level, so that the patches do not need to be altered,

It also supports a native mode, so you can create/modify patches that are make use of the Push 2 features that dont appear on norns e.g. the bigger colour screen, and lots of dedicated buttons
Ive been working on a version of MLR using this which you can see here

IMG_2362
IMG_2362.JPG3264×2448 1.57 MB

my fork should work on a standard norns, but :

  • Ive not tested, as I don’t have a norns - I run it all on a rPI3b
  • Ive not released a binary build, so you have to build yourself (not difficult the norns is setup to do the afaik)
  • If you installed my version, then you if you ran an ‘norns update’, you’d have to rebuild/install my fork again, as it would be overwritten.
  • I do keep my fork in line with the current norns build, in fact usually ahead of the release, but as its a personal effort - Its down to when/if i have time etc :slight_smile:
  • you could revert at any time to the standard norns build, by running the last update, which would overwrite my version.
11 Likes
#4

That is WILD and awesome. I’m a musician and not a coder - is there any way I can try this out with my Push 2?

#5

on a rPI or norns?

getting norns running on a rPI its a little tricky, but there is lots of good info in the norns on raspberry pi thread

its a pity, as really there is not too much too it, but it is probably quite daunting if your not a Linux person.
It could probably be packaged into something musicians could use - but that’s not a task Ive time for :frowning:

once you have that working on the rPI, or if you’ve got the norns hardware (and so preinstalled image), then switching to my fork is pretty straightforward.

just do the following (you’ll need the network working)

install a required library

apt-get install libusb-1.0-0-dev

move the monome version of norns out the way

mv ~/norns ~/norns.monome

download my fork of norns

git clone -b push2  https://github.com/thetechnobear/norns

build it

cd norns
./waf configure
./waf
cd sc
./install.sh

this is basically the same as the normal build instructions, just pointing to my repo.

once built, reboot and it should work :wink:

2 Likes
Norns on Raspberry Pi
#6

As others have pointed out, there’s other discussion around this, and perhaps I’m restating @TheTechnobear . But it’s worth stating clearly, perhaps in case anyone else finds this thread when they’re searching: monome grids are not MIDI devices. They communicate using a serial protocol known as serialosc. (It’s OSC-over-serial, basically.)

What this means is that any norns/dust script for a grid won’t just work with a midi controller without significant code changes. At the same time, those significant code changes would not be impossible; it’s just replacing all the grid-specific code with MIDI device code that would work for your MIDI device in question - for instance, replacing all the “light button X/Y on the grid” code with code to send the appropriate MIDI notes to light a button. Not trivial, but not impossible.

2 Likes
#7

actually its a touch more than that :wink:

the api used is indeed (something like) led(x,y, brightness) BUT you will get dreadful performance if you just send out mid based off that call.

the way the grid api works it it uses a buffer state principle,
so led() just sets the state, then its the refresh() call that figures out what has changed, and then sends the appropriate messages to turn on the leds. and all the patches Ive seen depend on this.

so you need to do the same, you need to buffer state and keep track of what has to be sent for midi grids too, and in fact I found with the Push, I needed to do a bit more optimisation on top of this to keep the performance/cpu load where I wanted it.

(the good news is, this is why implementing a virtual grid i.e. 2 pages of 8x8 is so easy, because you just have your rendering loop render the current page :slight_smile: )

but I believe you may have another issue, a bit more serious - dev_midi_send (so whenever you send midi out) is done in the main lua thread, thus sending out a load of midi data is going to affect performance - not usually a problem for sequencers etc - but for keep the leds up to date, that involves sending out a lot more midi.

I say “believe” this is an issue as this is what the norns code does,
but Ive not seen this in action with a grid, as for the Push2, I re-wrote the push2 midi handling to handle the issues I found with the base norns midi code, so in my implementation its multi-threaded.

this is what I meant by this is an area that warrants discussion, as i said i think these kind of details keep being glossed over… probably because so many are using monome grids, so have not seen this?!

2 Likes
#8

yeah, sorry - I didn’t go into too much detail, but obviously, the buffer/refresh pattern is something I was leaving up to the user to implement. (ie: send the bare minimum of data at any point.)

1 Like
#9

Turns out that, though I have a Pi, the programming side of this is way over my head so I guess I need and Norns and Grid if I want to be a part of the club. :rofl:

#10

So this is super interesting to me, the only real thing holding me back from getting a norns is that I’ve never connected with the monome grid, they’re just not opinionated enough about the interface for me and the Push 2 is brilliant but I hate being tethered to a computer (well… a big computer in any case :wink:). Leaving the OSC ecosystem for MIDI is a real a bummer, moreso knowing that there are technical hurdles involved in getting smooth performance.

That said, the possibility of having a norns as a platform for developing custom controller schemes on the Push 2 is something I can’t get my mind off. Having a crow to connect to the modular synth makes this this even more exciting. I’m a software developer and I’ve written a fair amount of low-level stuff in C and Assembly so I’m not scared off by that. @TheTechnobear I see you’ve kept your fork updated, is this still something your working on? Any hard blockers you’ve discovered?

This is totally naive, but I wonder if a MIDI->OSC “emulator” buffer middleware could be created…

#11

point of clarification:
serialosc isn’t the serial protocol, it’s an OSC server for routing monome serial commands to different desktop applications via OSC.

norns by default doesn’t use serialosc and doesn’t use OSC for talking to grids; it speaks the serial protocol directly (via libmonome.)

norns midi system will get a big refresher “soon” (when there is time,) possibly becoming a jackmidi client

(i’ve acquired a broader range of midi devices to test with, including some that expose multiple ports, but i’ve also been living out of a suitcase for a few months and will continue to do so til august or so. have had / will have neither time nor space to do anything but high-level planning.)

i could be missing something, but at first glance the push2 code doesn’t seem to conflict with anything or depend on other changes (ed: super-substantial changes, that is), so could be merged upstream? (well, i would make some small refactors… e.g. we want device layer to be agnostic of scripting language - there are forth and lisp variants in the works - so implementing the lua API directly in the device driver is not ideal)

6 Likes
#12

yeah, I’m totally with you… the Push2 is a fantastic controller in its own right, if it weren’t for the price, I think it could be a very popular ‘hackers’ controller.
(the push1 is also great, but again the used prices are still a bit high if you don’t use it for Ableton as well)

so yeah, for a while Ive been exploring using Push2 with various SPCs… but it got a bit more ‘serious’ when I added support for Orac, later when Norns was released it seemed like a natural fit too, and I had most of the code to hand… so was relatively simple :slight_smile:
(Ive also got planned a Push2 interface for Bela Salt and possibly Nebulae on the eurorack side which Im quite excited about)

as for Norns particularly, honestly Im not using it much, not quite sure why. I guess I’ve not really ‘gelled’ with it, and have alternatives that do the same/similar - however, Norns is evolving, so I ‘track it’, as it’s not much effort - and perhaps its evolution will make it become more relevant to me.

as far as I know, there are no issues with it, every norns script Ive used with it works fine.
I’ve still got some ideas on where to develop it further, some of those include refactoring it to make supporting other grids (like launchpad) easier, and also extending the native api more.

I did an MLR port (called PLR) , which used this native api to properly use all the features of the push 2 (e.g. hi res colour display, and extra dedicated buttons), but that probably needs a re-write as MLR and softcut have changed in the meantime.

I’d quite like to do that… as whilst its cool to emulate norns/monome hardware, having dedicated scripts really is ‘another level’ , its just a pity that by doing this, so few other users would be able to use it :frowning:

(tech note: the latest version is in my tb2.0 branch, the push2 branch is now ‘defunct’, I should really delete it!)

its more than just one file :wink:
but for sure, the tb2.0 branch merges without issue to the main norns code, as above, I’ve wanted it to be minimum effort… so I did the push 2 support ‘sympathetically’ to the rest of the matron code base.

lua code - the reason the I put the lua code in with the push was simply, the current model of putting it all in weaver.c was undesirable… it creates a kind of implicit dependancy, and going forward it’d be impractical to put all ‘lua support’ code in one file weaver.c, its logical to split it up by device.

the compromise would be for me to put this code in a device_push_lua.c, such that other forms could exist. (e.g. device_push_lisp.c) - easy enough change.
it’s something I’ve been considering anyway, because device_push.c is getting very large, and this is a logical split.
also as mentioned above I’d like to refactor the code a bit - so that launchpad support would be an easy addition. (all the midi grid code would be very similar for a launchpad)

not quite sure of the benefit to merge upstream, as you previously pointed out to me… few norns users will be interested in Push2 - and I’m maintaining/tracking the fork, and the fork gives me a little freedom.
that said, I can see if I add launchpad support, then perhaps that is interesting to others.

anyway, I’m happy either way, as long as its kept ‘compatible’
(I probably should add a comment header for GPL, and also to reference its origin (my repo) , in case in the future developers want to know the origin)

#13

indeed, there are changes to screen and device discovery, it’s not trivial but not a big deal either. here’s the full diff (from tb2.0 to master) in case anyone is following along:
tb2.0.diff (83.6 KB)

i don’t disagree, it’s inevitably getting a little bloated, and could use a couple kinds of refactoring to make it less so. i do think it’s good to keep handlers in weaver.h (as you’ve done.)

that would probably be better. my very simple point being that to do otherwise creates another undesirable dependency, device code on interpreter API, and makes it impossible for us to abstract device/peripheral support and interpreter stuff into separate libraries (which is being worked on now.)

i don’t need to keep banging on about this forever.

1 Like
#14

I’ve spent the last week or so installing SC on my laptop and going through the tutorials… already really impressed what this system is capable of and it’s feeling like something I’ll enjoy much more than MAX/MSP (which I’ve tried to get into but just never really got there). Got a couple different USB MIDI devices connected to scripts and was happy enough with the result to feel like moving forward (and started to understand that Crone was going to solve some development issues I’d run into along the way)

I’ve also been reviewing the available docs and source for the ableton Push to get more familiar with the technical bits of developing the ideas I’m brewing on. @TheTechnobear it looks like in your youtube video you were successful in getting some simple static graphics sent to the screen, was that using the resources in their JUCE repo? I’m still working out the cogs and gears of it so at the moment I don’t understand how I’d go about getting getting data from SC (Polls, other things?) parsed and sent over USB to the push.

… but I bought a Norns :smiley: This feels like it’ll be a real fun environment to work in!

2 Likes
#15

You mean for Norns? If so I just use Cairo for this - a simple to use open source graphics lib.
(The lower level usb protocol stuff I wrote myself)

#17

I was just wondering if there is any progress on this topic at this point.
I’m getting my norns next week and I’ve been thinking how would it be possible to get my push 2 to work with it. Unfortunately grid was out of my budget, but I’m really keen on the idea of MLR working with push (and also possibly other scripts).

#18

Funnily enough, after starting this thread years ago, I now have a Norns shield and no longer have a push but do have a launchpad!

3 Likes
#19

Do you have installed any scripts to make it work ?
I have a launchpad x and i’m getting my fates next week. Does it work out of the box through usb ? At least for midi

#20

Hi TB. Total noob disclaimer. I followed these steps on my DIY norns.

I was unable to get beyond

git clone -b push2 https://github.com/thetechnobear/norns

Fatal something or other …

Any pointers ?

#21

I renamed the branch to tb2.0

However, I’ve not been using norns for a while now,
So the code is not up to date with the current norns code base - it would need merging and then resolving of the conflicts - you’ll need to be a developer to do this.

Sorry, to bare bad tidings - as I don’t have time to do this at the moment - other projects etc.

2 Likes