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

#31

be sure you are running latest supercollider (3.9.3) for the Recorder class

#32

thanks, using 3.7, so will upgrade that :slight_smile:

#33

re: screen

i didn’t write this source but i have been going over it this weekend; def. could use a little cleanup as you note. the pixel format discrepancy might be an oddity particular to this screen.

my goal was to make an x11 adapter layer. shouldn’t be too bad. if this interests you i’m happy to leave it and turn my attention to other things.

does cairo allow for scaling?

yes, cairo_scale() affects all subsequent drawing

1 Like
#34

he he, sorry, I should have looked!
( I need to get deeper into the Cairo api now!)

I’m not really trying to do an X11 layer, but perhaps once Ive got more familiar I can look at it. I don’t really see a need for X for something like norns.

for now, im going to drive a touchscreen directly and that seems to be (kind of) working - but this is all just a step - to see norns working, ive a much more interesting idea for this :wink: (which will potentially be useful to some of the norns community)

2 Likes
#35

Has anyone been doing development in a non linux env via something like docker or vagrant? I may take a stab at setting up an image in the former (because that’s what I’m familiar with) as an exercise in wrapping my head around how all the pieces play together.

2 Likes
#36

I would be interested to hear what you figure out here. I have been doing some dev work on maiden, but missed the preorders so it will be a while until I can get my hands on the hardware.

Specifically I’d like to be able to “use” the REPL pane. It would be cool if I could “run” scripts within the environment as well.

I use Docker for Mac to run docker in.

#37

Well we might have different use cases. I’d like to be able to run and work on norns patches on a laptop, and it’s only like 4 lines to make an x window…

I’ll try and push something in the next days

5 Likes
#38

Definitely agree on there being a lot of value in taking an approach where scripts and engines are less intertwined. It seems at the moment that some of the scripts/engines communicate quite differently with each-other. A couple of ideas…

Could we define standard protocols / subclasses for the most common engine types. Eg, a ‘voice engine’ would have to take freq and gate inputs and output sound. An ‘FX engine’ has to support audio I/O. The majority of engines could fit these standards and then be completely interchangeable between control scripts.

At the moment engine params have to be defined in the lua scripts in order to show up in the menu, could this be automated from the SC or externalized in a separate Lua file associated with the engine.sc? I guess that’s what you’re going for @jah?

I’m also curious as to if there are further plans for the Parameter screen - it seems like we could do more there to organize and visualize.

Sorry maybe we should be in the dev thread :slight_smile:

5 Likes
Norns: dust
#39

@markeats yes! standardizing a subset of engines that are synth/voice engines would be really helpful.

a few ideas for the params screen:

  • i’ve already added the logic for slotted-pset saving (default=0, 1-99 also available)
  • i want to add an interface for midi CC mapping (learn)
  • perhaps psets organized into “subfolders” where a synth pset could be a sub of a main script pset
3 Likes
#40

Cool! MIDI learn and organized presets sounds great.

It feels like some subfolders would be helpful in params, there are often so many related settings (eg, all the filter params together or all params related to one sample). I’m also wondering if there’s sensible ways of utilizing the screen more.

When editing envelope settings would it make sense to do so on a dedicated screen with a visual of the envelope? I could see a small library of parameter UI being built out, similar to the pan control that’s already in Ack but perhaps also fullscreen stuff. Graph displays for envs & filters, waveform display and selection, mixer, etc.

I’d be happy to help out with the front-end work for some UI pieces!

8 Likes