we’ll be updating to 4.14 once we get a minute to make sure everything works, then we’ll get kernels and images posted up.
In general you’re probably better off running the default raspberry kernel anyway. Since we’ve had to drop the RT patches pretty much all the changes in the norns kernel are for supporting the norns hardware, which is irrelevant if you’re running on a rpi
FWIW - I had some funky problems with compiling the ssd1322 driver with 4.14 - gcc complaining about something in the way the init was called.
I’m hoping someone smarter than me can figure that one out.
This is where I’m up to now!!
having exactly the same message, but when I run apt update after adding artfwo’s debian repository (this line: echo “deb http://norns.catfact.net/ debian/” | sudo tee /etc/apt/sources.list.d/norns.list)
Any hints on how to get past it?
I don’t even know how to get started
where did you get this from?
(as perhaps its incorrect/out of date?)
in norns-image/build-dev-image.md its says:
echo "deb http://norns.catfact.net/ stretch main" | sudo tee /etc/apt/sources.list.d/norns.list
I got that from your branch of norns but I checked its the same line on the monome branch too.
its the second step: Sources “use the debian repository as follows”.
//edit but thank you very much for sending me down the right path
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
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.
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!
its on this thread, up a bit (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.
Started from the start of this thread (and will probably finish it at some point) but haven’t got there yet!
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)
GPIO things are defined in overlays
so you would want to grab this
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
I’m confused are you proposing to use gpio pins for USB serial communication?
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, args) end end
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:
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).
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.
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.
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!