I thought it might be nice to keep people updated on Rack v1 development, so you don’t need to interpret technical commit messages from the v1 branch on GitHub. Feel free to ask any questions for clarification of each task, and remember to subscribe to this thread.
You can now subclass
ParamQuantity and use it with
ParamInfo::config<...>(...) to display more general labels in tooltips. Without using a custom
ParamQuantity subclass, you are still able to set labels, units, exponential/linear scaling, and multipliers for display values.
Undo/redo history is implemented with Ctrl-Z / Ctrl-Shift-Z key commands. This requires implementing a
history::Action subclass for every type of modification to the patch state. Currently about 50% of the required actions are implemented. Plugins may implement their own history actions if their state is modified in ways other than moving parameters, e.g. if a setting is selected from its context menu.
Cool! Is there a limit to the number of history steps that can be undone?
Currently it’s infinite because no actions require significant memory. Most are on the order of 10 bytes.
I’m aware that I’ll have to rewrite my Module Browser, at least because the tags are stored differently. But I’ve made a note to make sure that I correctly add
history::Actions as appropriate.
do you map these kinds of things to command-Z on the mac? Just starting to do some keyboard stuff and wondering if Rack follows the mac conventions.
Yes. Cmd is the “Ctrl” of Macs.
Yay! Big times coming, thanks Andrew!
GLWidget for drawing OpenGL 2 code to a
FramebufferWidget, either every frame or when marked
dirty. Honestly not sure what this could be used for, but plugin developers are creative.
very welcomed addition!
WOW!!! going to 3D !
Inspired by the TouchDesigner mention I thought that it would be cool to have a ShaderToy-like thing that could react to a frame’s worth of audio samples. That should be possible with this.
Rack uses OpenGL 2.0, so depending on the user’s graphics driver, your code either won’t render (you’d better include error checking), will work because the driver is actually OpenGL 3.0+, or will work because the driver is OpenGL 2.0 but supports the required shader extensions. Worth a try to see what obstacles you run into.
Polyphonic cables seem interesting although I’m worried for what’s going to happen with them UX-wise. I foresee having to make various splitter/joiner modules and probably some kind of visual sigil for modules to subtly say “hey, this is a stereo port” or “this is an 8-channel port.”
The v1 branch fully supports polyphony now, but there aren’t enough interesting modules that support it yet for an interesting screenshot and announcement. Will do this later after improving performance of Fundamental VCO and VCF.
Will Rack v1 have the capability to see know movements via MIDI? I’m not sure what that involves, but it would be kind of kewl to have knob positions in rack reflect the knob positions on our hardware controllers visually.
Yes. Parameters in Rack will move according to the MIDI input device’s parameter position.