Bindings to run once when starting Cantabile

Cantabile
1

I’m trying to find a way to have bindings to run once when starting Cantabile (e.g. sending commands to initialize hardware synths to a particular state). I would hope there would be some way to do this from the Background Rack; I tried Rack >> On Load in the Background Rack, but that runs every time a song is loaded. Am i missing something ? If not, i’d suggest we request a feature for a binding source of On Load Cantabile (or Setlist >> On Load, which might be useful for other reasons).

  • Jimbo
1 Like
2

How about using a “fake” song that is only used to send its bindings on-load? That could be customized for different scenarios and those various custom “fake” songs could be inserted into a setlist to provide setups for a series of tunes following each, perhaps.

Still, being an old Sysex-heavy hardware synth guy, the notion of sending a bunch of initial setup signals used to be my world for the start of every MIDI project. So, I like your idea of a specific “On Cantabile Load” binding or script. @brad

Terry

2 Likes
3

This sounds reasonable. A couple of questions:

  1. Should this be based on app startup or engine startup? (ie: should power cycling the audio engine re-fire those bindings).
  2. Does there need to be a way to manually re-invoke them all.

Brad

4

A couple of answers (-;

  1. Only on App startup (many reasons for power cycling the audio engine where one wouldn’t want it to be doing other stuff)
  2. Don’t need to manually re-run them

Just my vote,

  • Jimbo
1 Like
5

Hey @Brad, why not just add “On AppStart” and “On EngineStart”.

Edit: Oh, because AppStart is EngineStart. Nevermind, I’m a dolt.

6

Actually, no… AppStart, EngineStart and Song Load are all separate events.

I’m going to look into adding these bindings, but it’s been a hectic week and haven’t got to it yet.

Brad

1 Like
7

I have a use case for this as well! Like initializing the lights on my Arturia MKII88 !

8

Next build (3684) will have 4 new bindings points for this:

Application Start - fired once, the first time the audio engine is started
Application Stop - fired once, if the audio engine is running when the application is closed
Engine Start - fired every time the audio engine is started
Engine Stop - fired every time the audio engine is stopped

image
image2582×439 37.2 KB

Note:

  • in order for bindings to fire, the audio engine must be running. Therefore the definition of the application start/stop events are a little loose and actually mean “the first time the audio engine is started” and “the last time the audio engine is stopped”.
  • you won’t get the Application Stop event if the app is closed when the audio engine isn’t running.
  • the start events fire after song/rack load events, the stop events before the song/rack unload events. See below
7 Likes
9

That was fast! Thanks!

10

Thanks, @brad Brad — very responsive as always !!!

Not sure i see the reasoning behind this - i would think we’d want the program start events to happen before the song/rack is loaded (after all, that’s the way the program works, right ?) For example, when starting Cantabile i’d want to send messages to put my hardware synths in a default starting condition, which could then be modified when loading a particular song or rack.

Or am i misreading what you wrote ?

– Jimbo

11
I was torn on this. The reason for it is that there's no point firing an event if the racks aren't loaded to respond to them - and if you want them to send any kind of MIDI data, the audio engine needs to be running. So, it loads the racks first, fire's their load events and then once the racks are fully initialized it fires the application and engine load events. I understand why it seems backwards, but I think it works better this way. Of course I'm open to it being wrong, but I'd like to see actual use cases where it makes a difference before making a bigger, more complex change.

See below.

Brad

12

Here’s my use case for an example:
I would want to use On Application Start to set my hardware synths to a default configuration. Then, if any song wants a different configuration, that song would use bindings On Song Load to change the configuration as needed, and bindings On Song Unload to restore the defaults. The problem comes if the first song loaded is one which wants a different configuration - the song would set the configuration as desired but that would immediately be overwritten by the On Application Start.

Probably too much to ask for variant binding points of On Application Start (immediate) and On Application Start (delayed) ?

– Jimbo

13

Hi Jim,

Of course you’re right and that makes sense. Let me see if I can tweak it. Might be a day or so as I have a small home emergency today (pool filter is expressing its desire to be a water fountain).

Brad

14

Pool filter fixed, and binding event order fixed. New order will be:

Application Start x1 time
    Engine Start                     ---|
        Rack Load      --|              |
        Song Load        |              |
        Song Unload      |              |
        Rack Unload    --| x N times    |
    Engine Stop                      ---| x M times
Application Stop (once)

Better?

3 Likes
15

I like! Makes most sense

  • prepare everything “non-rack-related” with the App Start binding,
  • set up rack basics with the Rack Load binding
  • re-initialize racks with rack-internal “Song-OnLoad” bindings (to revert changes made in a previous song)
  • then potentially override with song-specific “Song-OnLoad” bindings at song level

Feels very consistent and useful to me!

1 Like
16

Build 3684 available now has this. Should be considered experimental for the moment.