[WIP] new crone, standalone jack client

[catfact]

norns/crone contains a new jack client designed to replace some of the Crone supercollider components.

it has 4 inputs and 2 outputs. the idea is that the first pair of inputs are to be connected to system capture ports, 2nd pair is connected to supercollider playback, and outputs are connected to system playback.

crone will perform mixing and routing, host "built-in" effects and the softcut engine.

this is WIP:

• currently, there is only basic routing: ADC mix to monitor bus, bus to DAC, ext input to DAC.
• the IPC layer is still liblo and OSC messages, which is overkill.
• none of the necessary changes to supercollider classes have been made.

will make some roadmap issues and update this PR accordingly.

but for now:

• the very first step is for people to try building and running this project on the norns (requirements: cmake, libboost-dev, libjack-dev)

• i will be stitching fx and softcut into here shortly

• norns/sc/core needs to be updated; engines can send directly to jack client output ports.

• need to programmatically connect jack clients supernova -> crone (and disconnect supernova->system)

• as an interim measure, we could make an OSC bridge in sclang for routing/level commands; or, go straight to making changes in matron/oracle.

[catfact]

(PS: sorry about the duplicate commits. this branch has been rebased and GH gets confused. they will turn into merge commits, or of course can redo this when/if time time to merge.)

[tehn]

imp!!! 😸

[tehn]

read through the whole thing, looks great and very insightful/educational!

do you want to keep softcut as a git submodule?

moving on to testing now.

[catfact]

i was just gonna roll it into the main repo under this project, already added the sources here...

[catfact]

@tehn i've gone ahead and merged this set of changes even though its incomplete:

• it feels backwards to be building an OSC glue wrapper engine in sclang (esp. since i coudn;t get it working right away for some reason)

• so, started just adding glue directly to oracle. so far just done most of the levels/routing commands. not fx or softcut parameters. but i put the needed data in the comments, it is just a few editor macros away, too late at night now to continue.

• hm also this highlights a few issues and decisions made in the jack client that are kinda 'weird' (e.g. decision to explicitly reference fx algo and param names in the OSC paths) and also some ways in which new mix structure differs from old, for better or worse (e.g. ADC channels now considered as stereo pair; aux send comes after monitor mix instead of before)

but anyways i wonder if you think it's too tricky to have to refactor the lua scripts using softcut right now. (mlr, cranes,... anything else?) if we can do that i think it would be good to just go matron->crone directly. not least b/c it is then easy for a lua script to load a scsynth engine and also use softcut.

[tehn]

softcut is priority. mlr can be completely redesigned/redone, and i'll help dan derks fix crane (or do it for him) regarding any changes... so please do not be concerned with lua script compatibility.

agreed that softcut should be persistent and not involved in engine-space, almost like an extension to the audio parameters. i'm pretty sure this is what you're thinking already.

do you have an idea how to implement the softcut polls since they'll be always available? just have callback similar to norns.vu? vs. using the dynamic poll system etc.

[catfact]

do you have an idea how to implement the softcut polls since they'll be always available? just have callback similar to norns.vu? vs. using the dynamic poll system etc.

yes, either that or take the opportunity to make an experiment using posix shared memory. (for levels and buffer waveform thumbnails.)

[catfact]

oh but you're talking about the lua interface huh. will probably end up still providing a way to enable/disable phase and loop polls (whatever the IPC interface happens to be,) because there will be some measurable performance impact from computing these on the backend.

IOW, they will look like the pitch polls as far as lua is concerned.

[catfact]

BTW, i did get perf set up and ran some samples. nothing too unexpected:

• 32% of softcut work is spent in poke(). 9% in peek(). interpolation is the heaviest subroutine in both; in poke there is large contribution from fade-table lookup. actually i'm not so sure now. will come back to this.

• feedback/input matrix mix is surprisingly huge at 12%. i suspect denormals are contributing strongly, and will try crafting an appropriate gremlin-zapper for ARM. might also disable processing on mix paths that are non-audible.

[catfact]

added barebones Tape class. record is implemented, seems to work fine. playback isn't implemented yet but should be straightforward. (stubs in Tape.h if anyone is feeling venturesome.) Tape is a template class accepting channel count, so easy to implement options for multichannel.

[tehn]

thank you for the individual commits--- it makes following how this works way easier

[catfact]

let me know if there's anything i can explain or document better right now.

as it stands, probably the most significant thing is just the OSC interface. all methods that the crone process accepts are printed on launch, and collected in crone/osc-methods.txt. (which is manually updated with crone output, so it may be stale at any given point if i've forgotten to do so.)

[catfact]

currently i'm adding some basic buffer/soundfile management for softcut.

[tehn]

i can jump one this if you want? (lua glue...)

[catfact]

sure. seems a sensible division of labor if i make changes to oracle.h/c and stop there?

if we're going to actively collaborate on this branch it would probably make sense to close this PR and make a new feature branch in the upstream repo, instead of on my fork. (not technically required, since i enabled maintainer access for this branch, but maybe more convenient.)

[tehn]

it does seem like a good division. i'll handle weaver implementation then.

agreed that a merge to monome/new-crone would be nice as i tend to work on many different norns hardwares with different git setups :/

[catfact]

closed this and opened #660