Recently we have been chatting about using arrangers, talkers and drummers in live performance.
At one extreme is the scripted performance of a piece where one might use the arrangers to present the player with the changes at the proper time. The problem with this is that the player then is driven by the music. Such a thing might be OK for doing a cover of a song for a video or playing against a backing track but it is both limiting and unpleasant (and lifeless) in the context of a live performance.
At the other extreme is setting up a talker for the event / change (or using the existing drummer or loop controls) and have them happen on command. This way the music follows the player who is free to repeat or extend a section based on their own feeling or on the reaction to a live performance. The problem here is that one must hit the key at just the right time and focussing on that takes the player out of the musical moment as they are (as in the first example) driven by the song rather than the other way around.
So, here is a thought for an agent that addresses this. It would be an alternative destination for a talker that would hold a bit of Belcanto until a particular time.
It could be called a queuer, a scheduler, an eventlist, whatever seems best.
The talker would talk to this agent to give it the original command prefixed with something like: "hey scheduler1 at bar 'original command' do" and would then wait for the next bar to speak the command. It would support times like bar, beat, or other quantizations (such as multiple bars / beats?).
The obvious application is to switch drum loops at a bar more precisely and with less thought than at present. (it might be nice to have a latency adjustment in the agent?). It could also be used with the recorders, the metronome itself (to change tempo), arranger enablers and so on.
While I'm at it, it would be nice to initiate tempo changes with one of the foot controllers (or perhaps tap tempo with a switch - can that be wired now?). I was thinking, though, that it would be useful to have a relative change to the controller result in accel / decel proportional to the rate of change.
The two things above would seem to be important to place the player in control of the temporal aspect of a performance without demanding much of their attentional bandwidth