#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
#22

No pasa nada. How can I switch back to the original branch and ideally remove all of the extra Push 2 stuff I installed. Would I be better off reformatting the sd and doing a fresh install of Norns ?

#23

just reinstall latest norns firmware this will overwrite it.

1 Like
#24

Hi, is there a specific version/ build of norns that will still work with your code for the push 2? So wish this was actively supported… Thanks!

#25

my last check in was 16 May 2019, so Id say the norns release that is just prior to that.

as above, sorry, but im not really using fates/norns… so its not high on my todo list to update this to the latest norns code base.

Ive not looked, but I fear given its now over 18 months since my last update, it might be a pretty time-consuming task (not difficult, just time consuming) … and then unless I keep tracking the norns updates it’ll go ‘stale’ again… so perhaps you can see its not really that ‘appealing’ to do.

really what it needs is another dev who is actively using it to take it on… so that it can be kept up to date, then Id be more willing to bring it up to date - to give them a good ‘starting point’. (1)

I guess one rainy day, I might do it… but then again, there are many things on my to do list i say that about :wink:

(1) that said, the other issue Ive noticed is… many that want to use the Push2 for norns want to use a standard rPI, not a fates/norns … and setting up a rPI for norns is also requires a bit of linux knowledge/time… so this also puts users off doing it.

this is kind of the problem with this ‘push 2 project’ … its really still a dev project, really for end-user use it would have to be a full distro, to be install-n-go, but I dont have the bandwidth for that.

1 Like