using external process for audio engine

[catfact]

i often run other JACK clients on norns, but have never actually tried plumbing one into norns lua and using it like a normal engine.

finally decided to give this a go and see what kind of issues it raises:
https://github.com/catfact/ztsingou/

as might be expected, it's fiddly and risky and opens a can of all kinds of worms when it comes to the idea of distributing scripts with this kind of component. lots of ways things can go wrong.

anyway i have more thoughts and i'm sure others do to, this seems like a good place to hold any discussions about the technical risk and whether this is a reasonable thing to encourage / support.

[tehn]

provided you're able to do this without a norns core modification, it seems we already "support" it?

so the question is whether we encourage it. i definitely think it's an interesting proposition, and of course if someone is confident with hacking their system they absolutely should.

likewise, if someone wants to help others make something complex work, they're free to share it, i guess. at least, this feels like the level we've been operating at.

assessing the security risk is another matter. but i'm not sure this (including binaries) is any more problematic than other things that are currently allowed (unfettered os.execute)

[catfact]

i guess what i'm wondering is whether its worth supporting this and/or adjacent use cases more directly. for example:

• on one side, introducing things like engine.exe = 'ztsingou', engine.port = 9998, have norns lua handle lifecycle management and init sequence, reducing scope for error
• on the other side, providing things like FAUST architecture files and C/C++ project templates, reducing scope for error

the main "adjacent" use case being when the executable is installed elsewhere. for example it is possible to run max patches via RNBO, but RNBO wants to run as a systemd service.

pros and cons:

• self-contained exe in script repo, launched and stopped from lua:
  • pro: nothing to install
  • con: fiddly lifecycle management

and the reverse for using services instead.

and overall i wanted to take another temp check on this sort of thing in general. my example is perhaps not very compelling. but i could have spent another day on it and made, say, a wrapper for minidexed or some other popular tool.

this constellation of questions has been kicking around for quite some time and certainly touches on questions in "dependency management" discussion / PRs. so i thought it would be good to try and locate the discussion here, not just on forum/discord.

totally fine if the answer is, "let's not worry about addressing any of these things in norns core."

[tehn]

ah, i see what you're getting at. i do like engine.exe = 'etc' scaffolding and an example project. providing a route to non-supercollider DSP integration has been something we've all talked about for awhile, so this is one option--- a particularly non-integrative option at that compared to our earlier proposals of swapping out the reverb/comp etc (basically making a plugin environment)