Skip to content

3.0 proposals

ezra buchla edited this page Jul 26, 2020 · 9 revisions

norns roadmap

softcut

  • see https://github.com/monome/softcut-lib/pull/26
  • see https://github.com/monome/norns/compare/dev
  • issues/features: https://github.com/monome/softcut-lib/issues
  • rec/playhead ducking system done-ish
    • both read- and write-ducking are in there. the ducking algorithm works great with simple circular-buffer delays. but with softcut voices there are some edge cases related to sub-heads crossing into proximity with each other. the duck-level calculations are isolated and those functions can hopefully be improved on.
  • added rise+fall slew times for numerous parameters, which means a ton of params for the lua interface. how do we manage this? also easing functions? done-ish
    • i'd say this is complete on the backend, up to the OSC interface. the lua interface could use some QOL helpers to map named shapes to shape indices.
  • multi-stage envelopes handled in lua (must decide a syntax) cancelled, for the moment, i think cramming audio-rate sequencing is a bit much. a system like that really calls for routing options and much more than is really supported by the softcut environment.
  • fix: queue for value-time segments, ie: set value 1 with time 0 and immediately value 0 over time 10. currently this requires a delay so the first pair doesn't get overwritten done
  • new saturation/bitcrush not done
  • filter topology change done
  • waveforms and buffer ops @csboling

supercollider

lv2

menu / system

lua / docs

  • overhaul/evaluate library organization, syntax consistency --- https://llllllll.co/t/lib-development/32800
  • additional libs for common musical needs (identify)
  • documentation overhaul, including reworking studies and creation of various smaller studies/recipes
  • manually edited/curated "script reference" API, not luadoc

modules

  • sky @ngwese
  • tracker @tehn
  • crow 3.0 @trentgill

matron

  • finish cairo threading
  • clock updates (?)

maiden / maiden-repl

  • various possible feature improvements (?)
  • vscode integration tutorial

disk image

  • new kernel
  • update to buster
  • possible update to supercollider
  • possible RT optimizations, cpu affinity

notes from 7/26 meeting

thanks @dan_derks

3.0 meeting notes

what does 3.0 represent?

  • major point version — try to add as many breaking things as possible in one go, rather than piecemeal (aka avoid a soon-after 4.0 bump)
  • users will need to flash disk image from scratch
  • can we run a beta before upgrading? will it be impossible to run a lot of the older scripts?
    • ezra: supercollider changes won't be too bad
  • stored parameter values are the biggest change because level values will mean something different
    • ezra: end-user navigation of breaking changes requires making a clear, simple description of what needs changed
    • can we just transform 'em?
    • impose a versioning system moving forward
    • should we do an automated thing or do it ad-hoc?
      • simon: could we have a bootloader to maybe choose between norns 2.0 + 3.0?
    • maybe just try it within our group?
  • maiden: should we do a 3.0 catalog for scripts? so that 3.0 scripts and 2.0 scripts are collected, if a user hasn't yet updated...
  • promote reusable patterns (kernel separation, etc)
    • testsine is a blob, not the best way to use the class system
  • goal is that the adoption of existing SC code is smoother
    • promote clean architecture
    • don't want to force everything to be interpreted
    • ezra: came up with an engine that functions as a proxy — an engine factory
      • makes a clean global environment
      • anton: perhaps a bit ambitious and disruptive
      • anton: support both class-based and interpreted
        • worried about clashing class names
      • ezra: want to think about norns as something you mix in, rather than rebuilding an engine
  • greg: multi-engine spec is like lv2 metadata
    • so maybe we adopt that format?
    • ezra: it needs to be baked into the SC system tho, so the engine class can spit out that metadata
  • ezra: multi-engine isn't a compelling case personally
  • multi-threaded cairo was brought up, but unsure of impact

desktop

will 3.0 release with the desktop stuff?

  • decouple matron from hardware
  • can grab mouse and keyboard events, sure, but it could go deeper
    • opportunity to tailor an experience
    • simon: development environment

development

  • ezra: want a staging branch that isn't main
  • lua side of softcut
  • linux kernal or realtime kernel changes will have impact on audio
    • rv's changes...
    • affects linux scheduler — pulls it off three of the four cores
    • give supercollider and crone straight shots to the CPU
    • ezra: worried about the block size
    • brian: upper limit to how hard to push all four CPU's — jump thermals and pull current against battery. require external power.
    • set limits vs be constrained by them
  • no concerns about Buster...
  • urb issues

lib

  • goal: document the libraries better (docs + api)
  • libraries themselves are kinda inconsistent — syntax. review that before building docs.
  • coding style page isn't very valuable
    • make the style better documented
    • helps with sanity checks
  • expand library for common uses
    • can this be handled by docs? snippets.
    • first step would be fixing bizarre inconsistencies
  • elegant ways to persist
    • greg: JSON table for tabla
      • could send that to the web front-end
    • might be good to spend energy on saving the state of the system
    • automated docs
    • ezra: lua is a data format you can add intelligence to
  • what is a good library?
    • ezra: collection of random stuff. some need-based, some not architected for anything in particular

restart

  • restart commands — get rid of them in maiden, go for reset for a full-stack restart
    • ezra: it is still useful to restart SC alone, for developing engines, but don't use it for recovery / troubleshooting
    • brian: keep restart, add reset to do both
      • sam: resets system levels, tho. annoying.
    • greg: play button is lua-code — the only place where maiden knows about matron
    • brian: reset also needs to account for matron being in a dead state
      • reset should restart SC and matron services
    • ezra: there's a dynamic exchange of OSC at runtime — there's a state machine that keeps track of that process
      • would be cleaner to have all of that living in a file vs OSC

wrap-up (aspirational goal of 2 months):

  • softcut improvements
  • supercollider transition
  • new disk image with kernel improvements
  • menu repair + fixes
  • documentation
  • should we do a 3.0 catalog for scripts? so that 3.0 scripts and 2.0 scripts are collected, if a user hasn't yet updated...
  • ezra: debug poll issues

further down the road:

  • lv2 + new ways to think about supercollider
  • desktop environment
  • sky
  • tracker