Yes! that black screen on the top half of the screen is exactly what i get (either when i have the rpi plugged to an hdmi monitor or through my waveshare 3.5’’ touchscreen).
Audio is working, it starts up on the Awake script and if i connect the grid i can play with it and change the audio output
I managed to run maiden on the bottom of the screen (since the black screen is “always in front” on the top end :p). With maiden i was able to switch the script running, tried a couple of other scripts but some ended up crashing crone and matron (note that i tried this before the norns update, haven’t yet updated). REPL was working and connected to lua and sc tried some live commands but didn’t really change anything (was probably trying the wrong commands). Script editing also seemed to be working but still haven’t really tried much, wanted to get the screen working first :slight_smile:

1 Like

if you want to get the screen working ‘properly’, i.e. full screen
then you just need to edit matron/src/hardware/screen.c and change the resolution, and also change both the formats to CAIRO_FORMAT_ARGB32
then you can use cairo_scale(cr, s, s) , where s is a scale factor, to make the text readable :slight_smile:

ok, the next issue, i saw, but didn’t solve. (because im going in a different direction at the moment)

is because norns is writing directly to the framebuffer and so is X, any X screen updates with override the norns display…
to solve this ‘properly’ you need to change screen.c over to use and X11 surface.

however, what I think you could do, if your not a programmer, what you could do as a temp measure is to just get X running, but not have a window manager, i.e so nothing disturbs the display

(ideally id say the best option for your waveshare, Ive one too … would be to update screen.c to use SDL, that means X does not need to run, so less resources)

however… and the reason I didn’t go too far this way, is your also next going to need control for that display.
to do this you either need to:
a) add encoders/buttons via
then update the gpio ,as @tehn suggested, that is trival from a coding perspective
but the issue is there is enough gpio left with pisound installed.

b) do the control aspect some other way
this is ‘easy’ enough from a hardware perspective,
e.g. use a midi controller, use an Arduino for encoders etc, then send over uart.
but it requires you to then write a new ‘matron’ driver - which lets say (having done it) has its challenges :wink:

I say this is because the menus, only respond to encoder events… and Im not sure if you can generate these from the lua layer, if you can, then you might be able to control via midi… (if not this might be an interesting small addition to matron)

the alternative to all this…
forget the current screen/current apps all together, and just write your own ‘norn’ apps in lua that rely solely on midi, using the hardware you have.
this involves a bit more ‘lua’ and there are limitations(*) , but in these early days of norns, I think could still be quite rewarding.
also, it may be that ‘limitations’ this approach has, may be reduced as norns matures.

(*)Ive not had an exhaustive look at the lua layer, so can’t really say whats possible and whats not with this approach, but finding that out, would be interesting in itself.

3 Likes

So OT

what do you think about using the push2 and it’s screen and knobs then for this particular problem?
The reason why i consider this is that i have switched to linux exclusively this year for seevral reasons and woudl love to still use the push if you think it solves the issue?
I have a Norns and i realize when i am out of my depth on something and yes my main reason for getting a Norns was to connect it with my grids and learn lua. I have zero interest in bashing my head to force some solution and wasting time.

I would be interested in your thoughts about the push2 idea

without going too OT.
generally, Ive alway thought the Push2 is a really solid piece of hardware for ‘other projects’.

its a fantastic screen, great encoders, pads, loads of buttons which can be are all lit (in various states)
at first it seems expensive, but actually I think its probably highly subsidised by Ableton, because there uses will buy Live (and then be on the ‘upgrade’ train)

unfortunately, because its not cheap… most only buy if they are invested in Live, and so ‘hackers’ are not that common (even though Ableton were great in releasing a detailed API for it)

so if you are hacker (and you also use Live) I think its awesome…

to balance the pros, two cons

  • its pretty big, all the buttons, pads, screen take up a space.
  • while it works bus powered, the display is not bright enough imo, without external power. (ymmv)

how this translate to norns?

for norns (still waiting on MCM collective noun!), its absolutely fantastic
in my current ‘cuckoo’ mode, it replaces the screen, the encoders, the buttons, acts as a monome grid (8x8, or 16x8 virtual) and can switch to midi controller mode (for pads) - its awesome :slight_smile:

after this, im going to add a ‘native’ mode, where the screen will be accessible in full resolution and colour, and all the buttons etc - this is probably what i will write apps for !


other ideas…

unfortunately, I traded my Push 1 in … and im still waiting for the price to drop on these.
I reckon Push 1s will when the price drops, could/should become a really popular hackers controller.
its screen is restrictive ('character based) , but there is still so much potential with it, and its really easy to code for.

2 Likes

you have the actual norns hardware though :slight_smile:

just use a normal computer (even a pi is fine) with a web browser, connect via wifi, and start using it. i appreciate wanting to get it running on a pi (i want to do this too) but if the main goal is .to learn/use norns, i’d suggest using the software/setup we spent years designing/building so you wouldn’t have to reinvent

that said, as a technical endeavor i’m happy you all are digging in

8 Likes

yes, and that is what became obviously clear to me this morning.
I have YEARS and years of SC2& 3 experience going back to a class on micro-sound i took on electro-acoustics which got me into supercollider and i took three classes and was VP of the supercollider club in grad school so i am comfortable with SC and my first idea is to make a
SCtweet loader with Norns. and have the buttons load a random tweet with lua and then learn some encoder stuff for some randomness/parameters on a griesinger reverb or a delay to get stuff sounding consistent.

1 Like

@zebra gave a good insight into porting your SC code above. try it out, it’s awesome

1 Like

i am sure you have seen this then
https://sigabort.co/p2d.html

Yes and that;s what coffee and the weekend are for.
i have a personal thing i will send you a PM

thanks for everything Brian and thanks for Norns bro

1 Like

yeah, if I had the option of the full monome hardware - Id definitely spend my time using (and extending) that.
I’d not bother replicating whats already possible, imho, theres not even really a technical challenge here, about IF it can be done, we already know it can, its more just legwork to actually do it.
(and if you count the number of hours spent you’ll doing this, that certainly justifies the cost of a norns)

more importantly, there are huge possibilities within the whole norns ecosystem , and lots of things to help grow and mature - if you have the hardware, Id do that…

as i say, its a necessity for me, so its different (imho) , and also there is an interesting programming challenge contained within it, which helps me get familiar with the norns codebase

… but I’ll be honest the building/customising the distro is pretty tedious for me, not hard, just boring :wink:

but we are all different, we have different goals, and enjoy different things… so each to their own.

1 Like

@tehn, could this topic perhaps be rename to “Norns on Raspberry PI”,

even though Ive a PiSound, I think that this is largely irrelevant in this topic.
just a simple tweak (to jackdrc) , the main meat of this topic, is the rPI and configuring raspbian.

others…

how far have others got?

Ive mentioned on the dev thread, im getting xruns on earthsea, anyone else seeing this?
(though this is on my general purpose rPI dev image, so not really optimised much)

I tried various jack settings (whilst keeping buffer at reasonable levels (256)) but still xruns.
but, after info from Brian, Im now building a new kernel with preemptive, performance governor, and 1000hz timer, to see if that helps.

Im then going to be hatcheting quite a few running services… to ensure on the essentials are left running.

once Ive got this dev version ticking along nicely, Im probably going to build a new ‘light’ image,
based on the wonderfully complete information generously provided by Brian on the norns-image repo , with a few tweaks along the way.

hopefully because I already have my ‘dev’ image working, that can be fairly streamlined, and I can therefore keep some notes while i do it.

3 Likes

yes i agree. i think buildin the stuff helps me understand the ecosystem as we are calling it because it really truly is and my desire is really to add lua to my compentencies so i was liek "what am i doing? wasting time struggling with something when the product is sitting right there.

BUT!
It got me a working proper version of nodejs on the raspberry pi v8
i updated my SC build on there from 3.9.-0 BETA to 3.9.3
and i learned about go/glide with go get is pretty sexy for dev

1 Like

i am not getting any xruns with the piSound that i can add too, don’t you have one of those?

1 Like

What’s your jackdrc look like, perhaps larger buffers?
I get Xruns (see crone output) with earthsea if I have say 6 notes playing. (Aux on). - not constant but a few glitches.

Might be some rogue services I’ve got running though as this is a pretty standard desktop image.

Also, if you do top, how much cpu do you see matron using, if you have a grid plugged in and running?

/usr/bin/jackd -P3 -dalsa -r48000 -p1024 -n3 -m -S -D -Chw:pisound -Phw:pisound$

zer overruns and the awake patch which is light of course was running for two days

I do have official hardware coming in batch 2, but I’d also like to get a pi build going when that arrives, for the simple purpose of having a backup I can swap in, should something go wrong during a performance.

Object redundancy is important, and some things are expensive to buy two of.

1 Like

yeah, im not getting any xruns on awake

ok thats a lot bigger buffer than im using, the norns is using -p256 , and thats really my target… I want it low latency.

good idea…
what do you plan to use for the UI though?
I think for a backup solution, Id be tempted with a 7-10" touchscreen, with virtual buttons/encoders.
its not ideal, but for a backup, you could ‘struggle thru’ with it, and its small enough to put in a backpack, that it wont be a hassle to take a long ‘just in case’. (you just need to remember to keep the two things sync’d :slight_smile: )

Ive not seen the Norns , but its small form factor is very appealing… so you’d want/need (?) your backup similarly sized?!

what about a lemur app with the OSC

so new kernel = much better

for some reason I still need to set the governor manually (well in .bashrc or similar) even the performance is default.
but now Im generally able to use -p 256 , not as good as norns which appears to be -p 128

I can get that to xrun if I really push it, but i think for normal use its probably ok.

but seems still room for improvement, 69% cpu
what I don’t like the look of, is that almost all of the cpu load is on one core… 64 … other are at 6,4,5.
now given matron is on 26% cpu, the question is… why is it on the same core as scsynth!

interestingly, let it run for bit, and xruns disappear, - why because i can see some of the load move to another core
hmm, time to look at processor affinity i think :wink:

1 Like