122

yes, of course. i have several devices running patchbox here at home that i will certainly look at using (i don’t even have a norns shield yet.)

that said… i hope the motivation for a custom, minimal “distro” and kernel is also clear: maximizing performance for the primary use case. CPU headroom for audio threads, bootup time, etc. we’re already seeing some discrepancies between what one can get away with on {factory norns/ monome kernel}, vs {pi3b+/ stock raspbian/ fates}, as you’re aware. i’d expect such differences to be exacerbated by the buildroot release.

re: pd, thanks for the backports guide. it seems simple enough to build from source and host our own .deb like we did for supercollider.

bringing in newer libcairo seems trickier maybe? just a guess, haven’t looked at dependencies.

3 Likes
123

shield can run now with the raspbian build (the new kernel works).

also the output works pretty fine with many headphones, so i will likely skip adding the separate headphone driver (as this takes it out of DIY given leadless)

so, short of me posting a working disk image, this is basically ready to go!

16 Likes
124

good news ! ! tyyy for the hard work on this - it’s a huge step up in accessibility for me

also good news given that this’ll be my first shot at surface mount. what are the concerns w/ headphones / if any ? (wasn’t following why a different driver was needed in the first place)

2 Likes
125

@simonvanderveldt How are you handling the pi4 and it’s default framebuffer being dynamically assigned?

(with a pi4 and stock buster the HDMI ports are not active unless something is plugged in, so the OLED will default to fb0, but if you plug in an HDMI device, the HDMI takes fb0 and the OLED goes to fb1. The pi3 is hardcoded to always have the HDMI on fb0 as best I can tell)

So… I discovered the settings to sort this out today while digging around on /boot/config.txt settings. Now I’ve managed to get the pi4 to reliably boot with the OLED on fb1- with or without something connected to the mini-HDMI port (either port, but I did not try both).

So edit /boot/config.txt
set hdmi_force_hotplug=1

which does this:

pretends that the HDMI hotplug signal is asserted, so it appears that a HDMI display is attached.

then changed my /boot/cmdline.txt
set fbcon=map:1 to fbcon=map:0

then changed fb0 to fb1 in /etc/systemd/system/norns-matron.service

Therefore this would be more in line with the setup on pi3.

126

I’ve been the one working on the rpi4 setup. We haven’t yet finished merging things into a single buildroot config where the system is built once and then from that generate rpi2, rpi3, and rpi4 images with the proper config setups.

I’m not 100% positive this is the latest config.txt I’ve been using on the rpi4 - but for reference: norns-image-1/board/norns/cmdline-rpi4.txt at feature/rpi4 · ngwese/norns-image-1 · GitHub

Admittedly I haven’t had the need or desire to attach an HDMI display to the rpi4 so the dynamic frame buffer switching behavior; if it even occurs in the buildroot setup, is not something that has come up.

2 Likes
127

Tbh I haven’t tested/properly checked this but I think the buildroot image has no support for HDMI so we don’t run into this issue (don’t have time nor means to check this, also don’t think it’s relevant for the initial release).

128

And the sound quality is good? The quality out of the headphones port on my raspberry Pi 3b is horrible, but maybe that’s been improved in future revisions?

Edit: or maybe you are talking about driving headphones from the codec’s lineouts?

129

It’s from the norns shield outs i presume.

1 Like
130

this is correct.

the additional driver chip simply provides extra gain (and a separate jack).

131

This is fantastic news! Are you still planning to do a run of boards with the SMD components pre-soldered?

1 Like
132

I have printed some boards based on the Eagle files on October 7…Am I safe assuming they are the same as the ones currently posted? (I see last commit date is Sept 15…so I guess there were no edits to the boards themselves…)

133

I think you and I (I put in an OSH Park order yesterday) will be the owners of rare Revision 1 boards:

but it sounds like that won’t be a huge change, and older boards could probably be updated by cutting a few traces and doing some extra soldering… @tehn will that be worth it, in your opinion?

134

like i said, the boards work. we have a bunch of them between the core devs. not sure you’ll need to add resistors.

5 Likes
135

yoooooo. someone holler when this is an easily purchaseable, buildable kit for us ludites!
need some norns yo.

6 Likes
136

doesn’t sound like monome will be offering kits directly but there’s no reason why someone here couldn’t organize something like that (or check out fates instead, for which kits are being offered albiet in limited quantities at the moment)

I’ve considered selling some builds but given my time I’ll likely just be putting out some cases

in a parallel train of thought, it would be smart to put together some detailed build instructions for the monome docs aimed at beginners, so maybe kits are less necessary - I’d be down to help out.

2 Likes
137

i’ll be producing a run of SMD-populated boards, but not likely full kits. (definitely nothing with enclosures.)

19 Likes
138

oh and opinions ?? would I be smarter to find another SMT project to start with or should I just dive in with some PCB backups if I’m excited about it (I am excited about it).

also any more tool req’s before I dive in

139

any plans on an aluminium enclosure?

140

if it happens - just laser cut birch or acrylic. I’ll try n make em nice tho. will post info here

4 Likes
141

I’m in a similar boat maybe - never really done any DIY electronics stuff, but this is the first one that’s really appealed to me, and I’m naively hoping that my enthusiasm for it (and some backup components + some research :wink: ) will carry me through this project hehe