I know this has been thought of, but just curious if anyone has any insight.
Everyone always asks for a native synthesizer in Renoise. Well, that would be cool, but once it has been made, people will start asking for different stuff: more oscillators, signal input, FM synthesis, waveshaping…
What if, instead, we could write our own? A software development kit (SDK) for compiling native DSPs, like Max/MSP has for external objects? Or perhaps a scriptable API for audio-rate processing, like REAPER has with JS (not Javascript, confusingly)? The user could write a custom synthesizer, reverb, vocoder, or anything else. Then it would either be compiled and loaded into Renoise (much like a VST), or loaded as a script (much like the JS plugins in REAPER) – that depends on how the SDK would work.
Custom DSPs could be shipped with the .xrns and would be platform-independent, just like current native DSPs. Maybe we could also export a standalone “.xrnd” containing just the DSP.
I’m sure the devs have heard this idea before, and they even mention in the Lua API docs that “you can not script realtime DSPs - yet”. So obviously the issue has been considered. Anyway, a general interface to DSP functions would let people make whatever they want, including a native synth, in the same way that .xrnx has allowed us to extend functionality and make macros to suit our own needs. I’m curious if something like this is planned.
Yeah, I know. Not exactly like lightbulbs are gonna go of in Taktik’s head suddenly. :>
Yep. But this would be distributable inside of the .xrns, unlike those. And, y’know, if I had the option to write one in Lua instead of C… (big grin, eyes widen)
Hot damn! Some other amazing software is also waiting for LuaJIT 2.0 to go stable, so I definitely have a stake in that…
Yeah! Because I can use mt Windows VST with… Oh yeah, just Windows!
Talk of possible real-time capable scripting in the future (read that as in not on the current todo list but has been considered) is what I’ve gathered from previous discussions on this board. I can believe you’re comment that the Devs are waiting for LUAJit, or other realtime LUA library (or complier or whatever the exact difference is,) before seriously considering its implementation makes perfect sense. Also the current API already is a lot for people to get their heads around, get updated as missing essentials are spotted and upgraded with Renoise that a note going all in at once was probably a good idea.
Here’s to hoping things may develop smoothly in this direction some time soon
