Skip to content

201231: meeting notes

dan derks edited this page Dec 31, 2020 · 1 revision

norns meeting 201231

present

  • simon
  • brian
  • artem
  • anton
  • greg
  • phil
  • tyler
  • dan

current state of play/community

  • surprised by the number of new scripts
  • how many scripts?
    • 145+ in the catalog
    • scripts contributed to community repo vs how many scripts never get contributed
    • shields brought a ton of people in -- no soldering lowered the barrier
      • curious evolution -- boards w/ nothing, then thru-hole, now snap in!
      • ~200 prebuilt kits have gone out
  • greg's maiden updates look really nice
    • accessibility was a big motivator
    • greg learns by taking something, duplicating it, then changing it
      • but there's nothing in maiden that makes this easy
      • so, want to add features that allow somebody to copy and modify with one click (local forking)
      • also need way to easily back out, so perhaps versioning could be added
      • dd: i love the idea of making maiden a tool for learning code maintenance by mucking around
    • simon: comparable to arduino IDE...you can get into trouble if you want, but there's a lot of stuff built in
    • brian: there's a lot of great command line stuff in maiden
    • custom editors:
      • brian: we maybe don't need so many UI widgets if we can train users to use simple commands (;install)
      • "collecting scripts is the first step to getting interested in norns"
      • are there substantial things missing in working with a custom editor?
        • simon: some issues left with terminating connection from both sides
        • brian: ezra mentioned this being a lua issue?
        • greg: can't run a script via http...maybe more ; magic commands can help make this more opaque?
        • simon: the two REPL tabs are a little problematic -- it'd be nice to be able to wrap those up. folks on discord have mentioned issues (Kenji, Ryan, Tyler, Mike, Sam)
        • docs: should showcase maiden repl as a workflow..sam did good work on this here: https://monome.org/docs/norns/extending/#detour-norns-programs
        • we could have a clearer standalone REPL environment, so folks can use external editors -- this doesn't need to split the user group, though. druid is a REPL, not an editor.
    • maiden gets a lot less love as far as contributions go, so if we put more functionality into it, then we have a question of visibility there -- contributions to the CLI feels unapproachable
      • we need to generate more interest in fixing and enhancing it
      • brian: people would like to work on the backend if they knew what's desired + how to use go
      • simon: small things with a single purpose might be a good guide
    • usage patterns of users + maiden: user research opportunity -- discord/lines
    • tyler: ssh fs was a game-changer
  • tyler: discord
    • 5 - 10 people have joined every week
    • asking for help + sharing what people are working on
    • 150 people
    • #stupidquestions channel: 24 hours self-destruct
      • replicate an incubator feel
    • song project -- monthly!
      • two people who've never worked with github before made PRs!!
      • supercollider vocoder is up next
  • brian: circle needs re-energized
    • prompts to get people into coding
    • need feedback from folks

topic: sam's sdl PR

  • allows for different targets -- provide this software to new platforms
  • brian + ezra have had a lot of talks about how extending to other platforms won't facilitate the goals of the project
    • they want to allow sdl rendering for folks who are developing, but not turn the norns software into a separate product / platform
    • preventing forks has been a major challenge with open source software
    • set standards for what's in the community repo + don't encourage that process
    • could open up screen recording
  • tyler: it'd be great for learning to be able to show the norns screen while demonstrating
    • sam was able to cast the screen to maiden somehow
    • good FR!

topic: screen

  • greg: idea to support multiple render surfaces
    • is norns about writing complex things to the screen? or making interfaces?
    • the more distinct things that can be displayed, the easier it is to associate memory to the key combos (so, not just complex UIs)
    • wants to just draw a new thing on top of an old thing
  • tyler: getting something on the screen lowers the barrier
  • brian: a lot of proposals are focused on extended techniques -- just fully supporting cairo could be a good way in
    • side issue: sam's sdl PR
  • phil is interested in engaging with this

topic: clocks/timing

  • artem: perhaps the only person who understands how clock.sync() works

    • there's always a clock source -- they run simultaneously, we drive via one at a time
    • the reference track stores what's now -- absolute time since we started matron (monotonic clock), beat, bpm
    • clock.sync(1) will wait for the next whole beat -- it checks to see the expected next beat and assigns
      • there was a bug that artem squashed where syncs would happen too far ahead or behind
      • if we trigger a sync too closely to the beat -- then we'd wait for the next one. so, the threshold needs tuned.
      • if we change the tempo, the sync would resume at the scheduled time -- this creates a discontinuity
    • proposed fix: single-threaded scanner that works at 1ms ticks
    • the names of clocks are confusing
    • docs need to be improved
      • have to showcase this scheduling decision-making -- it's not note durations
  • anton: supercollider's pattern library is useful -- could we build something similar in norns?

    • artem: you could build this in a functional way -- a declarative pattern library (greg's covered some of this ground with Sky)
    • co-routines are very powerful, but are a bit of an anti-pattern considered the other patterns of norns
      • anton: look to the supercollider community for documentation and explanation
  • tyler's pattern sequencer could be plugged in

  • greg: the callback mechanisms used in norns are all focused on now, but clock.sync() is based on future -- time is a curve, especially with an unsteady clock.

  • brian: the clock system is presented as a separate concept -- so we should integrate this / make it more cohesive to the docs.

    • syncing becomes hard to conceptualize with multiples of a beat -- versus sleep
    • so maybe we need a sleep converter accepts a note value...
    • artem: best would be to combine sync + sleep in one co-routine -- and we should have a conversion for note values for sleep
  • how do we name these functions? the current phrasing is a little problematic...

    • need a "waiting for a sleep quantized value" name -- tyler: "dream"
  • global transport cannot be a core feature, unless we can break from it?

    • start/stop callbacks would be useful
    • it should be script-level
    • better docs would help!
  • greg: is there a place, in the system, for start/stop to operate?

    • and then scripts are responsible for syncing into this
    • just add to where PARAMETERS > reset lives

topic: logging, debugging, user assistance

  • how to get logs?
  • greg: could have a button in maiden that downloads the log to their computer (diagnostic dump / crash report)
  • greg: the collection process should just be a well-known shell script and we can ship it
  • simon: should user get the output as a bundle? or just a pastebin?
  • brian: how and what to export?
    • simon: we can use journalctl, we just need to pick the unit we want to see logs for

topic: docs, API cleanup and standardization

  • https://github.com/monome/norns/compare/help

  • documentation takes time but so much needs documented

  • API: phil is interested in engaging with this

  • brian: this is first order of business. it's where the system is worse.

  • autoexport docs are garbage versus what users actually want to read

  • processing.org's documentation is goal

    • human-curated + cultivated
  • our API in general is pretty inconsistent. set up a lot of C-code conventions, but not a lot around tables, etc.

  • humanization around the API + documentation

  • greg: our existing inconsistencies is also demotivating -- without an established, desired style it's very hard to approach adding to it

    • phil: agrees -- norns is at a stage where a bunch of exploration happened, but now we have the opportunity to step back and shore things up
    • maybe it's time to break APIs in the interest of tightening the entire ecosystem
    • core metaphors should be agreed upon -- the product has taken a shape that it didn't have two years ago
    • brian: add more musical libraries like Tyler's sequencer lib and Greg's Sky
      • we need documentation for these
  • brian: doesn't want to document API's that don't feel good

  • tyler: could we move docs to a wiki?

    • anton: +1. git is hard. contributing to documentation shouldn't require learning git.
    • brian: this requires additional authentication, though. adds a different barrier.
    • simon: move from reviewing to actively curating
    • brian: open-source solutions would be awesome
      • we want to keep great information on a separate platform, so we can avoid bit bloat + misinformation

concept: skill tree/cluster, different approaches to norns, encouraging participation and engagement on different levels

  • we should have more regular syncs / follow-ups
  • phil: looking for more ways to engage / re-engage -- end of year, time of life, etc.
    • wants to see what non-programmers are encountering
    • are we reaching non-developers and artists the way we'd hoped?
  • phil: now's a good time to take stock, with how many new folks are in the room

etc

  • PARAMETERS system is sticky
  • brian: the focus switching is a bit fragile because it's all rooted in lua -- race conditions. ezra mentioned moving all the menu logic to C.
    • a more focused system necessitates UI toolkit
    • these layers need to return to the right level of the stack
    • "an octopus problem" which might be best as a redesign in C
    • also, it works pretty well right now, so maybe we just do something else?

uncovered:

  • short term: next update ETA, options for inclusion
  • long term: goals (briefly, topics to be discussed below/afterwards)