this is huge ty dan for the hard work! really looking forward to testing out the sampler capabilities once those modules are added in. also nice to see the vcv delay working in there; it has a unique sound imo
is there a rough timeline for the release of 2.0.0, or at least it moving to a beta/feature complete state?
its seems many (majority?) have started using 2.0 (dev) due to its feature set.
so the danger here, is that 2.0 is essentially defacto released, yet still considered a dev branch.
(I think the call from users for specific 2.0 plugins, shows its moved beyond ‘dev testing’ , at least in expectation - imo)
I ask, as im still interested in developing modules for 2.0, but dont really want to start down that route until its stabilised/released.
at the end of the day, 2.0 is not the end game (hopefully), so doesn’t have to be feature complete… things can still come in 2.1/3.0 or whatever
anyway, I guess, the question is … whats the plan? where does 2.0 end?
Good question, and it’s something I have to remind myself of constantly.
The 2.0 features involve an API breakage, so that’s how I’m determining whether something goes in 2.0 or later. Basically, if it requires a non-backwards compatible change then I’m trying to get that into v2.0.
The reason is that one of the main goals of v2.0 is a stable API for plugin developers. Another related goal is to support most/all of the Rack API (if not in terms of functionality, then at least in terms of API compatibility – for instance polyphony may not work on MM, but the API for it works without crashing)
And, well, to be totally honest, there are some v2.0 features I’ve added that didn’t involve an API breakage but they were things I promised long ago and had to make good on! And others features I originally thought would cause an API break but ended up being done in a way that was backwards compatible. But all these things are already merged in.
So, the remaining road map:
Merge the current Rack SDK headers into the metamodule-rack-interface and update the implementation in firmware. This is a long boring job that will add no features or optimizations – but it will mean we can add support for more Rack features to v2.x releases without needing to force everyone to move to a v3.x
MIDI Output API – The framework is here, but I need to make a test implementation to make sure it’s all good before declaring it stable.
I was hoping to get support for c++ exceptions and streams for plugins, but I’m willing to put that off till v3.0 in order to not hold up 2.0. I’m going to give it one more shot, though!
Then in v2.x, we’ll see more flushed out MIDI features, an implementation for bypassing, loading/saving User Presets, GUI stuff like Performance/Edit mode, etc…
Update on this:
MIDI Output is working, and the Rack SDK headers are merged in.
I’m implementing the API for native modules graphics now (which I guess left off the list above?).
I gave the latest dev firmware a go last night and got some very odd behavior. Simple patch with a couple of panners, band pass filters and attenuverters. And what I got out left me wondering if I had lost my mind. Delay effect with distortion and a long decay… huh? Checked my work, and it definitely was NOT giving me what I expected, and not a sound that could have come from my patch. I rolled with it because it was a cool sound but the most accidental of happy accidents. I suspect that even though it was showing the correct modules in the UX, it was running other modules. Could that be the case?
