monome / dust Goto Github PK

meta-issue tracking work around generating docs.

stuff to consider:

• lua script docs
  • script tagging (require grid/midi, etc) #104
  • embedded long-form docs #100
• sc engine docs
  • how might scdoc and schelp fit in?
• documentation for writing docs (script, module and engine)

also related:

• maiden doc integration (monome/maiden#91)

I suggest to put the script specific controlspecs used in kayan (EDIT: and other scripts) in a script specific table rather than the core ControlSpec table.

Ie. see this line:

I've not tested this in practice but am quite sure that line changes the standard ControlSpec.AMP for any script using that default controlspec loaded after kayan.

likely needed by various scripts in the future: simple folder-selection script.

parameters: root folder, file type

returns filename or -1 (cancel)

redirects redraw, enc and key for the length of selection, returns control to original state.

Loading the script in scripts/emb/loops.lua puts the device in a state where the OLED says "no parameters" and what sounds like a somewhat short buffer size that is looping whatever sound is coming in the input. The first key does not exit menu mode.

It looks like the script is asking for key 2 to control starting and stopping a metronome.

The the failure is kind of interesting since it produces somewhat pleasant noise based on most inputs, though the controls make this script appear as if the device is broken.

Running dust from release 181101. Not tracking master branch in git.

After a combination of actions I can't reproduce (ran a couple of scripts, had grid plugged in, then plugged in USB MIDI device) I get the following errors continuously scrolling in the maiden's repl:

lua: attempt to call a nil value
stack traceback:

Occasionally when unplugging from USB I get:

dev_delete(): removing device 2
lua:
/home/we/dust/scripts/tehn/earthsea.lua:164: attempt to index a nil value (global 'pat')
stack traceback:
/home/we/dust/scripts/tehn/earthsea.lua:164: in function 'gridkey'
/home/we/norns/lua/grid.lua:119: in function </home/we/norns/lua/grid.lua:115>

MIDI input isn't working for these scripts when this happens. It is working for jah/hello_ack.

Any idea what could be causing it?

dust is open source (I can see the code) but what are the conditions of contribution and its use and redistribution?

It would be beneficial to include a LICENSE file in the repo. For one thing, it would allow me to contribute to dust (I need to clear open source contributions with my employer, and they want to know the terms of those contributions).

I suggest something simple and permissive but protective like the Apache 2.0 license.

After the 1.0.4 update, selecting the jah/hello_gong.lua script results in a OLED screen lockup but not a kernel crash. Connecting via SSH shows that supernova began consuming 100% CPU time of all 4 threads. The crone systemd logs report many xruns after loading. I suspect jackd kicked out supernova for not being able to keep up with the callback timing.

we@norns:~/dust $ journalctl -u norns-crone
Oct 08 05:40:15 norns ws-wrapper[4084]: a CroneAudioContext
Oct 08 05:40:15 norns ws-wrapper[4084]: [ CroneEngine adding command, hz, f, a Function ]
Oct 08 05:40:15 norns ws-wrapper[4084]: [ CroneEngine adding command, amp, f, a Function ]
Oct 08 05:40:15 norns ws-wrapper[4084]: [ CroneEngine adding command, decay, f, a Function ]
Oct 08 05:40:15 norns ws-wrapper[4084]: [ CroneEngine adding command, coef, f, a Function ]
Oct 08 05:40:15 norns ws-wrapper[4084]: [ CroneEngine adding command, lpf_freq, f, a Function ]
Oct 08 05:40:15 norns ws-wrapper[4084]: [ CroneEngine adding command, lpf_gain, f, a Function ]
Oct 08 05:40:15 norns ws-wrapper[4084]: [ CroneEngine adding command, bpf_freq, f, a Function ]
Oct 08 05:40:15 norns ws-wrapper[4084]: [ CroneEngine adding command, bpf_res, f, a Function ]
Oct 08 05:40:15 norns ws-wrapper[4084]: -----------------------
Oct 08 05:40:15 norns ws-wrapper[4084]: -- crone: done loading engine, starting reports
Oct 08 05:40:15 norns ws-wrapper[4084]: --------
Oct 08 05:40:15 norns ws-wrapper[4084]: engine: an Engine_KarplusRings
Oct 08 05:40:15 norns ws-wrapper[4084]: command entry: [ 0, hz, f ]
Oct 08 05:40:15 norns ws-wrapper[4084]: command entry: [ 1, amp, f ]
Oct 08 05:40:15 norns ws-wrapper[4084]: command entry: [ 2, decay, f ]
Oct 08 05:40:15 norns ws-wrapper[4084]: command entry: [ 3, coef, f ]
Oct 08 05:40:15 norns ws-wrapper[4084]: command entry: [ 4, lpf_freq, f ]
Oct 08 05:40:15 norns ws-wrapper[4084]: command entry: [ 5, lpf_gain, f ]
Oct 08 05:40:15 norns ws-wrapper[4084]: command entry: [ 6, bpf_freq, f ]
Oct 08 05:40:15 norns ws-wrapper[4084]: command entry: [ 7, bpf_res, f ]
Oct 08 05:40:15 norns ws-wrapper[4084]: cpu_peak
Oct 08 05:40:15 norns ws-wrapper[4084]: cpu_avg
Oct 08 05:40:15 norns ws-wrapper[4084]: amp_in_l
Oct 08 05:40:15 norns ws-wrapper[4084]: amp_in_r
Oct 08 05:40:15 norns ws-wrapper[4084]: amp_out_l
Oct 08 05:40:15 norns ws-wrapper[4084]: amp_out_r
Oct 08 05:40:15 norns ws-wrapper[4084]: pitch_in_l
Oct 08 05:40:15 norns ws-wrapper[4084]: pitch_in_r
Oct 08 05:40:15 norns ws-wrapper[4084]: tape_rec_dur
Oct 08 05:40:15 norns ws-wrapper[4084]: tape_play_pos
Oct 08 05:40:15 norns ws-wrapper[4084]: free engine: an Engine_KarplusRings
Oct 08 05:40:15 norns ws-wrapper[4084]: CroneEngine.free
Oct 08 05:40:15 norns ws-wrapper[4084]: a CroneAudioContext
Oct 08 05:40:15 norns ws-wrapper[4084]: type: polyphonicReuseSynths
Oct 08 05:40:15 norns ws-wrapper[4084]: inControlName: nil
Oct 08 05:40:15 norns ws-wrapper[4084]: outControlName: out
Oct 08 05:41:15 norns ws-wrapper[4084]: controlsToExposeAsCommands: ControlName  P 3 timbre control 1.0, ControlName  P 4 timemod control 1
Oct 08 05:41:15 norns ws-wrapper[4084]: ntrol 0.5, ControlName  P 49 envrelease control 400.0, ControlName  P 50 envcurve control -4.0, Con
Oct 08 05:41:15 norns ws-wrapper[4084]: autorouteInputs: nil
Oct 08 05:41:15 norns ws-wrapper[4084]: autorouteOutputs: [ out, Bus(audio, 6, 2, localhost) ]
Oct 08 05:41:15 norns ws-wrapper[4084]: autorouteAmp: [ out, Bus(audio, 6, 2, localhost) ]
Oct 08 05:41:15 norns ws-wrapper[4084]: autoroutePitch: [ out, Bus(audio, 6, 2, localhost) ]
Oct 08 05:41:15 norns ws-wrapper[4084]: type: polyphonicReuseSynths
Oct 08 05:41:15 norns ws-wrapper[4084]: [ CroneEngine adding command, gate, ii, a Function ]
Oct 08 05:41:15 norns ws-wrapper[4084]: [ CroneEngine adding command, on, i, a Function ]
Oct 08 05:41:15 norns ws-wrapper[4084]: [ CroneEngine adding command, off, i, a Function ]
Oct 08 05:41:15 norns ws-wrapper[4084]: [ CroneEngine adding command, noteOn, if, a Function ]
Oct 08 05:41:15 norns ws-wrapper[4084]: [ CroneEngine adding command, freqOn, if, a Function ]
Oct 08 05:41:15 norns ws-wrapper[4084]: [ CroneEngine adding command, polyphony, i, a Function ]
Oct 08 05:41:15 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:15 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:15 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:15 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:15 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:15 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:16 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:16 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:16 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:16 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:16 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:16 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:16 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:16 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:16 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:16 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:16 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:16 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:16 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:17 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:17 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:17 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:17 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:17 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:17 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:17 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:17 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:17 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:17 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:17 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock
Oct 08 05:41:17 norns ws-wrapper[4084]: nova::dsp_queue_interpreter::run_item: possible lookup detected in dsp helper thread
Oct 08 05:41:17 norns ws-wrapper[4084]: Jack: xrun detected - resyncing clock

To get the device to function again (all keys and encoders are also not responsive) I did a reboot via a shell over SSH.

this refers to "some sort of micro-enveloping at the loop points to de-click the loop transition". my thinking is a cos based window akin to http://msp.ucsd.edu/techniques/latest/book-html/node36.html .

this requires refactoring of the trigger based sample start/end/loop point logic.

alternatively, implement some kind of crossfade. or add both micro-envelope windowing and crossfading.

also found this by fellow lines member: http://sccode.org/1-51A

I just did a sync from Norns onto a usb flash drive. I went to this repo and noticed some updates to a few of the supplied scripts, so I went to check out fetching and pulling in latest master to get those. Currently, it seems like a lot of the supplied files are not under source control, so the pull would not be clean:

My thinking is that making sure stuff that we want under source control to be tracked (and things that we don't to be ignored) would fix this. It would allow users to manually pull and stay up to date with master (as opposed to waiting for releases). I think that having a more definitive release-cycle makes a lot of since for norns' firmware (with QA, beta, etc.), but less so for the type of stuff that dust holds.

these lines handle midi the old way before the mid level api was put in place. this script should be updated to use the public api as demonstrated in in earthsea

problem code:
https://github.com/monome/dust/blob/master/scripts/jah/hello_gong.lua#L166-L212

/cc @antonhornquist, @artfwo

symptom: polls phase_n and phase_norm_n always return 0. other polls working so the lua syntax seems corret

seems the polls are implemented:

https://github.com/tehn/dust/blob/master/sc/Engine_SoftCut.sc#L157

but i can't see where the phase_b busses actually get created?

https://github.com/tehn/dust/blob/master/sc/Engine_SoftCut.sc#L94

@catfact maybe i'm missing something? i would have expected sc to throw an error message like "phase_b not found"

i'd like to sustain notes with ack.

maybe with a new argument to the SynthDef:

playbackMode = 0 // 0 for one-shot, 1 for ADSR

so that existing scripts would not have to change.

when set to 1 for ADSR, it would enable more arguments for the envelope:

volumeEnvDecay = 0.3
volumeEnvSustainLevel = 0.5
volumeEnvPeakLevel = 1

and maybe even

volumeEnvCurve = -4
volumeEnvBias = 0

when gate is 0, the envelope begins to close.

i have a prototype of this working for the Engine_Ack SynthDefs, and could submit a PR.

is there any interest in this feature for ack? or should it be part of a new engine?

• sample select
• one-shot (trig)
• loop points
• playback speed (w/ reverse)
• gain
• volume envelope (# points? at least AR)
• filter cutoff, res, mode
• filter cutoff envelope

8 channels is fine as a default. each index has each of the above params

ie

e.trig(n) where n is the index, triggers envelopes and loop start
e.speed(n,-1.0) where n is index, -1.0 is reverse 1x

envelopes and loop points in ms is fine? number of points for envelope? (can this be variable/dynamic?)

bonus points:

• slew time for speed, volume, cutoff, res
• shaper/overdrive per voice
• loop windowing toggle
• aux send master delay, aux send to master reverb

up for suggestions on the engine name, "ack" just references the early akai sampler inspiration

What's the intention of the dust repository? Is it for everyone? Just the people at monome? Is there a bar for inclusion.

Put another way, if I start building norns things, would I send a pull request to add them to scripts/nf in this repository?

It would be good to make this clear in the README.

lib for extended drawing functions (non-cairo-native)

a start from tyler: https://gist.github.com/tehn/2bd6862d2eb323978ee9f6648b6102eb

one for each voice, based on Sweep-based playhead would be great to have for playback position visualization in the ui

https://github.com/tehn/dust/blob/master/lua/poly.lua#L169

we've got Midi.event (midi.event) for that.

shaper/overdrive per voice

i've not done a lot of overdriving in sc, if anyone has suggestions on good-soudning overdrive let me know.

tl;dr overlapping frequencies cause audible distortion. it'd be cool if things were tuned to make that better!

from @tehn:

we need a sort of tagging system. ie, scripts that only use input, or require a grid, or a grid is optional, or require midi input, etc. almost like a bunch of fields that have required/optional/no (where no is the default)

rather than having script docs split into two places:

• scripts/<author>/<script>.lua (for the menu docs)
• docs/<author>/script/index.md (for the long form ones)

we might consider pulling the long-form script docs into the script source itself and parsing it out with a custom ldoc filter.

while we're at it, we could define and process some custom tags to do things like build app indexes. things we might want to index include:

• grid-requiring apps
• midi-supporting apps
• arc-friendly ones
• utilities
• samples and studies
• templates
• experiments?

@tehn: i think you had other ideas?

thinking specifically about polysub with its wealth of params.

a simple editor patch where MIDI/grid triggers notes (like POLY), but the screen/key/enc interface are all graphical and intuitive for designing synth patches which could then be "exported" as pset files. (see https://github.com/catfact/norns/issues/344).

these "synth" psets could then be used by other scripts ie earthsea. the earthsea script pset could reference the synth pset, so you could use a file-loader to select the synth pset from a collection.

and then this could apply to other synths/engines as well.

it's read here:

https://github.com/tehn/dust/blob/1b688ea3a89e7368c56a76f49d9347526857abb0/scripts/tehn/awake.lua#L122

but there's none checked into data/

/cc @tehn

At the moment the dust repo is still structured for 1.0

Could 1.0 be pushed to a separate branch and 2.0 structure added for ease of pulling that directory structure (for building on RasPi)?

slew time for speed, volume, cutoff, res

I've been able to replicate this 100% of the time, but I don't understand why its problematic with foulplay and not playfair since they're using the same audio engine.

Load any wav file from any folder and all is well.

Load an aif from /audio/tape and the audio engine locks and cannot recover. Norns has to be restarted.

If I'm the only one who can reproduce this I'll do some more digging locally, but it seems to happen every single time on my norns with the lastest update 180707

Outside of MLR, direct application of engine.rate(i,f) causes severe playback glitching if f values are less than 0. Application of positive f values behaves as desired.

Steps to replicate:

1. load @tehn 's halfsecond.lua through Maiden
2. toggle HOLD on norns to freeze the buffer at 1x
3. execute engine.rate(1,-1) -> playback glitches
4. execute engine.rate(1,1)-> eventually, playback re-stabilizes

I'm unsure if there's a condition unique to halfsecond.lua that causes this (vs MLR), but I have also replicated in other WIP SoftCut scripts.

the mlr.lua script should be assigning all voices to record from inputs 1+2. but reports are that voices 1, 3 only get input 1, voices 2,4 get input 2.

that's the default configuration for the engine patch matrix, so this is probably a stupid error in the patching command setup (or possibly a regression from when i changed patch matrix to pause processing on unconnected routes.)

Both awake and rebound use near-identical code for scale/mode selection. It would be nice to unify this into a library that can be used by any norns script. The library could also provide various utilities for expressing notes, scales, and chords as strings, midi notes, and frequencies (and converting between them).

Does this sound desirable? I already have a WIP of this on my norns that just needs to be tidied up.