Hi @Wurlitzer
No time frame right now except to say that besides the Mac port it’s probably top of the list along with some related features.
Brad
Might as well throw this in now;
Wherever there are timed triggers, there’s always the question of ‘chasing’ or ‘look-back’ to ensure the correct midi events are acknowledged, regardless of where playback commences.
Does anyone see this as necessary component of any trigger event?
Good question - I’m interested too in how others feel this should work.
I guess the uses of song position triggers fall into two categories:
- Simply triggering things, such as MIDI notes (e.g. sound effects), which otherwise don’t affect Cantabile’s state, or the internal state of plugins. These by definition wouldn’t require ‘look-back’, as they have no lasting legacy.
- Triggers to modify Cantabile’s state, or the internal state of plugins, such as volume changes, song state changes etc. Without ‘look-back’ these would always allow Cantabile to get into an unintended state after seeking within the song.
Since as far as I can see, most of the really useful uses of song position triggers fall into that second category, I’d say some kind of ‘look-back’ would be important, in exactly the same way as MIDI sequencers should work for control messages. Otherwise, I can see it being necessary to embed lots of ‘reset to intended target value’ triggers, instead of being able to just insert ‘change’ triggers.
So when playing back from a new location, or restarting a looped section, Cantabile should ideally ensure that any of its state is the same as it would be if it had reached this position by playing from the start. I guess you’d need to do this by dealing with different types of bindings from song position triggers in different ways. Bindings in that first category above can just be ignored, as they don’t contribute to the ‘look-back’. All other song position trigger bindings would require Cantabile to scan back to where the binding’s action was last set in an absolute way; this might be from a binding triggering earlier in the song, or from a state change. Then for some actions, such as those that can be toggled or incremented, scanning back forwards to see if other song position triggers modify the previous absolute value, and finally executing the binding if it will have an effect on its target.
This is of course made more complicated because as you scan through the song you need to take into account the scary prospect that the enabled state of some bindings might be modified by song position triggers themselves (e.g. when automating song state), so some may need to be ignored if they’re disabled. It gets even more problematic when you include the fact that the enabled state of song position trigger bindings might be modified manually by the user, either directly by other bindings or by manually changing song state, so Cantabile may not have any reliable way to know if a given binding should be regarded as enabled or disabled in a given part of the song. In fact, binding sources and targets themselves can be state-dependent, at which point all bets are off!
This then prevents it from being a solvable problem in the full, general case, since Cantabile can’t reliably know what state all of the bindings are in at any given point in the song, because it can to some extent be user-driven during the performance.
My approach would probably be for song position triggers to require a special kind of binding, with the following constraints:
- It cannot be modified by other bindings - source, target, enabled state etc. are fixed
- It has no state behaviour
- It can only bind to actions that have an absolute change (so no toggling/incrementing)
- Probably several other constraints I haven’t even considered…
That ought to take away all the complications, but still allow ‘look-back’ for song position triggers for most useful applications such as modifying song state, fader levels, MIDI control messages etc. When playing from a new location, including restarting a looped section of the song, Cantabile would need to scan back to the last song position trigger event that modifies each target, and re-trigger them, which doesn’t sound too complicated…
Neil
3 Likes
This is important for me. I would like to trigger patch / cc messages at time-stamps in a song. I could drop into a DAW and add the items, but that seems like a hack, but because I want to control the state of my gear from just one place and not have to open a midi file in another app to view/edit the events. I just want simple events like Intro > Verse > Chorus > Solo/Bridge to trigger events that allow me to change guitar and vocal effects without me tap-dancing. Does that make sense?
1 Like
Makes sense! 
Most important things a vst host should do is:
-glitchfree audio engine
-setlist functionality (I haven’t found the drag/move function in cantabile yet to move a song in the set list to another position?.. I use the move up/down command which I don’t like… lasts too long)
-automationatically move to the next song after the last song ended (still not working in cantabile?)
-time based control function (like you need)
Why using a computer and it still can’t help us on stage to automate things like… switching sounds at the right time (always most of the big problems on stage), or give a visual or audable feedback WHERE we are in the song… like “now chorus please”
We tried all VST hosts in the last 2 weeks. Cubase was the worst, instable and glitchy as hell (even after doing all modifications to the OS possible), ableton… glitches!, cantabile… good but a bit “basic” if you want to import some wav backing tracks. And because song positions as trigger events isn’t available we had to switch to reaper - which is free and does it all.
We have some songs where it is hard to know WHEN the bridge, chorus, ref comes in… and I don’t want to count to 32 at ever part of the song. As a solution we’re now having another notebook on stage which has reaper running… and reaper sends a clicktrack with infos… like 4,3,2,1… if another song part is coming, a signal horn when the singer needs to start… seems to work fine. And… as we are trying to get a “big” sound, we are using VST effects on drums, git, bass and vocals. So… no amps/cabinets on stage anymore.
Reaper switches the presets for guitar, bass. Sadfully I still have to switch presets by hand 
It would be cool to have cantabile run as a slave (timecode) to automate state switching.
Roelli.
Have you tried Ctrl-up/down? That also works for reordering plugins, racks, routes, bindings etc.
Neil
1 Like
That’s it! Thanks!
Iam an idiot… it’s also written in the manual but I overlooked it.
Roelli.
Add me to the list of people who would like this feature!
I was quite surprised to find it didn’t TBH.
1 Like
I’ve been following this since I asked if it was available when I purchased last March. Is there any update?
Thanks!
I’ve worked on a couple of different designs for this but haven’t come up with anything I’m happy with. It does open a bit of a can of worms and there’s UI work to go along with it.
Basically I don’t want to implement half baked solution and then be stuck with it so I’m biding my time on it for the moment…
1 Like
Just a little 2 cent reminder -
Until Brad gets this worked out, I have been using the method described earlier in the thread, where loopMIDI provides the link between my DAW and Cantabile. It allows a fully fledged midi editor to address Cantabile, placing all the timed commands where they need to be.
Then just export the midi file from DAW and run it in Cantabile, swapping out the routing accordingly.
If you’re working on one computer without multiclient ASIO software, just disable the audio device in your DAW and leave it active in Cantabile while you’re arranging the MIDI file.
I have to say, this approach works very well for setting up more complex midi automation because the DAW is so fully developed in this area - probably in a way that we wouldn’t want to see bogging down Cantabile’s operation.
2 Likes
Yes, I think even though it’s a bit convoluted, this is currently the most elegant way to implement position-based automation.
Given this, maybe the easiest way to move one step closer to doing this inside Cantabile would be just a very simple MIDI editor within Cantabile (maybe just a list view, filtered by channel, ordered by timestamp or bar/beat, with the ability to insert, delete and modify events). Pretty simple UI - just a table view…
OK, not quite as elegant as a timeline-/grid-based editor à la Cubase & Co, but probably good enough to do the job.
This capability, combined with loopback ports and bindings, would be good enough to deal with most time-based automation challenges.
@brad: what do you think?
Cheers,
Torsten
3 Likes
In case anyone is following this who does not want their DAW open (or do not have a DAW) this MIDI editor seems to have a good event-list editor as part of it:
http://openmidiproject.osdn.jp/Sekaiju_en.html
Terry
I’m totally up for this.
I may need to look into the loopmidi workaround for now. In addition to triggering patch changes I also need to set up loop points in the audio file, based on song position of course, where I can trigger a repeat for soloing and things like that. Would this work for that?
Brad, I’m sure when you come up with something it will be great as everything we have now is so very functional! When I’ve run into can-of-worm design situations I find the KISS principle works the best!
Thanks
With my ‘Idea’ of ‘Quantized state’ this could work…
so you could start the Audiofiles >> in Time<< with ‘load state’ and what you put into the Mediaplayer is only a ‘snipet’ of your Audiofiles
(Like cubase arranger Mode)…(or Ableton Live)
So you would Need only two options:
- Loop State until next State is pressed (… Like Variation on an Arranger Keyboard)
- Specific Command what to do at the end of Audiofile (… Like Intro or Ending on an Arranger Keyboard) [example: goto State #1, stop]
Also i could use it with ‘dummy midifile’ to work with Timed statelengths…
Only requirement is a Quantized Container/State that fires only Quantized in Time with the Beat…