next milestone planning (2.9.0 / 3.0.0)

[catfact]

landing the norns-converged branch seems like a good opportunity to plan additions for the next release / milestone. the changes will almost definitely involve a new base OS image. it would not be a bad time to consider breaking API changes as well.

we'e been sticking pretty closely to using major versions for breaking API changes only, but this change might be big enough to warrent using one whether it breaks APIs or not. (though, i'd lean towards calling it 2.9.0 if changes are mostly under the hood and aren't expected to greatly affect scripting / end user experience.)

regardless of whether the next version is 2.9.0 or 3.0.0, opening a discussion here mostly to collect candidate issues to target for inclusion. looking for relatively low-hanging opportunities that also imply adding things to the base OS image.

[catfact]

resample on softcut import, this still gets people after all these years
#1884

[catfact]

include sox in the image
#1791

[colinmcardell]

I would love to see SoX integration as something that's part of an extensible framework of offline processing and information retrieval operations. I could see it become a rather nice tool agnostic processing layer that ships with SoX as the first backend. I’m curious if anyone has thoughts on this proposal.

---

Verbs like convert, trim, fade, resample, normalize, etc. that are tool agnostic, stable, composable operations that benefit from consistent UX and developer experience, with things like progress, cancellation, normalized errors.

Additionally, tool level (SoX, etc.) details could be exposed allowing the backend to be called directly.

local ops = require 'ops'

-- verbs
ops.resample{ input=..., output=..., rate=48000 }

-- backend-specific
ops.tools.sox.run{ input=..., output=..., effects={...} }
ops.tools.<future_tool>.functionality{ ... }

Verbs would be opinionated and intentionally "incomplete", exposing generally useful functionality. Anything “advanced” would live in ops.tools.<backend>.

• Avoids hard-coding SoX assumptions into user-facing APIs
• Enables future expansion to other external tools (e.g. Composers Desktop Project (CDP), ffmpeg utilities) or in-process DSP
• The design could support safe, async, progress-aware processing jobs for Lua scripts
• Intended for offline / background processing (file-based), not real-time processing.
• Allows the functionality that comes from tools to be (re)implemented in other ways if targeting desktop, starting with a clear design separation from the start.

[Dewb]

In general I'm suspicious of premature abstraction in APIs, but I do think establishing a repeatable pattern for things like this would discourage people from using shell commands to access tools like sox/ffmpeg/etc. and redirect that energy into the enhancing the Lua API. So I like the direction!

[catfact]

for once, i might be able to carve out some rare time to tackle issues / test / review, depending on timeframe.

there are a number of not-quite-there PRs over the last few years that would be good to go over and see about reworking.

[catfact]

consider adding other scriptable synthesis/processing backends, like pd-vanilla or csound.

it's not hard to support things like this with hacks and workarounds, nor custom jack-client executables for that matter.

there have also been various proposals to make "external engines" more ergonomic to use; nothing has landed as a result of decision paralysis / lack of a motivating use case, rather than any technical limitation.

[tehn]

worth noting that more-sane jack management was added last year #1836 which is likely not well known or utilized.

decision paralysis is real, but i'm wondering how necessary it is to formalize parameter exchange, versus let people roll their own if it's going to happen via OSC.

i recall @ngwese started working on an interesting proposal for an lv2 interface. this seems like something that could lead to easily-distributable extensible dsp (that's not sc)

(seeing as how reverb/compresssor options are often requested)

also @catfact's favorite shaper/distortion collection!

[catfact]

There is a pretty full fledged interface for lv2 management and discovery, but nothing actually built on the audio side. If that were moved forward I think it would be a good idea to include a good collection of plugs on the image as well.

[catfact]

more-sane jack management was added last year #1836 which is likely not well known or utilized.

i looked at this and noticed that although there are FFI bindings in weaver, i don't think there are any lua bindings outside the "private" norns interface, and ofc it does not appear in API docs.

[catfact]

i'm wondering how necessary it is to formalize parameter exchange, versus let people roll their own if it's going to happen via OSC.

i'm not invested either way. the main thing i'm suggesting to consider is whether it might be better to include more musical programming environments in the base image, rather than having scripts try to install things. (same thought process as when considering something like sox or mpv or whatever people tend to want to install.) it really doesn't seem good for scripts to be doing package management so might be worth making it less tempting.

[Dewb]

agree, I think the system should start actively discouraging scripts from doing package management. Installing more useful things in the base image would help, also putting some more oomph behind the norns minimum version statement in scripts would help, so authors are steered towards using that instead of doing a “check and install if not found” to avoid errors on older systems.

on the other hand, if desktop support is an eventual goal we should probably be discouraging scripts from making any kind of shell calls.

[Dewb]

Yep, I think it would be great to simultaneously plan for a 2.9.0 as the first converged release and then a more significant 3.0 with changes to the image etc.

Github project boards, while not amazing, are a decent & hyperlocal way to track these sorts of things, I’ll throw one together and folks can evaluate whether it’s useful.

If we have to make API-breaking changes then 3.0 would be the time to do it, but I also think the project is mature enough that it might be good to avoid changes that break scripts (or at least provide a painless upgrade mechanism for when someone wants to run an obscure and unmaintained older script.) Writing up a document describing the intended compatibility model and expectations would be a good guide for future development.

[colinmcardell]

Would a "modernization" of the maiden stack be something that might be of interest for 2.9.0 or 3.0.0? I could see a few areas benefiting from some updating. An example would be CRA moved over to Vite. It would likely be helpful for future improvements.

[tehn]

@ngwese has mentioned some possible incremental improvements, though I see a major overhaul being a 3.0.0 candidate