-
Notifications
You must be signed in to change notification settings - Fork 32
Roadmap
This is the current state of Dplug's priorities as seen by Dplug contributors. If you want to influence the content of the roadmap please think of a way to contribute.
Note that product roadmap sometimes takes priority for Dplug contributors. There is no firm guarantee every listed item will get worked on. It is open source, you can work on it too.
Basically our weakness is lack of extensive support for higher channel count and buses and sidechain. But also that it's not really easy to make complicated UI with the existing layout system, which is not compositional.
- MIDI output for AUv2 (if/when SMAOLAB decides to do a drum machine)
- Remaining macOS crashes. I think this needs to be "Dplug-winter"-breaking since this can be heavily disrupting to the bottom-line.
- ability to use redub in dplug-build
- Easier Faust integration. dplug-build support .dsp, parameter updates, perhaps UI
- Port of canvas_ity, for another canvas API tat can do more but more slowly
- CLAP, since it will be in JUCE and FLStudio it changes everything
- Need to improve compat: AUv3 and/or Windows arm64
-
[ ] Buses, channel layouts and sidechain. Can we have a transition path for a better dplug:client?POSTPONED -
[ ] I'd like to adopt the layout model of Flutter.POSTPONEDreflow
semantics would be a bit different. This needs not to break anything.
It's time to pay our debt? I think that beyond those items, the general focus should be on fixing the architecture: audio buffers, audio processors, state variables saved into chunks (possible this year), buses (hard, could be progressive transition though). Memory safety was always just nice to have but it's entirely possible to design to have more of it, @safe
and @trusted
are not that hard.
Retrospective: We didn't finish all items. Good Architecture takes a whole lot of time and doesn't really benefit Dplug users in short time frames, so it needs to be very long term instead of costing this much. Buses needs to be possible. Managed to put FL plugin format in, a new format takes about 3 weeks.
-
MIDI output for AUv2=> post-poned in case it's useful -
Live + resize + macOS crash (#754)=> done early January -
DPI support in Windows NSIS installer
-
VST3 MIDI CCv14.0.3 -
Finish futureBinState ("State Stage 1") in LV2 (and for VSTHost/Orion in VST2)v14.0.2 -
Issue #687, rsrc => was fixed on Apple side
-
FL Studio format supportv14.1.1 - DPI support macOS => wasn't done, and not sure why no one asked for that for Auburn
-
work towards=> no time for thisIOStream
(needed for AudioBuffer) -
putting whatever you want in a chunk=> https://github.com/AuburnSounds/Dplug/issues/352 -
QOIX support -
Enhanced PBR rotating knobs (UIImageKnob)
Retrospective: We didn't finish all items at all, but the early year had very significant changes like Wren coming in, more people using Dplug than ever, and many small stuff. Platform support increased thanks to AAX UB, Rosetta-less installers, DLL signing, cloud signing. Resize is still not finished (Live + macOS resize crash), this is super hard. We also got better graphics, like the resize quality. Created an image codec for future PBR knobs and improve load speed, but JPEG still king for most details. The Windows installer not having DPI support is annoying, and a bit ugly. Also, Dplug now has its own Discord server to separate from the busy D server, the Wasteland was created (governance + code sharing), the Tutorial series now has 13 entries. End of year is on quality target with open issues being 1/10 of closed issues.
-
macOS Ventura => waiting for Ventura to be released=> OK -
sign Windows DLL (antivirus annoys users of D software) -
macOS installer shoulnd't need Rosetta installed -
support AAX arm64 => waiting for pro tools M1 to exist in the first place => now they do => #704 -
understand why LDC 1.30 regress in speed=> #703 -
Support cloud signing on Windows=> #712 -
Dplug v13=> #681 -
Fix REAPER resize on macOS=> #708
-
finish fixing Wren + arm64=> #711, #669
-
separate image library from Dplug =>gamut
Long-term strategy Dplug would need:
- a WebASM compatible runtime
- a good color abstraction
- a good font abstraction
- a good audio buffers abstraction
- a good abstraction for VFS
- a good abstraction for I/O
a fixed Vec (memory usage)- a good abstraction for an audio processor