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::Action
s 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!
Added 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 !
Woohoo!
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.
After multiple days of refactoring app/*
widgets, I now consider them “modernized” enough to move on, and I believe all undo history actions are now implemented. Until the release, testers may discover crashes or missed history actions, so post an issue if this happens to you in the v1 branch.
Added module bypassing, by context menu or Ctrl/Cmd-E.
This was actually added a couple weeks ago, right before I started this “blog”, so I’m mentioning it now.
Does this have passthrough (ex. bypassing signal → LPF → signal just copies non-filtered audio) or shush the module entirely?
This is a standard case. Signal will be passed to the next module in the row without any effects by module in bypassed state.
I have another question, @Vortico. Maybe in the future you will be able to add the ability to freeze modules so that they do not take away cpu resources? Or combine this function with bypassing somehow, idk.