I have been a happy Cantabile user and silent reader of this forum since 2017. Unfortunately, I had some scaling issues with the 35xx series which is why I have been stuck with build 3289 for a while now. The new rendering introduced in Cantabile 4 seems to mitigate those issues. Therefore, I will proudly extend my subscription for the first time in years. Finally being on top of the technology again is enough encouragement for me to be a more active part in this community. I’d like to start of by dumping some of the thoughts concerning possible features that I collected over the past years. These are mostly little things that have been nagging me while working with Cantabile. As a disclaimer: I know that part of the reason Cantabile is so powerful without feeling bloated is that Brad does not just throw in every single feature that is suggested in this forum. So I will naturally continue to be a happy customer even if none of these suggestions make it into the software.
Some kind of controller object that lets you place faders, buttons, knobs. This might be a type of rack that has a customizable list of input elements and a binding section to bind those elements to whatever you want. Alternatively, it could just be an object without binding panel that is available as binding source in its parent’s rack/song. I think this would really fit into the “You can build everything you can imagine with racks, routes, and bindings” theme of Cantabile.
One of the few routines in my workflow I haven’t found a good solution for yet is sending CC messages to a hardware synth based on song states. My way of doing this is very tedious: Create two “Song States -> On Load” bindings that send different CC values, set their state behavior for “Enabled”, and enable one binding for the song states in question and the other for the others. I tried to virtualize those hardware controls in a rack with embedded racks for each control by binding the gain slider to the CC value. However, this is far from ideal since the dB to MIDI mapping is not linear. Having some kind of customizable input objects for bindings would really help a lot. As a side note: Another solution to my particular problem would be to provide the option of overriding the gain control curve per rack. But I think the “Controller Object” is more general and less hacky.
Making some of the audio engine settings available as binding targets (primarily buffer size). I sometimes find myself in situations where it would be helpful to change the buffer size on a per song basis. When playing guitar, the latency introduced by a buffer size of 256 is very noticeable due to the direct nature of a guitar and since the audio needs to go through two buffers. At the same time, a buffer size of 128 may be to small for songs with many CPU heavy plugins. Having the ability to automatically change the buffer size for only a few songs would be awesome. From a developer perspective, however, I do understand that it might not feel right to open up driver settings like that.
I really like the template options for songs and racks. However, rack templates only seem to work for linked racks at this time. The way I use racks makes templates particularly useful for embedded racks since I initialize instrument racks from a premade template file.
Maybe add an option to set a template as default which skips the whole “Choose template” dialog when creating a new song/rack. I only have a single song template where every new song is derived from. It would save some clicks if wouldn’t have to manually select that template instead of (Blank).
Default audio routes (I think this was suggested before). When I insert a new rack, it is automatically routed to the main output instead of my mixer rack. It would be very helpful if you could set the default audio target on song level. Taking this a step further, you could save default midi/audio in-/output routes for newly insert plugins/racks per song/rack. So that when I insert a plugin into one of my instrument racks, it would automatically place itself at the correct position within the signal chain.
Ordering of the source/target dropdowns for routes and especially bindings: Currently these dropdown menus are only sorted alphabetically which makes it very hard to find what you are looking for if you have a lot of racks. It would be so much clearer if these sources/targets were grouped by category and sorted alphabetically within these groups. E.g.: Global items (Engine, Master Levels, Metronome,…) | Input Ports | Output Ports | Rack Ports | Plugins, Plugin Ports| …
I’m sure I would never mistake “Master Levels” and my “Master” Rack again or “Input Port - Nord Stage 2” and the corresponding virtual rack “Nord Stage 2 In”.
Hi Jonas, and welcome as a participant , and thanks for the ideas.
Regarding 1. Controller object, that sounds very similar to what you can achieve with the controller bar, I would say. Have you tried the controller bar to get this functionality?
The controller bar is indeed very similar. However, there are some limitations. The obvious one is the number of control elements I can configure.
For my little use case (i.e. a virtualization of the MIDI-addressable controllers of a hardware synth) I would require hundreds of faders if I was to map each controller on my Nord Stage 2. The “controller object” I am dreaming of could be placed within racks just like plugins and would fully integrate with the state behavior system. This means there would be a controller object for “Slot A Synth Filter Frequency” with a fader to dial in the CC value. I could then enable the state behavior for that fader and set different values for different song states. Switching between song states would send the CC values assuming I have appropriate bindings in place. Just like racks and plugins, it should be possible to disable these controller objects so that no accidental MIDI messages are sent when I am not using a particular controller.
Controlling MIDI CCs is really just one use case. I think many instrument and utility racks would benefit from the possibility to dial in settings without having to dig too deep into the internal circuitry (similar to IE Massive’s macros). Just think of the enigma machine that is @dave_dore’s fader rack.
Default colors for racks and plugins. I like to color-code different types of racks/plugins but I always forget to set the color after adding one to a song.
An open/ collapse all command for the main list view (if.
@brad What are your thoughts regarding these suggestions? Especially the ones in my first post.
Yes, I’m definitely interested in adding something like this. I presume you’re asking about putting these in the song/rack as opposed to globally like the controller bar?
Not keen on this… that would require shutting down the audio engine, which also shuts down the binding system and sounds like it would open a can of worms. Anyone else think this might be useful?
I could probably add this. In the meantime, you can use the template system to add a linked template rack and then right click on the rack and choose “Convert to Embedded Rack”.
Yes, this was an idea from a long time ago… surprisingly it’s not been brought up much since so I’ve never given it a high priority - although I notice it’s got a good number of votes.
I’ve been putting this off for a long time because I was waiting for the new GuiKit - which is here now so I guess I can probably do something about this. Not sure what happened to the trello card for this, so created a new one
Correct, I envision something that you can just slap into a song or rack and then use bindings for wiring the controls to the respective functionality within the rack. Either by providing its own binding panel (similar to the buttons which can be bound within the rack’s binding panel). Or by exposing it as a binding source within the rack/song the controller resides in (e.g. binding source “Controller Bar 1 → Fader 1 Value”). The latter is probably more powerful.
I thought that this is a pretty delicate subject. But wouldn’t that be similar to “Restart Engine” just with an additional step involved? The buffer size is the one thing that keeps me from bringing my guitar more often. Playing muted notes is really no fun with the latency of 256 samples.
I’m currently playing around to see what else I can do with bindings (still catching up with new features). It’s really hard to find those system binding sources/targets if you have a lot of racks. Bringing some organization into those lists is probably easier to implement than the other suggestions and would improve the workflow a lot.
You can set custom colors in the settings. You will just have to abandon one of the 16 default colors. But I guess that is low price to pay for puce and chartreuse .
My workflow regarding this is as follows: Insert “embedded rack from file” to open an instrument template rack (e.g. for Serum), make some modifications, and click “save rack as copy” to save the finished sound without converting the embedded rack to a linked rack.
, and thanks for the ideas.
.