#267

cool, Id guess that is incorrect then…
(@tehn, this is coming from https://github.com/monome/norns/blob/master/readme-setup.md)

so Ive build norns twice now :slight_smile:
a) development build (first)
on an existing ‘stretch image’ on my development ‘PI’ , I really didnt follow the instructions at all for this, just used that ‘readme-setup’ as a rough guide - and as it was a development image, I built it all from source, rather than using any norns builds.
(the goal was just to initially test and explore norns)

once I had that working , I went on too…

b) norns image
this is the one i documented, in norninstall.txt
and for this, as stated in that doc, I used norns-image/build-dev-image as the starting point
basically the goal of that was to get an build that was to get as close to the hardware build as possible
so I kept everything as close as possible, just adjusting where it was absolutely necessary.

anyway, thats why i didnt stumble over this little hurdle, but its good to spot this kind of thing.

#268

Well I’m glad I brought it up then.

Wheres that norninstall.txt? I couldn’t find it but that would be extremely helpful!
I thought I’d been using your branch (because I’m using a rPi obviously) but it just occurred to me that because I’ve been following the .mds that clearly haven’t been editted I’ve just been cloning from the monome/norns repository anyway!

#269

its on this thread, up a bit :slight_smile: (search finds it)

yeah, you only need to use my fork if your planning on using a push2 (it has no other changes iirc),
otherwise id advise you to use the official repo.

1 Like
#270

fantastic!
great work!

Started from the start of this thread (and will probably finish it at some point) but haven’t got there yet!

1 Like
#271

So I’ve finally got Crone and Matron running!
turns out Matron will run with your HDMI port if you just add the ‘we’ user to the ‘video’ group!
Took a while to work that out…
I’ve added notes from my own experience to @TheTechnobear 's install notes.
Heres a git to it:

Also please don’t look at my github account! i dont use it very often so its pretty bare (kind of embarrassing really).

I gotta thank pretty much everyone on this thread for posting about it, its all helped me get my head around linux and get my raspberry pi running as a sound machine!!! Even some of you who just asked questions about problems you were having helped send me on the right path.

Some problems I’m still having:

  • Matron running comically slow on my Raspberry pi 2 B, but I haven’t had any sound problems… apart from a few Xruns but I haven’t even started looking at how to optimise linux for audio yet.
  • Maiden isn’t working but I think thats because Apache is failing during boot.
  • Jackd seems unstable and refuses to open half the time so crone won’t run.
  • I was hoping to use my arc as replacement for the encoders but I read somewhere earlier in this thread that that won’t work because the GPIO and OSC messages can’t really be interchanged… but if Technobear got his Push encoders to replace them it must be possible… anyone have any tips on that?
    Looking at GPIO.c at the moment but it just looks like chinese to me… except I can speak Chinese (and c)
#272

GPIO things are defined in overlays

so you would want to grab this

https://github.com/monome/linux/blob/norns-20171029-1/arch/arm/boot/dts/overlays/norns-buttons-encoders-overlay.dts

and then modify for your GPIO needs and then compile this to .dtbo

dtc -W no-unit_address_vs_reg -@ -I dts -O dtb -o norns-buttons-encoders.dtbo norns-buttons-encoders-overlay.dts

Then you put that file in /boot/overlays and add an entry to /boot/config.txt

# Buttons and encoders
dtoverlay=norns-buttons-encoders
2 Likes
#273

I’m confused are you proposing to use gpio pins for USB serial communication?

#274

In another thread it was mentioned that Grid is talking serialOSC directly so I’d assume Arc would work the same way. But… digging around in the lua files, I don’t see arc defined anywhere.

So to get some OSC from arc you could do something like this (completely untested):

function norns.osc.event(path, args, from)
  -- osc message from arc looks like:  /enc/delta n d
  if path == '/enc/delta' then
      enc(args[0], args[1])
  end
end
1 Like
#275

@scanner_darkly was working on arc support

1 Like
#276

That would be a beautifully clean work around. Minimal editting so the scripts would still work fine if I got some encoders plugged into the GPIO pins.

Good thinking, I’ll let you know how it goes.

No, I was proposing to get the OSC messages from the arc to navigate through the menu, etc. So turning them will do whatever the the encoders on the Norns currently do and pushing them will do whatever their associated button will do (pushing arc encoder1 will act as key 1, etc) as I don’t have encoders or buttons on my pi so am stuck in Awake when I run norns.
Feeling like this at the moment:
SleepingShaq

1 Like
#277

i ran into some issues and closed the PR as i need to concentrate on getting teletype 2.3 release ready. if somebody wants to take a look the PR should be a good starting point. it does need to be updated for whatever the latest changes are around globals and grid module (which potentially can fix some of the issues i experienced).

2 Likes
#278

Oh! I totally get you now. Making that work would require some code surgery for sure. But I see why you’d want to do that.

1 Like
#279

re: getting encoders and buttons into an rpi.

it is ridiculously simple in terms of hardware. compared to hacking the matron code to map OSC/etc (this way is hard) i’d suggest getting a breadboard and some wires and following some of the most-basic rpi hardware tutorials. you don’t need to write any code. just modify the the encoders/keys dtoverlay for the correct pins.

we provide a lot of information about the hardware: https://github.com/monome/norns-image/blob/master/readme-hardware.md

if someone actually gets to this point i can explain further.

3 Likes
#280

Oh, I’ve done a lot of work with the GPIO pins in the past and I know how easy it is. I have a breadboard and a rPi breakout board. I’m just not particularly good at putting stuff in cases and making things permanent and transportable (my spatial awareness is… low, I think).
The arc is a beautifully crafted, stable and transportable piece of hardware I can gig with stress-free. Something you have unique talent for and that you’ve probably forgotten how tricky it can be when you’re getting started.
I have ordered some encoders to give it a go anyway as they’re cheap but until they arrive, and while I have time off uni (software engineering), it will be more beneficial and less stressful for to get my head around the code and see how can modify it to suit my ends.
Just a month ago I programmed an Arduino to trigger solenoids on receiving OSC messages and had to wrap my head round the OSC protocol to do that. So I have confidence I will be able to do this if I can find the time.
I’ve learnt so much already!

1 Like
#281

making norns receive osc is not really the issue
i think the ‘difficulty’ is , how do you plan to generate the encoder and button events?

afaik, this is not exposed to lua, so you are going to have to do this by forking/extending matron.

if you have the relevant skills to understand the matron C code, its not too hard, but likely to be fiddly (if my experience with push2 is to go by) … the event generation is ‘easy’ , the main bit is wiring it (possibly via oracle?)

as for Arc, would have thought the arc support would eventually be added ‘natively’ rather than going via an OSC bridge, Id have thought that approach would be pretty simple.
(wether encoder events are the right thing to be throwing to lua from an Arc is another matter :wink: (given the current acceleration code etc)

1 Like
#282

I know, I was just yanking my own chain, ha ha!

This is good food for thought and thanks for sharing but I’m not sure what you meant by

do you mean getting it linked permanantly?
and

Is this referring to the varying speeds of OSC sending/receiving?

//edit actually I realize what you mean by acceleration code, the code that handles the accel value from the encoder

P.S. how did you go about getting the Push2 encoders to act as the native encoders? or is this a clever illusion?

#283

Is norns running serialosc under the hood somewhere?

I don’t see a serialosc/serialoscd process running but i remember my friend’s grid just showing up without any fiddling around.

Would I want to install serialosc separately? Would this screw anything up with norns?

1 Like
#284

I believe I read in one of these threads that it’s just communicating with grids directly through the USB port (raw serial, no OSC). Naturally, I can’t actually find that to link to now.

I haven’t tried to set up the pi-norns yet. raspberry porns?
(I was waiting on a software update to support newer B+ boards, which may well have happened already.)

This mostly means that I can’t confirm for you that my grid “just works” in this setup. But it does just work on the official hardware, so that’s something.

Anyway… I don’t imagine it would screw anything up. It’d just sit in memory, ignored.

#285

In reading the development thread today I think i understand a bit better - I believe grid is detected by libmonome - which might be happening inside the matron process (?)

Mostly what I’m looking for is some kind of “a device has been added” output when plugging something in (like a grid, or whatever).

FWIW - i have things running on a pi3b+, but i had to jump thru a bunch of hoops recompiling to get a version that works.

1 Like
#286

hey @TheTechnobear i have a push two and i’d love to try the NornRpiP2 solution if your willing to share it