Norns on Raspberry Pi

[TheTechnobear]

Looked at the setup.sh on the norns git and there is some commented out lines about supercollider/supernova there. A shot I the dark maybe, but do a fresh install and comment out this?

so the original release of norns didn’t use supernova, it used supercollider
then the latest release of norns switch to supernova

then to complete the story, 2.0 will be back to supercollider

to test, what you should be able to do is just run supernova / supercollider (as applicable to the release you are running) , and see if this throws any errors.

as @okyeron said, Id break it down… test jack, test supercollider, only once thats working bother with norns.

some ‘tips’

• make sure you KILL everything before you run stuff… if you start having stale scsynth/supernova servers running, its going to confuse things
• make sure you have installed the SC from the monome apt-server , not the raspbian one.
  (this is in the install instructions)

also what sound card are you using? is this definitely showing up as hw:0?
(I thought hw:0 would be the built in rPI dac?)
theres some instruction in this thread, about using aplay, to select the card, and setting this in the jackd.service which is separate from setting it for the user … id recommend you do both!

[okyeron]

(I thought hw:0 would be the built in rPI dac?)

you gotta blacklist the rPi dac

# blacklist onboard audio
# edit  raspi-blacklist.conf 
sudo nano /etc/modprobe.d/raspi-blacklist.conf
	#add
	blacklist snd_bcm2835

[noiserock]

I’ve tested with some different soundcards/read up on Linux support on the different cards and have gotten the best results with an Audient iD4.

And blacklisted the internal DAC and referenced hw:iD4, and that helped.

[noiserock]

quick, and maybe stupid question.

can anyone confirm that the current 1.xx build works with the most recent raspbian stretch image?

Edit: and is there a «simple» way to test the display after compiling Linux? Im using an sd1322 display

[okyeron]

Display test (modify the gpio assignments as needed) - probably best to test this before you try doing an overlay:

sudo modprobe fbtft_device custom name=fb_ssd1322 width=128 height=64 speed=16000000 gpios=reset:15,dc:14
con2fbmap 1 1

con2fbmap should give you the console/terminal-prompt on the display. Look up the details on that to change it around.

EDIT - use lsmod to check and see if your fb_ssd1322 module is loading or loaded.

[noiserock]

slowly making progress here. Jack is working with usb-soundcard, and the boot sequence seems to work nicely. BUT.:

No fb_ssd1322 module being loaded. It is connected the following way(no buttons or encoders yet as I try to do this piece by piece):

PINS
1, 5, 6, 10, 11, 12, 13, 14, 19, 20 - Connected to ground (pin 6 on the rPi 3B+)
2 - Connected to 3.3 V (pin 17)
3, 9, 15, 18 - Not connected
4 - Connected to D/C (pin 8/GPIO14, defined in the overlay)
7 - Connected to SPCLK (pin 23/GPIO11)
8 - Connected to SPIO_MISO(pin 21/GPIO9)
16 - Connected to RESET(pin 10/GPIO15, defined in overlay)
17 - Connected to CS/SPIO_CE0_N(pin 24/GPIO8)

Could my display be faulty? Using this:

https://www.digikey.no/product-detail/en/newhaven-display-intl/NHD-2.7-12864WDW3/NHD-2.7-12864WDW3-ND/7355953

Following this pinout chart:

Fun fact:
Booting the PI with an HDMI Display attached gives me the UI that is supposed to be drawing on the screen X2 on the top half of the HDMI-screen.

lsmod returns this:

[okyeron]

So… it could be the display driver module is not installed - as I don’t see fb_ssd1322 in your lsmod output.

Check a couple things.
uname -r
ls /lib/modules/$(uname -r)/kernel/drivers/staging/fbtft/

you’re looking for fb_ssd1322.ko which is the display driver.

If it’s not there - you may need to recompile the display driver module - see https://github.com/okyeron/norns-image/wiki/Compile-OLED-display-drivers-(SH1106,-SSD1322)-from-source

I ran into all sorts of problems here getting a linux-headers mismatch so the driver had compiled, but with different linux headers and thus would not work.

[noiserock]

Looks like there might be a kernel headers mismatch yes.

uname-r shows:
4.14.79-v7+

but ls /usr/src/linux-headers* shows:
/usr/src/linux-headers-4.14.98+
/usr/src/linux-headers-4.14.98-v7+

Any idea how to revert back to older headers?

Edit: I am using the latest version of Raspbian Stretch Lite( 2018-11-13)

Edit2: Did a fresh compile, and now unman -r shows: 4.14.52-v7+
I got the ssd1322 driver to install thou, but it is not showing up in lsmod.

Edit3: Maiden is running as well. Just make the Display work and everything should be good to go. Progress!

Edit4:
fb_ssd1322 16384 0
fbtft40960 1 fb_ssd1322
is showing up in lsmod(no idea why).

Still nothing on the display thou, and still have the sparkles/gui x 2 pop up on the top of the HDMI screen if I plug it in.

Edit5(this is getting ridiculous, I know): There seems to be an issue with the handling of the GPIO pins, after running dmesg I got the following errors:

[Taubaland]

Did anyone end up getting the Midi I/O working on PiSound?

I remember @TheTechnobear finding a work around but there were larger issues at the time?

[TheTechnobear]

I remember @TheTechnobear finding a work around but there were larger issues at the time?

yeah, I found the issue , produced a workaround , and issued a PR (*)

device monitor return non-usb midi devices

but zebra rejected it, because it created ‘noise’ on his laptop, and because it was not relevant to the norns hardware…
(note: the comment about ‘merging anyway’ was only added AFTER I withdrew the request - see edit)

around the same time, I pointed out issues with device detection here but similarly, one of the core developers got overly defensive - the irony being, I was willing to re-write the usb midi handling, because I’d done something very similar for Bela…

so given the two episodes in short succession, I just gave up on the idea of contributing to Norns, not worth the hassle - easier to just keep my own fork up to date, and fix any issues that I run into.
(and leave the norns developers in peace to go in whatever direction they want)

anyway, as for the fix, its relatively straight forward, it basically removes the usb check, and then handling them correctly.
it’s still in my fork, which is up to date with 2.0 - and as far i know should still work.

---

(*) even to issue that PR, Id spent about an 1 hour, rebasing my fork, dealing with merge conflicts etc, so I could re-align myself to the norns repo.

[artfwo]

around the same time, I pointed out issues with device detection here but similarly, one of the core developers got overly defensive - the irony being, I was willing to re-write the usb midi handling, because I’d done something very similar for Bela…

As I said in the linked PR, there’s no need to re-write the midi handler. We can pull the alsaseq code out of the norns git history as well. I just don’t see the necessity to do so as long as there’s (potentially) a cleaner solution using rawmidi subdevices and/or shipping an appropriate alsa.conf.

We probably can also avoid disabling USB checks by adding a correct subsystem check for SPI/GPIO midi devices?

[okyeron]

around the same time, I pointed out issues with device detection here

At the time, did you see my response on that github thread?

it seems like Alsa rawmidi reference - snd_rawmidi_info_get_subdevices_avail and also snd_rawmidi_info_set_subdevice might help solve the issue of subdevices not being detected? (I don’t know enough C to try and tackle that on my own)

[TheTechnobear]

no, as i said, I was no longer interested in contributing…

if snd_rawmidi_info_get_subdevices_avail works, it means that you are going to be putting alsa code in the device_monitor, which means in turn the ‘unified’ monitor is no longer unified (as @artfo wants) - its treating midi devices differently, and then why not use the alsa api in the first place!

as I pointed out, on an associated issue ,
it makes much more sense to get midi devices thru alsa, you don’t even need dynamic detection, as a user has to associate new devices with a virtual midi port anyway - so you could scan at that time (its a very low cost op). even if you do think its necessary, just do a rescan midi when you detect a new usb device.

anyway, its all cool, its their project, they can do as they wish…
it’s obvious I have different ideas, approach and goals, and I do not not want to create conflict nor stress for either the devs, or for myself.

Ive plenty of other projects I work on and contribute too, so gives more time for them

[okyeron]

totally understand - I was just looking for an opinion on if I was barking up the right/wrong tree with snd_rawmidi_info_get_subdevices_avail / snd_rawmidi_info_set_subdevice

if snd_rawmidi_info_get_subdevices_avail works, it means that you are going to be putting alsa code in the device_monitor, which means in turn the ‘unified’ monitor is no longer unified (as @artfo wants) - its treating midi devices differently, and then why not use the alsa api in the first place!

Just to complete my thought for anyone else playing along in the home game - I think this subdevice stuff would happen in device_midi.c (where there’s already some alsa code) rather than device_monitor.c but I could be wrong.

I really don’t understand enough about the subsystems here and will have to do some more reading.

[TheTechnobear]

I think this subdevice stuff would happen in device_midi.c (where there’s already some alsa code) rather than device_monitor.c but I could be wrong.

I don’t think so… each midi port needs to appear as a different device (aka midi_device) , and it is device_monitor.c that adds things to the dev list, notifies the additions, which in turn is how the device_midi (or grid or whatever ) gets created.

(one key use for midi ports is midi hubs, so you really do have a different device on each port - which means you’re going to want to assign each to a different virtual midi port)

---

unfortunately, Ive been all over the matron code, and in particular device_monitor, device_list, and X_device when adding the push2… and I was quite surprised how many ‘tweaks’ were required to make it work - as others will find when they want to add specific device support.

[noiserock]

In other news. I got norns 1.xx working on the pi, running awake now. seem like I have some slight issues with encoder 1 and button 2. should be fairly easy to debug.
I feel happy.

[zebra]

this one point specifically needs correction:

yeah, I found the issue , produced a workaround , and issued a PR (*)

but zebra rejected it

actually no, i made some comments bringing up concerns - i specifically did not reject or approve the PR, but wanted to dig into some issues created by the hack (one was solved - passing NULL to strdup - but then you are passing empty strings to lua which breaks assumptions) - and maybe suggest a different method to get the desired result (namely, a separate scan function.)

technobear quite abruptly closed their own PR as i was editing my comments and considering specific code feedback. thus ended their first and only code contribution to upstream norns. well, so. that is their prerogative of course.

([final edit!] for the record: of course we would like to support GPIO/SPI midi devices, even though they do not exist on norns HW and are consequently hard to test. but i continue to think that hacking the USB hotplug detection module is not the best way to do that - there is simply no reason i can see not to have a separate function that scans the [non-usb] subsytems you are interested in at startup. i don’t see why that’s such a distasteful suggestion. maybe renaming device_ modules to to usb_device_ would make their purpose clearer / the suggestion less distasteful? honestly i was baffled by the response, and evidently still am.)

i would kind of like to go on… but i’ve edited this comment far too many times now, so will stop here, except to say:

we always welcome issues and PRs to upstream norns. there might be discussion and disagreement which is the nature of the work (collaborative software development.) i’m bummed that this thread seems to be evolving into a “silo,” and that there are hard forks involved in the discussion; i welcome constructive criticism of the upstreaming process; but can’t accept the assignment of all blame to “defensiveness” in the norns dev group. (perhaps one person’s “defensive” is another’s “care and concern.”)

---

moving on from this very weird speedbump in the norns-raspi history - we are approaching a stage with the norns HW where it feels basically stable and extremely fun to play with, and would like to put more of our time (again: volunteers) towards directly supporting other hardware ports.

[Nordseele]

About Norns 2.0 (the current dev) on Raspberry Pi.
Following a fresh re-compilation of the kernel and all the steps I listed here I can’t get the display to work. The drivers for the ssd1322 are here, no issues with the linux headers etc. I can connect to Maiden , there’s no error related to Matron. I tried to run sclang manually to see what’s going on with Jack and I discovered the following errors, something similar to the errors you encountered @noiserock

I’m installing things over ssh. After installing network-manager, I suddenly lost connection with the RPI and had to reconnect with a different IP. Each time I sudo reboot the thing the IP increases by 1. I used to connect to 192.168.1.18 and now it’s 192.168.1.45 Anyway, I’m wondering if the wpa-supplicant and the network manager file has anything to do with the issues I’m encountering now, I know it seems weird but… The log of sclang says ‘too many clients’… idk

[greaterthanzero]

(re: Zynthian, which should probably have its own thread…)

if they’d switch to pisound id recommend it.

They haven’t switched, but it looks like they’ve at least ensured we have the option to adapt one of their partial kits and cobble together a case.

Using pisound with Zynthian / Test-Image

(I’m curious to try it. In the initial research stages now…)