#9

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 ]

1 Like
#10

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…

5 Likes
#11

yes, apparently it is :slight_smile:
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.

2 Likes
Norns: dust
#12

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?

#13

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.

5 Likes
#14

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

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

./crone.sh

followed by

./matron.sh

?

1 Like
#15

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.]

1 Like
#16

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

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

1 Like
#17

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?

#18

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)

3 Likes
#19

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!

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)

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

3 Likes
#20

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.

1 Like
#21

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.

4 Likes
#22

bug tracking is the difficult bit. memory less worrisome.

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

1 Like
#23

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.

2 Likes
#24

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 :slight_smile:

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.

7 Likes
#25

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.

2 Likes
#26

can you not version library scripts?

even if its is just like so’s e.g. pattern_time.7.lua
perhaps with a symbolic link, so pattern_time.lua-> pattern_time.7.lua

of course, inter-dependancies between the libs, should refer to specific versions - all common versioning stuff really.

(I don’t know lua, perhaps already has some kind of standardised versioning system)

#27

That sounds sensible. I think there are 2 ways to go with these things, iterate a lot initially (as you suggest), or start with a blank slate and then promote code from a users library to core once it’s attained consensus.

It might be a good idea to prominently mention that libraries are in flux, and maybe set a timescale (end of the year?) to getting them locked down.

Maybe also consider ways to allow Lua libraries and SuperCollider scripts to exist in user folders too?

Versioning as @TheTechnobear says is a solid option. I’d be tempted to snapshot libraries once a year or so (e.g. lib/2019/*, lib/2019/*). Then scripts can communicate (somehow…) which core API they want. (Need to factor all the system libraries into this too…) I’m sure there are other ways to achieve the same aim.

Apart from avoiding endless support threads, there is a nobler aim to all this, it would be really nice to avoid bitrot and for all the instruments that are made now to still work in the future.

1 Like
#28

something like this is already happening, just the other way around. scripts in dust/scripts/user should have any necessary support in dust/libs/sc/user and dust/libs/lua/user.

its not ideal but for the moment we can keep from treading on each other’s toes.

versioning is part of the plan too. core lua modules have version strings. we aren’t using them in an intelligent way, mostly because i wanted the input of the brain trust on how best to structure that.

1 Like