Norns: development

[shreeswifty]

i agree with the non-spliterings and the idea that

the experience could be “finished” by adding glue for a cairo window and virtualization of the GPIO inputs (encoders and keys). these additions would be welcomed as it’d support a large user base.

so software fans could experiment with Lua/SC to make patches easier
the build so far was not super difficult it just needed as @ngwese offered a little direction about what and how
i have not done much with cairo except include it in the past and of course last night but a release of everything which i am sure is planned will be welcomed so those not dev savvy can contribute with their musical skills.

For example in Derel Holzer’s Vector Synthesis endevaors with pd it really needed an XY Oscilliscope “app” that made the entrance intoit joyful so i was thinking that maybe something like that for the cairo stuff in OF or something simpler would be wonderful

i am about to go pickup my physical Norns and experiment with it this weekend and i am sure i’ll have some more questions and probably wishlists or task lists very soon

[mzero]

Cloned the repo and looked over the code last night. I’m still trying to sort out all the interfaces with the HW that would need to be stubbed out for a non-norns port… even on linux, it seems there are still several things beyond just the screen and buttons. (A “norns-bios” layer?!?)

I did have one thought for how to go about bringing up the environment on a system w/o the HW screen and buttons: Ship the screen image back to sclang, and use the GUI classes in SC to draw the screen, and provide on-screen controls for the three buttons and encoders. Either the bitmap itself could be passed and painted… or the Cairo primitives actually map pretty directly onto the drawing commands in SC’s Pen.

[TheTechnobear]

probably a question for @ngwese , how tied is Maiden to norns/lua?
Ive had a couple of projects where id like a web-browser for SC, where sclang is running on the host (which is where my midi devices are)… when I first heard of Maiden, this sounded like a possibility… then once the talk of lua started, I feared perhaps not.

thoughts? it seems generally for SC a web-based editor onto sclang could be a useful thing, perhaps a ‘spinoff’, if its not inline with norns objectives.

(note: ive not ploughed thru the maiden code yet, mostly the norns server side)

[zebra]

my main interest will be different display/control services (i.e. not based on the Linux fb, as you are currently using) , and this obviously need more C/C++ code.
(so basically screen.c/h needs to be abstracted a bit)

this should be pretty simple, not requiring a lot of further abstraction, just pair of functions for creating/destroying teh cairo surface
opened issue
[ https://github.com/monome/norns/issues/391 ]

[ngwese]

how tied is Maiden to norns/lua?

maiden is only loosely coupled to norns. Currently there are some hard coded assumptions about file types but that is likely to get addressed. The REPL only assumes that the underlying interpreters are available via websockets (and there is a static config file which it loads to learn about which ports to connect to).

There is some specific knowledge/coupling around the play button as that works by sending lua code to matron for evaluation.

Moving forward I anticipate maiden becoming more coupled to the norns ecosystem in various regards in an effort to improve the development experience. There are several areas that I’d like to explore around content sharing and potentially a project/package concept to better manage dependencies…

[shreeswifty]

yes, apparently it is
On my machine i only needed
libevdev https://www.freedesktop.org/wiki/Software/libevdev/
&
nanomsg http://nanomsg.org/
and a simple
./waf configure
sudo ./waf install did the trick
i will share that nanomsg had to be compiled from source the apt-get repos i was pointing at did not have the latest one.

[robbbiecloset]

Answering my own question here but it looks like engine code is not present via maiden at the moment, so I assume it will be worked on in a local (non-norns) build env which will have to be built and installed over on norns.

If anyone knows whether or not I’m getting that wrong I’d appreciate the perspective.

I guess it also leads me to ask: just because the engines that ship with norns don’t seem to be accessible via maiden, can we add our own custom engines that way?

[zebra]

Norns: dust

it will be worked on in a local (non-norns) build env which will have to be built and installed over on norns.

you can do it that way, or you can edit SC classes directly on the device over ssh. (we have used a combination of both approaches so far.)

currently there isn’t really a convenient and functional way to restart / recompile the SC class library, except by manually running sclang and matron processes from ssh sessions. (there is the audio.restart() method in lua, but it has drawbacks - e.g., currently doesn’t re-initialize global effect parameters and I/O levels.)

more tooling for SC development will be added, not in this next update, but probably starting in the one after that.

[robbbiecloset]

Thanks, this all makes sense & helps a ton. I’ll play around in there this weekend.

Norns: dust

manually running sclang and matron processes from ssh sessions

Per the docs (if I’m understanding them correctly), this translates to just:

./crone.sh

followed by

./matron.sh

?

[zebra]

those scripts will redirect stdio from the matron and crone processes to websockets, for use by maiden.

if you want I/O on the terminal, do

cd ~/norns
./waf
./build/matron/matron

in one session, and just plain old sclang in another.

[mod hat: i’m going to move these posts to the develoment thread.]

[zebra]

Norns: dust

any suggestion on how to fake the cairo surface?

[ https://github.com/monome/norns/issues/

that is, 1) create an X window, 2) use cairo_create_x11_surface()
[ https://cairographics.org/Xlib/ ]

[sam]

When you run a Lua ‘app’ from the Norns menu, does the app run in it’s own:

• Lua environment
• sclang instance
• scsynth instance

or does each app reuse the running instances?

I can see there is an audio.restart method that recompiles the class library (and effectively kicks) sclang, does that also restart scsynth too?

[jlmitch5]

Maiden is a react/redux app built around the open source ace editor (also a third party lib called treebeard for the file tree pane). The go stuff is a super simple REST api for doing crud operations for the scripts/datafiles/etc.

I think it might be somewhat difficult to make the Maiden repo work with other systems, but it would probably be a great reference or starting point if you were interested in writing a react/redux web-based code editor/viewer. And it’s GPL’d so you can use the code itself, as long as wherever it’s used is also open-sourced (I think that’s the gist of GPL…I am not a lawyer disclaimer)

[tehn]

Hello, I’m a developer and I own a norns. I would like to contribute, should I just grab an open issue that appeals to me in the repo? Or is there an another way you delegate tasks?

hi eric! check out the issues page and for what we’ve noted in terms of features and fixes, but feel free to work on anything that you yourself would find useful immediately. perhaps spend some time with the device first and see how it works for you as is. and would love to have you onboard!

how tied is Maiden to norns/lua?

for a web based sc-editor it seems almost appropriate to just start from scratch with maiden as a model. fundamentally maiden is the glue between the ace editor and the file system + norns REPL.

edit what @jlmitch5 said (also thank you @jlmitch5 for the fantastic maiden contributions)

if you want I/O on the terminal, do

cd ~/norns
./waf
./build/matron/matron

in one session, and just plain old sclang in another.

remember ./waf configure if you’re using a fresh checkout

[zebra]

When you run a Lua ‘app’ from the Norns menu, does the app run in it’s own:

• Lua environment
• sclang instance
• scsynth instance

none of the above; rather

or does each app reuse the running instances?

yes

I can see there is an audio.restart method that recompiles the class library (and effectively kicks) sclang , does that also restart scsynth too?

effectively yes; a local server is booted as part of the Crone startup method. (we might change this to use an explicit scsynth instance.)

right now working on some changes to make audio.restart() more useful as first step to a functioning workflow for live-editing SC components.

[sam]

or does each app reuse the running instances?

yes

How much danger is there for memory leaks building up and for previous Lua apps causing bugs in future Lua apps running in the same instance? (And likewise for sclang & scsynth?)

Really I’m coming at this from the point of view of trying to head off potential support requests. If there is the danger of apps leaving cruft behind then you can end up with horrible heisenbugs that only occur if apps are run in a particular order.

---

On a separate tangent, it’s so cool to see so many of the regulars here contributing their strengths to the development of Norns.

[tehn]

How much danger is there for memory leaks building up and for previous Lua apps causing bugs in future Lua apps running in the same instance? (And likewise for sclang & scsynth ?)

bug tracking is the difficult bit. memory less worrisome.

there’s an issue already: https://github.com/monome/norns/issues/258

[ppqq]

If there is the danger of apps leaving cruft behind then you can end up with horrible heisenbugs that only occur if apps are run in a particular order.

agreed. another gotcha is that evolving module dependencies is tricky. that is, if you have a script MyScript that requires a helper my_utils that you’re actively developing it can be surprising that my_utils does not get reloaded on changes. (see also the ticket tracking a module-reload from maiden.) . with sand-boxing this may just work as expected.

[sam]

Excellent, I’m glad that you’ve all been thinking about it already.

One comment I’ll make about the ticket (here, rather than add too much noise there):

the question i still have is, what’s better - getting people to use good lua code style, or making a sort of complex environment that will protect them from the consequences of bad style?

good style is probably best, and we should suggest this in the short term given the sandboxing isn’t going to happen overnight

good style is totally a hostage to fortune!

---

One other thing that I think may end up causing support issues in the future is the existence of the lib folder in the Dust repo.

Code re-use is good, but… it’s not unreasonable to suggest that in a years time we could have 50-100 apps/scripts in the Dust repo, not to mention countless other scripts not in the repo. That will make it really hard to make changes to anything in the lib folder for fear of breaking scripts (even fixing bugs can be problematic).

Also users may end up tweaking a Lua or Supercollider script in the lib folder for something they’re working on, not realising the consequences to other scripts.

Ultimately I guess it comes down to how curated we expect the Dust repo to be, and how we want the burden of keeping all the scripts working to fall.

It could be that we can find a system to move the library files to each users’ script folder, e.g. lib/lua/pattern_time.lua would move to scripts/tehn/lib/pattern_time.lua. I like this as it shows ownership, and even if we provided a way to require scripts from another user’s folder, there is an implication that you shouldn’t rely on it not changing.

[tehn]

i appreciate all your points!

some libs certainly need to be considered “common” as they’ll have heavy re-use. what’s difficult at this moment is that the libs aren’t complete and perhaps in their final form. i imagine over time (the first few months) we’ll arrive at a collection of core libs that can enter some sort of protected status… but it’s nice to be able to edit via maiden hence inclusion in the dust repo. we’ll just need to be careful about breaking changes.

i’ve just added some contribution text to the dust repo readme, and would very much appreciate further input from the community in shaping the idea behind this collection.