|
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107 |
- # Carla TODO
-
- # ----------------------------------------------------------------------------
- # in short
-
- 1. move backend from Qt to Juce (80% done)
- 2. move frontend from PyQt4 to PyQt5, rewrite to share widget code (60% done)
- 3. allow to use old Qt code (except graphics) for non-Juce-supported OSes (BSD, Haiku, Solaris, etc)
- 4. custom "plugin slots" skins, ala Reaper (also define set of keys for a new LV2 extension)
- 5. internal patchbay processing mode (needs #1)
- 6. Carla as an LV2 plugin (needs #5)
- 7. direct support for csound files (as plugins, inspired by 'cabbage')
- 8. OSX builds (needs #1 and #2)
-
- Ideas for later:
-
- 9. Carla as VST plugin (will have to be a custom UI)
- 10. easier canvas connections by using smart key shortcuts
- 11. Mobile version (using Android Patchfield for example)
- 12. Mobile OSC Control app
- 13. Port good JACK-only apps as internal plugins (zita stuff would be nice)
-
- # ----------------------------------------------------------------------------
- # more detailed
-
- GENERAL:
- - finalize Juce backend move
- - finalize PyQt5 move
- - add back old Qt code for when Juce is not available (or disabled by user)
- - add direct program access on ui-dialogs (needed for standalone bridges), maybe add extra buttons too (reset plugin, fix ui size)
- - implement midi-learn (new dialog)
- - custom skins for plugin slots, design for 8 types + instruments (gig, sf2, sfz)
- - custom skins for internal plugins
- - implement favorite plugins, add in new tab near file-browser
- - blender style canvas theme
- - make it possible to run forced (and only) rack or patchbay mode
- - make it possible to use backend as fake standalone app (using pipes) instead of a shared library
- - create startup scripts for carla-rack, carla-patchbay, carla-settings, etc
- - smarter carla-single script (LV2 must only need URI for example, and ignore all other hints)
- - alternate, simpler UI for mobile and/or VST version
-
- ENGINE:
- - allow to change position of plugins (up/down)
- - allow to add plugins when engine is stopped
- - save&restore canvas connections (optional, must not be used under SM)
- - complete RtAudio+RtMidi support (only MIDI out missing + save&restore)
- - complete Juce engine driver support
- - implement Haiku Media support (based from JACK?, LATER)
- - implement latency in continuous-rack mode
- - implement internal patchbay mode (once Juce move is complete)
- - engine as internal plugin
- - internal patchbay mode, based on Juce graph code
- - handle sample-rate changes in JACK (made possible by switch-master)
- - add MIDI-bank change type (GM, GS, XG and MMA). See fluidsynth docs
- - allow to use static OSC ports
-
- PLUGINS:
- - add control-out rate/freq option in frames (or just a regular block-size option?)
- - control/midi-out in singleProcess() calls, use timeoutFrames var
- - implement midi-cc automation special rules (invert, half, logarithmic, etc)
- - implement Juce plugin hosting (provides AU and VST2/3 support; will replace current VST hosting if Juce is used)
- - implement LSCP file support (new native plugin)
- - implement Csound file support
-
- Native:
- - Cleanup API
- - Document API
-
- LADSPA:
-
- DSSI:
- - custom chunk-data extension, publish on kx website when complete
-
- LV2:
- - complete lv2-worker support
- - handle in-process graphics via Juce
- - no in-process UI support if juce disabled
- - revisit all extensions
- - option to set lv2 preset folder
- - only load LV2 bundles on request, never load full LV2 world
-
- VST: (non-Juce build)
- - no UI support
- - simplify code (because of no Juce)
-
- FluidSynth:
- - per-channel volume control
- - proper buffer-size/sample-rate change
-
- LinuxSampler:
- - multi-program
- - 16outs (depends on multi-program)
- - proper buffer-size/sample-rate change
-
- # ----------------------------------------------------------------------------
- # current work
-
- BACKEND:
- - cleanup API, document everything properly (tested with doxygen)
- - apply API docs to python code as well (TODO: use proper predefined pydoc style)
-
- FRONTEND:
- - fix things to new cleanup API
- - share code as much as possible
-
- OTHER:
- - create tests for all utils code
|