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

Thanks for all the info, I totally understand. Had not thought of a direct to rPI set up but that would be brilliant, you can get used Pus2s for like $250usd these days. Cheers and thanks for all the work you put in!

#27

Not to derail but where are you finding Push 2 for $250?

1 Like
#28

Was on local FB marketplasce, of course when I look now they are not that cheap.