#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
#29

Ive built norns (crone/matron) and maiden and trying to get it to run…

my first tiny hurdle was norns assumes its in ~/norns (in the lua scripts) , thats was easy enough to fix with a symlink (and I did the same for dust while i was at it)

after some initial issues, I also discovered you need to run sclang, once before you run sc/install.sh, otherwise the SC default abstractions are not there.

(btw: as stated below, I think it would be better if crone flagged to matron the cause of an error during initialisation, even it it was just, ‘fx failed to init’, rather than it just timeout)

that said the journey (see below) to resolve the issue was useful to trace thru the process to see how matron and chrone sit together, and how the osc messages flow for control etc - pretty confident I have a basic understanding after architecture now.

anyway, i think all is good now, I just need to make it so that I can read whats on the frame buffer :wink:
then I’ll check maiden is working (I dont think that’ll be problematic, seems straightforward enough)

then I can get on with some ideas Ive got…

thanks to all those involved on the project for the docs, they are very good.

you can now ignore the following, this is just left here for reference in case someone else might be treading down this path…

(mods: feel free to delete if you think its obvious/un-useful)

crone

ok, so I run crone.sh , and I can see an error class Recorder not found (then new message not understood, I assume from class error)
I also seem to get DoesNotUnderstandErrors on Meta_Crone::initTape, and possibly something to do with Meta_AppClock?

any obvious thoughts? (Ive run sc/install.sh, and that appear to work)
if not no worries, I’ll dig deeper.

matron

so the sparkles come up, I see norms.lua.statup(), and start_audio(), then device add : (a few things)
then just sits there.
Im assuming some kind of initial menu you should come up? but its waiting for something?

EDIT: ok, found the addendum describing startup, for others looking it can be found here

any clues, whats next on the log?

on both counts, no worries if its not obvious I’ll start exploring the code, really just after hints on where to next look … or are any ‘red-herring’ errors/warnings expected… or should it all be nice and clear :slight_smile:

updates:

(so I dont keep posting, I’ll post anything extra i find here, again in case useful for others )

a) so after reading above, I now know Im stuck in startup.lua:start_audio(), waiting for norns.startup_status.ok() to be called, and its not.
then I waited a bit, and got the timeout, so audio engine error, then I get something else on teh display,
(but its too small to read, so Im going to need to hack screen.c (or something) to cope with the much bigger display fb :slight_smile: )

b) ok, so gone back in the stack, learning more about norns…
so crone is not sending /chrone/ready (from crone.sc) despite matron sending ready (on correct port)
interestingly, I can see /poll/vu coming in, so crone is able to send osc.
so perhaps those crone errors are causing the issue - I now know what to start poking in crone.

c) yup, as suspected the recorder errors, cause initTape to ‘crash’ and so complete not get set, so chrone = not ready = matron sparkles… probably would be better in these cases if chrone caught errors, and sent something back to matron to ‘flag issue’

now the hunt for me, is to find out why recorder and the other errors are happening in initTape

d) issue found, you need to run sclang before sc/install.sh … if you dont, then you need to delete ~/.local/share/SuperCollider/, to let sclang initialises it before norns adds its extensions

5 Likes
#30

ok, next topic :slight_smile:

screen.c…

why is: cairo_image_surface_create, using CAIRO_FORMAT_ARGB32
while : cairo_image_surface_create_for_data, is initialised with CAIRO_FORMAT_RGB16_565
should they not be the same? (they need to be for my framebuffer)

ok, then more generally…
screen functions appear to be all based in pixel units?
is the idea for other displays we use a scaling factor for this?
or does cairo allow for scaling?