#21

okay so i am going to get the raspberry close to the desktop for norns, maiden and matron before i ask another question

#22

apologies this is a long post, as you’ll see its kind of exploring some broader ideas, brainstorming,
and, im going to have to keep using norns for software, until i get a collective name… or perhaps i switch to MCM ? (matron/crone/maiden?)

ok, MEC already is a shared library/api, so thats not really an issue, but I think a step further, once Ive got some kind of norns platform working - but for sure an interesting idea.

I think possibly we are looking at this from two different viewpoints, so its probably helpful to clarify this.

so my aim, is to get existing ‘norns app’ working unchanged on a platform I can afford, so push2+pi+pisound.

once I have that platform , then I can discover norns, see what it offers, and see how I can contribute further.

from my understanding of the code base, this means the push2 have to work with the current ‘matron api’ (as defined by lua/weaver) - hence my talk of abstraction at the lower levels.

this is kind of a milestone for me, as I can’t develop on something, if what I see is fundamentally different from what norns hardware users see - it would lead me to a different ‘idea’ of what norns is… and thats not a place i want to be.

however, Im getting the feeling you (@zebra) view this slightly differently…
what I think your suggesting is:
(please correct me, here im stating this , so i can get to a common understanding)

push2 etc, should be added as separate matron devices, in a similar way to dev_monome, dev_midi,
and each device has their own api.

the ‘apps’ (is that what they are called, or scripts?) can then be written to use that lua api, specially for that device. (and so use its ‘unique’ properties)

if apps wanted to treat devices similarly, then a lua abstraction layer could be written.
(so we could have a display ‘lua abstraction’, that could switch between using push2 screen and norn screen)

is that correct?

if thats correct i do understand your viewpoint,

the approach means that apps can target hardware specifically (so use all its features), and a lua abstraction could make the ‘cross device’ if thats what the app developer wants.

( im gleaning this understanding for a few others posts I seen you write on the role of lua,
but this might be 1+1 = 3 :slight_smile: )

if so its cool, I get it…and I can understand that view generally, it does make sense for those with norns hardware.

In this sense, your in some ways saying norns is a platform for apps, but the specific apps are a only a part of it.
Im not being derogatory to apps here.
more that norns is worth ‘building on’ to write your own apps, dont be too worried about the supplied apps.

however, I have a problem with this approach for my immediate goal

I do want to see the current apps, as I think they are an important part of what end users will believe norns is,
and to this within ‘your’ approach means:

  • If I want to see the current apps on the push,
    this requires me to :
    write a device for norn
    write a lua abstraction layer
    start adapting the all the current apps
    this is a lot of work, particularly as my core competencies are in C/low level, not lua
  • ive no ‘guarantee’ that new apps will use the lua abstraction (because the developer may only be interested in monome) , so id have to port these too.
  • it potentially ‘fractures’ the norns community, into those with norns hardware and those without.

so whilst I can see how I can do this, I don’t see it as moving me closer to my objectives, without quite an undertaking of work.

Im wondering…

norns is young, the ‘community’ around it is buzzing with idea, so the vision of where norns is going is in a state of flux - similarly, you (the developers) are still exploring, and also have no doubt lots of things you want to add before it reaches your visions.

perhaps, my views are just a bit premature, they are not where your priorities lie… and in some ways are talking about ‘distant ideas’, when the current ideas are not even fully developed.

and similarly on my side, the vision of norns and the role of lua and supercollider etc is unclear, because its still ‘in progress’

so, we are all in a learning and exploring phase…

in that sense perhaps what its better for me to do is simple - fork matron, and just do what i want/need to get the rPI+piSound+Push2 working.
it’ll be on a public repo, so if you want to look you can, but I won’t do PRs etc.

I can then use this as a vehicle to explore norns, to watch it grow, see how the apps grow, and see how norns develops - and this will perhaps lead over time for me to understand the norns ‘vision’ a bit better.
then as this is clear, none of this stops me, pursuing the approach (I think) your suggesting, for push 2/ eigenharps / soundplanes

so in this sense, its a typical ‘prototype’ which can potentially be thrown away, its aim is educational, and lets be honest here, this is something I can achieve in a matter of hours, where as the lua abstraction is days++ , and ‘feeling’ norns in my hands, Im not sure thats something I can commit to.

ironically, this actually was one of the reasons I was being ‘coy’…
I wanted to be in the background, get a quiet understanding of what norns is, and where its going … rather than start ‘committing’ to extend it, before I have a firm understanding of what ‘it’ is, and what shape it will take.

(note: anyone reading this , here im making no commitments, Ive many open source projects… so time is limited)

thoughts?
sorry , another long post, but I guess the important question is
@zebra am i broadly correct in my understanding of how you see new devices fitting in , and the role of lua?
knowing this helps clarify in my mind where you think (at the moment) where norns is going.

finally apologies to anyone if they feel this is all some how a ‘waste of time’ , perhaps it is…
(not my intention, I tried to originally keep the question very specific, but that approach failed too)

my only ‘defence’ is that if you want to attract new open source developers, there is a certain amount of ‘investment’ in time on both sides (I have already spent quite a bit on norns) as both sides explore whats possible - that investment gets rewarded once both sides get comfortable with the direction they want to go, a direction both sides find interesting, and rewarding.

4 Likes
#23

my thoughts
i think that adding cool lua scripts or fleshing out what is already there is what is needed and what others may appreciate.
making things work with what seems to be the direction [and i a sure others will correct me if i am off base would be welcomed and appreciated
i think there is a general feeling–again only my opinion and not necessarily the feeling of the core developers is that not many of us know lua yet really well – but it’s certainly a fun feeling that we as a community will “learn lua together” and make, share and get cool patches for music and art working first before “splintering” it to our chosen expertises.
I am enjoying the fun of learning go and glide, maiden and the other nice stuff it’s fun and i am adding to my core competencies and if i get to run my Pd patches on it as a “Norns Study” i am cool with it

BUt i think SuperCollider being scripted with Lua is the direction --So i would ask you are you interested in helping out or sharing stuff with that before or as i like to say ‘in parallel’ to your MEC/KTRL, Oracs, MI stuff? or can you adapt some of those fun ideas into what is already there?

I for one really like the MEC/KTRL stuff because i like it for circumnavigating the “menu” issues i thin we both tired of in organelle. but i think SuperCollider and Lua is what the vibe is and once again i am very sure i will be kindly corrected if i am off the mark ubut learning something new is what has attracted me and i like the Grids/Arcs/Ansible/Meadophysics/Floor/ aesthetic

(I have already spent quite a bit on norns)

i think that we can all say that some talked for months and because of the previous vision and consistent kindness, generosity and overall wonderful ethos/pathos of tehn were willing to shell out 800$ to support that. Now what i would ask you is this

What do you want to do? Are you willing to make stuff for others to play with Norns or in Nornia :slight_smile:

1 Like
#24

i think maybe you edited while i was writing

#25

三相女神… I love it! “trinity goddess”

2 Likes
#26

a brief bit of encouragement to @TheTechnobear - I get your point and i’m happy to contribute, to the extent that i can, to an approach which let’s people explore norns apps without having to port the app.

for quite i while i’ve been working on using an RPi to run apps on two old 40h grids that I’ve integrated into my modular rig. this effort was enabled a lot recently by @artfwo’s excellent update to the pymonome library.

the virtual grid abstraction that the latest library enabled makes it possible to adapt other python apps to run across two spanned 64 grids without having to know anything much about the underlying hardware.

I had been planning on releasing what i’d done, in case it was useful to some fringe dwellers like me. but with norns out i’m much more inclined to contribute to any efforts that will allow norns apps to run across “non-standard” grids etc

as it happens i’ve also dived in and ordered a current edition grid - hoping to pick it up tomorrow - as I felt like it was becoming important for me to just “make music” sometimes and not be cutting code all the time, plus i figured it would also help me really grok apps running on standard hardware when i was porting them.

i doubt that much of what I’ve done in python will be directly usable in the norns / MCM environment but i’m keen to get an RPi set up soon so I can start experimenting - so if there are others doing similar things i’m happy to pitch in.

let me also say i’ve always been super appreciative of the ethos that @tehn and the community at large bring to the monomeverse. i’m glad to now be in a position to be able to get a current edition grid, but in the many years since building a 40h kit, I’ve always felt supported in my DIY journey, and i fully expect to keep on DIY’ung with edge case interfaces and platforms - the prospect that norns / MCM makes that stuff much less of an edge case is incredibly exciting.

10 Likes
#27

hey, i’m also hacking stuffs on pisound + grid using pymonome (sadly, not so much lately). very curious to see what you’ll release especially the grid spanning thing :slight_smile:

1 Like
#28

making a list for raspi stuff:
also this was crucial for building Norns Matron
sudo apt-get install libavahi-compat-libdnssd-dev
sudo apte-get install lua5.3, lua5.3-dev
libevdev:
https://www.freedesktop.org/software/libevdev/libevdev-1.5.6.tar.xz
nanomsg

nanomsg library
maiden specific:
wget https://storage.googleapis.com/golang/go1.9.linux-armv6l.tar.gz
sudo tar -C /usr/local -xzf go1.9.linux-armv6l.tar.gz
export PATH=$PATH:/usr/local/go/bin # put into ~/.profile
cd to the go/src/github.com/monome/maiden
then run glide install
go build

UI:
for node.js
curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
then
sudo apt-get install -y nodejs

3 Likes
#29

this is all covered in the readme_setup instructions in the norns repo.

#30

@shreeswifty i appreciate you delving into this. it’d be great to make a readme that step-by-steps the process.

can you stop posting partial progress reports, though? having multiple revisions across various threads only adds confusion. alternatively, it’d be great it you could fork the norns repo, start a new file readme-build-pi.md (or similar) and link to it. so the info is always updated.

also FYI all have you seen https://github.com/monome/norns/blob/master/readme-setup.md

which duplicates many steps above.

edit @TheTechnobear and i were typing concurrently :slight_smile:

2 Likes
#31

sorry i wastrying to get a bunch of simple stuff into a post for a readme. i am out of town away from my machines for tomorrow and the next day.
i did not see that because i have my raspi in a weird studio space and it’s only connected usually to a screen and a speaker for pd. So i apologize

pp

#32

@shreeswifty or @TheTechnobear - either of you willing to put your installation and startup scripts – how ever sketchy and hobbled together from shell history they might be – in a gist?

1 Like
Norns: development
#33

hey
i am making right now on raspi so i can help
$GOPATH is my first pain in the hiney. it’s not clear where it should go at first

no scripts yet really. Ezra promised me a template later when he’s not travelling and i am hoping techobear or someone helps out with the cairo/framebuffer thing.

#34

EDIT: mods, I guess this and the previous posts should be in the rPI/Blokas thread, rather than clogging the development thread… feel free to move :slight_smile:

I pretty much followed the setup instructions, in the norns and maiden repo

the only things i tripped over were:

norns/dust are expected to be in the home directory ie… ~/norns ~/dust,
so if like me you clone ‘development projects’ into a separate area , then you will need to symlink them to home.

go installation - basically you need to put go in /usr/local (as expected) but if you use the glide curl installation that will fail, since its not got permissions, and you cannot sudo it… but it turned out its just a single file, so copy that to go/bin - go path then points to your local go workspace (I think thats detailed in the setup docs)

supercollider - i had issues with, as documented in this thread
basically you need to install 3.9 from source (easy enough) , then make sure you run sclang once, then you can run sc/install.ch , I found i had to change the mkdir to mkdir -p ( to create intermediate directories)

overall, Id say the instructions were ‘spot on’ , just a tiny bit of fiddling here and there.

from there, I had to get it working on my setup

so, I did some small mods to screen.c to update it for the waveshare touchscreen i have,
basically just change the dimensions, check format, and then use cario_scale() to scale from 128x64 to something close to 1024x600 - this was for a ‘temporary test’

this meant I could test that crone/matron started, I get the sparkles, and then it launches one of the monome apps, I see the step sequencer graphics and it plays some sounds - so I know I have sound from SC.

the next step is getting a control service to control things… so that moves me away from the touchscreen to a push, which also has encoders/buttons etc - so thats what im working on.

(if you want to do a touchscreen implementation, then you could do X, but Id probably look at SDL so X is not needed)

Ive built maiden, but not tried to use it… im sure it will be fine, but I didnt want to get overly sidetracked.

however, that could be a another way to start out, rather than worry about a hardware interface.
(Id assume you could create apps to control things like the mixer on things other than norns hardware)

startup, we’ll I didn’t want to change the default startup, as i currently have orac/mec as my default, and thats what i need most of the time.

but when I need to , I will simply use systemctl … I think there might even be some scripts in GitHub.com/monome/nornimage ?
(you might want to just check that repo out for ideas, id didn’t need to as Id already got the PI running for audio apps anyway… so no changes needed)

I guess later once Ive got it working to my liking - I’ll probably do something with MEC that will allow me to switch between orac and norns from the push… (as I want the solution to continue to be headless like the pi3/orac)

so yeah just follow the setup docs, they are really done well…

2 Likes
#35

a simple Pi hat with 3 encoders and 3 keys would do the trick for control, with cairo mapped to a connected monitor. that’d be a super easy wire-up with a hat protoboard.

or does the pisound not allow stacking? (sorry, i haven’t been paying attention to that)

but i also know ezra has had this all working with a usb soundcard as well.

again, if you all make progress on certain bits please document them somewhere so we can eventually have a nice centralized howto for people to follow steps— information gets lost on the forum instantly. it’s good for conversation, it’s not good at being a database or a wiki.

6 Likes
#36

does this work for the framebuffer issue @zebra mentioned?

1 Like
Norns: help
#37

sorry, not sure which issue you’re referring to?

#38

when i run scalng & ./matron on raspi the menu system opens to a framebuffer and i am wondering how to pipe that to a X_window

#39

no, this is for making a serial connection into the device (screen is a tty command)

cairo to xwindow requires some low level code, not some linux piping. you’ll have to wait until someone volunteers time to do this, or start reading up on cairo. also, keep an eye here: https://github.com/monome/norns/issues/391 and i might suggest posting further questions there regarding this issue

#40

it has a few spare pins on the headers, but not many
https://blokas.io/pisound/docs/Specs/#raspberry-pi-pins-used-by-pisound

but you could easily use an arduino or something to attach encoders/buttons, and then transfer the data either via uart or usb.

this is pretty easy to do as a conditional compilation (as detailed in 391), it only changes the init and deinit code, the actually drawing functions remain the same.
if its still open when im done on the push, I’ll take a look…