-
Notifications
You must be signed in to change notification settings - Fork 149
201231: meeting notes
- simon
- brian
- artem
- anton
- greg
- phil
- tyler
- dan
- 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.
- brian: we maybe don't need so many UI widgets if we can train users to use simple commands (
- 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
- 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!
- 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
-
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 forsleep
-
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
- 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
- simon: we can use
-
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
-
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?
- short term: next update ETA, options for inclusion
- long term: goals (briefly, topics to be discussed below/afterwards)
monome.org