#121

I think this would be an excellent goal for when the DIY Shield goes “official”.

Ideally because at the very base DIY level - the shield is basically “an audio hat” and could potentially be used with any distro. For example, someone might want to have a PatchBoxOS install and build their own interface aspects (or not use the UI stuff at all).

1 Like
#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: https://github.com/ngwese/norns-image-1/blob/feature/rpi4/board/norns/cmdline-rpi4.txt

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

State of the art SMD/DIY best practices
#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