#1

Hi i am about to work for a few days on the Raspberry Pi3 that has a pisound [96Khz/midi DIN]
i also see on another thread in the Blokas community that SC3 can run “headless” which is very encouraging for making one of my piSounds a Norns box

https://supercollider.github.io/development/building-raspberrypi.html
nano ~/autostart.sh #and add the following lines (ctrl+o, ctrl+x to save and exit)…

#!/bin/bash
PATH=/usr/local/bin:$PATH
export DISPLAY=:0.0
sleep 10 #can be lower (5) for rpi3
sclang mycode.scd

I know there is a ton going on but any caveats before i nornify my pi?

6 Likes
Can one use A launchpad or Push 2 with Norns instead of a Grid?
Norns: help
Equipment for making music with field recordings?
Fates - a DIY norns DAC board for Raspberry Pi
Norns: ideas
Equipment for making music with field recordings?
Norns shield Eurorack housing
#2

my PI+PiSound is already running full blown norns :slight_smile:

18 Likes
Norns: ideas
#3

nice, I’ve be MEC-king patches all weekend and finally getting some time
Any gotchas or weird shenanigans you noticed?

#4

Can you share more info on how to achieve that?

#5

Well the Norns is running one and i assume that he’s made his own Cairo_wrapper/workarround?
I’ll post my struggles/successes here as i take a crack at it today but i think the most difficult part is simulating the Cairo interface and the buttons/navigation which technobear seems very adept at making easier for devices to talk to “stuff” but i am sure he’ll weigh in

1 Like
#6

care to share your process?

2 Likes
#7

Im happy to, but it appears some elements of the community might not be so happy about this,
so perhaps we need to clarify this first. (I included you on the PM I was sent, and my reply)

2 Likes
#8

I’d be interested in replicating this on my PiSound set up, as well, and then helping make it turn-key.

Norns spurred me to rebuild my Pd based PiSound rig in Super collider. This served multiple purposes: learn SC, see if I like sclang(1), see how well it works on the Pi(2), and prepare for possible work on norns porting.

It’s gone well: I’ll be playing live with headless PiSound, running and processing my rig via SC. That is, a very norns like use…

As you can tell from my posts, I’m quite interested in good modular frameworks, esp. for MIDI routing(3).

Hoping there’s no community friction to a PiSound build. And open work on it.

(1): OMG, it’s SmallTalk!
(2): 5ms audio in to out latency with my full effects chain engaged. <2ms MIDI (USB) in to out latency. This is about 1/3 what I was getting with Pd.
(3): Even in my short time with SC, I found no MIDI component high-level enough, so I wrote my own: 600+ lines and a dozen classes that let you route and scale MIDI between devices and to/from synths in very few lines of readable code. I’ll relase as soon as I wrote some documentation… unless anyone wants it sooner!

9 Likes
#9

I think there should be an open-air discussion here regarding the propagation of norns (as a software ecosystem) and norns-enabled hardware.

I suspect that the unhappiness directed at @TheTechnobear is rooted in a protective feeling towards monome as a company and the possibility of sales lost to DIY norns-enabled hardware. Monome are the only ones capable of giving us direction on that issue. Hopefully they’ve chosen licenses which reflect the boundaries of what behavior they’d find acceptable.

The other aspect is the unity of the norns ecosystem, i.e. preventing multiple hardware implementations from creating splinter factions. I’d argue that NOW is the best time to start making norns support multiple hardware platforms. There will always be apps aimed at certain external hardware (Grid, Arc, specific MIDI controllers, specific MIDI synths, etc.), but the base experience could be available to anyone with a computer and audio interface. The longevity of norns might benefit from what I’d call “ubiquity through accessibility”. Take a look at the VCV Rack community for a good example.

5 Likes
#10

norns is licensed under GPL

norns is built upon some exceptional open-source projects (lua, supercollider)

norns support across hardware platforms and for integration with various controllers is welcomed. we’ve already intended to put energy into having norns work on normal linux computers— so any contributions from that angle would be appreciated.

we’ve put years into this project and we want to see it stay cohesive and build on what we’ve started: the foundation of this project is sharing knowledge and collaboration.

(mod edit, changed thread title)

39 Likes
#11

second, i think it’s important that we do some name differentiation, soon.

norns is the harware.

maiden is the web editor.
matron is the application that runs lua scripts.
crone is the supercollider layer.

i’ll come up with a collective name for maiden, matron, and crone.

25 Likes
#12

I’m sure a little musing on the topic should bear fruit.

5 Likes
#13

I want to parallel my dev on a Raspi so i can simulate on software what would be going on in/on the hardware.
I usually like to buy my ticket to the show Grids/Arcs/Organelle/Blokas/Mod-Duo/OWL so when i ask i am not trying to create splinters but i also know that i am not going to spend the hours on making a Cairo layer
i know SC has the ability to do MIDI/Graphics like with LNX_Studio
https://sourceforge.net/projects/lnxstudio/files/LNX_Studio%202.0.3.h.zip/download

Is there a way to do that and maybe get the functionality on a raspi?

I agree that some folks would not welcome some “version” of Norns that is available to those who do not want to pay for the device itself but i think we are in a unique situation though being years of planning it’s still IMHO in a ‘release-wise’ nascent stage and what i am really saying is that IF i can get it working “in Parallel” i can contribute more to making it worth while for me as a music makin tool not just a platform for my “software”

1 Like
#14

Might I suggest “jötnar” for the collective noun?

4 Likes
#15

And i don’t know what was said to the technobear and it was certainly not me but what the oracs system and the o/s he provided for organelle WAS NEEDED. When i bounced into the forum almost two years ago there was like 4 posts a day. People were promised patches every week and then that fell off and people were PISSED OFF. I found a device i liked to play with because i dig Pd and now i see an active community and of course i am NOT by any means taking credit for their success/failures but i contributed and was rewarded on several levels --mostly by enjoying the sounds. But i think some people like to play who has the biggest linux wong and that might annoy some folks once in a while but it’s really not that often. BUt i think for the most part what went on there was making a simple device simpler and cleaner to deal with for some folks but most of it is just a choice you make or dont make based upon your expertise

6 Likes
#16

heya, just want to say that i also don’t know what was said in private to @TheTechnobear

but i do wanna point out that all the systems in norns were chosen to be pretty hardware-agnostic, and to use standard linux hardware abstractions. encoders and buttons use /dev/input. audio uses jack. screen uses cairo and /dev/fb0. the kernel customization is mostly just to support the bespoke internal soundcard and to strip out uneeded components for a faster boot.

it is totally possible to DIY a norns and that is by design. we all want people to be able to use and contribute to the jötnar components on a budget.

all that said, there are some bits that could me more abstracted. like screen, and hardware gain control (uses i2c.) someone wants to open a GH issue collecting those tasks, i will contribute to it and answer q’s as best i can.

my point in the other thread is just that it’s not totally realistic to expect me or brian or other norns developers who are working on supporting the monome hardware, to devote a lot of bandwidth to supporting other hardware. that’s just a time thing; almost all of us are doing this work in our spare hours after our paying developer gigs - and brian of course has put about two million hours into making his own awesome hardware and is primarily concerned with making it more awesome.

this really shouldn’t be a huge issue. three options: 1) make your DIY screen show up on /dev/fb0, 2) tell matron to use a different framebuffer device, or 3) use an x window.

i really will try and get something together using an x window soon soon. this is gonna be a compile-time flag for me, but no objection if someone wants to make it fancier.

my personal goal in doing this is not to replace my norns hardware, but to be able to streamline the workflow away from the hardware. (echoing what @shreeswifty said - having parallel hardware support makes it easier to make more creative contributions. i’m sad that most of my time with norns has not been spent creatively thus far.)

16 Likes
#17

The more energy that gets put into building INSERT COLLECTIVE NAME FOR MAIDEN+MATRON+CRONE into a powerful, integrated, extensible and sustainable stack of interconnected musical applications, the better. Physical implementations of this stack will evolve to support the needs of the stack and the preferences of the communities that use it.

(PS: 三相女神 Sansō megami or just Sansō has a certain flair)

5 Likes
#18

lets move on…

I think having this discussion is positive, and Id like to post in this nature…

first, clarification to perhaps avoid further miss-understandings
(then I’ll discuss , what im doing, and where im at)

because, I was not being explicit about what I was working on, there was an incorrect assumption, that I was asking questions because I wanted to take ‘norns’ to another platform, specifically the Organelle.

I generally don’t like talking too much about what I’m up to in advance, so as to not raise expectations, or put myself under pressure to deliver - this is quite common in development, esp. when there are a few unknowns as there are here.

I think thats my prerogative, but perhaps it inflamed the situation , I dont know, certainly wasn’t my intention.

what am i up to?

Im looking to add Ableton Push 2 support to Matron.

  • Yes, this would be for me to use on the rPI+PiSound+Push2 , as I cannot effort to buy a Norns+Grid, I just dont have the money - however, Id like to contribute to this project as I think its interesting, and also something Ive some experience/skills in .

  • But also, the Push 2 support would be useable by Norns hardware users…
    (hence my expressed thoughts on secondary displays)

as a few know here, I do quite a bit of open source development…one important thing Ive learnt, is its when you do these things, it never solely about your own ‘goal’, but how to generalise, to help future developers do something similar.

So, I recognise, there are not that many Push 2 users with Norns hardware (or with rPIs for that matter).

but thats not really the point, by developing push 2 support, I need to answer a few ‘interesting’ questions:
(at least to me)

  • can we have alternative/supplementary displays? (e.g. touchscreens)
  • can we have alternative/supplementary grids? (e.g. launchpad)
  • can we override a MIDI controllers implementation for more specific support (re:vid/pid) ?
  • can devices be some how generalised, so apps are ‘shielded’ for specifics, whilst allowing ‘extras’ to be added.

these are all things, I thought could be useful outside the push2 , and by studying the source code, I could see have a few challenges and so I was asking what the ‘developers’ thoughts were, nothing more.
I intended to do the code changes… just i wanted to have a feel what they thought the ‘right’ direction is.

of course, I recognise, these are early days, so there is no criticism implied/intended, rather a will to look into improving something I have an interest in… and for me that is what open source is about!

so thats it, I freely (and openly) admit its unlikely I’ll buy a norns + grid, I just don’t have the money.
However, Id hoped, that I could still find a way not only to use ‘norns’, but also to utilise my skills, to contribute , to improve it.

where am I?

as stated, I have Matron/Crone running/working on rPI3+PiSound, currently its using an attached touchscreen display - to just test it.

I also spent quite alot of time, looking thru Matron/Crone to see how the Push 2 would fit in, given its display, encoders, midi and a grid… (hence my questions)

as some will know, Ive already written software for the Push 2 for my own open source software (MEC) , so I have all the usb code, and rendering and midi handling - it’ll just need adapting
yesterday, I spent a bit of time converting MEC push2 support over to using Cairo, as used by Matron.
(so I knew it would work, before putting into a new framework)

today, I had planned to start coding/integrating it, until these ‘questions’ were raised and rather dampened by enthusiasm, so unfortunately, its not been done…

last point, for transparency - porting to Organelle.

as i said, Ive no current plans to do this and never have. (some other user implied i might not me)

actually, I think there are a couple of technical impediments to this anyway, basically the arch linux in place is too old for many components required… so if this was ever to be done, this would be after I complete the ‘Linux upgrade project’ (something else Ive worked on to give back to the community)

great idea to have a collective name for Matron/Crone/Maiden… I use norn due to the repo name, but its cool to reserve that for the hardware.

21 Likes
#19

I don’t know how far along you are with push2 support/how generic it is, but you could have a look at leveraging Ctlra https://github.com/openAVproductions/openAV-Ctlra. It’s a nice generic way of enabling rich controller integration into applications.
the benefit would be that it would be used by more people/projects (there’s work on Mixxx integration) and we get additional integrations with the currently supported devices for free :slight_smile:

I tried to get Push2 support working with a Push2 I borrowed for a week, but I have no C experience so didn’t get all that far unfortunately https://github.com/simonvanderveldt/openAV-Ctlra/commits/add-ableton-push2

#20

cool, well my 2c is that it’s a lot easier to understand the question when it’s put specifically - “i wanna use push2 with the norns stack.” ok!

i also didn’t know what MEC was until just now (or i had forgottenb, apologies.) so, it’s a hub / adapter application that lets you interact with push2/soundplane/eigenharp/&c via OSC, right? neat, ok!

so, brainstorming: what about just running MEC alongside matron? matron is already set up to send and receive arbitrary OSC from lua. [https://github.com/monome/norns/blob/master/lua/osc.lua]

it’s pretty basic - a global callback for all messages - but maybe that’s sufficient for proof of concept at least, requires no modifications to anything. and maybe trying to actually use that subsystem would clarify some ways we could improve it for other use cases as well.

it also seems like the MEC (or parts of it) could be packaged as a library or something? that might make it easier to integrate. it seems like the controller targets for MEC (push2, eigenharp, soundplane) are disjunct from the mostly lower-bandwidth ones that we support on norns already (basic midi, tty, HID)

(so just to be clear - actually we have been asked if norns can run on organelle already. even before norns was shipped! responding to a real question. sorry didn’t mean to imply that’s what you were talking about, but wasn’t sure and anyway speaking for the benefit of onlookers.)

3 Likes