Workflow Suggestions for treating commands as 'deviation from standard state."

Not sure how best to phrase this, or how to go about searching the forum. Perhaps someone can nudge me in the right direction.

My band plays live and uses MIDI to change a host of parameters on our equipment as well as on our x32 board. One of the major challenges I keep bumping up against is how to ensure that the presets we used in song A do not 'contaminate' the setup for subsequent song B. If song A requires a crazy ring modulation vocal effect from processor A, and my other 100 songs do not use processor A whatsoever, I seem forced to add a 'default' value to the presets of the other 100 songs, to ensure the ring modulator is turned off regardless of which song we play afterward. This becomes impossible to manage as adding each novel effect causes me to make 101 changes.

Alternately, I could manually select a 'song complete' preset at the end of each song. This causes delays on stage, is difficult to manage during quick transitions, and is easy to forget.

Ideally, I would be able to create a single 'default' preset which contains a default state for every parameter affected in my show. Each 'Change Song' preset would include the defaults as a prefix (or interact with it in a more sophisticated way) to ensure that all songs start from a common state.

How do others manage this? Doubtless I'm not the only one dealing with this.

 

Best,

Chris

Hi, you could have a timer the runs every timer you select any song.

And have the timer iterate through the parmeters you want to reset before the next song parameters are set. For setting the parameters on the next song, you would need to delay slightly to give time for the parameters to reset before setting up for the new song. Using a single timer would mean you always have the reset parameters in one place instead of the end of every song.

Incoming Trigger for your Song: Whatever you use to trigger

// Set the number of iterations here

ga=100

Outgoing Action : Timer “Reset Parameters” ga times, 0 initial delay 5 ms repeat delay.

Incoming Trigger for your Song: Same as above as another translator

Outgoing Action: Whatever you do for the next song, with delay of 600ms (above plus another 100)

Incoming Trigger : Reset Parameters

pp=ga

ga=ga-1

// Set oo for the MIDI Channel qq for the CC number and rr for the value

if pp==100 then oo=0

if pp==100 then qq=5

if pp==100 then rr=0

// repeat rules for each parameter you want to control

 

// OR the MIDI channel wit Bx to make it a CC number

oo=oo|0xb0

Outgoing: Raw midi oo qq rr

 


The initial set up of your rules would be a bit of a pain but after that you would be able to change in one place if you want different defaults.

If 600 ms is too long, you could try reducing the repeat time but my guess is anything under 1 second to set up for the next song would be acceptable.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

Thanks Steve!

I think I understand that you understand… but without going in to the nitty-gritty, let me summarize your suggestion and ask for your confirmation, ok?

So your solution would, upon receipt of a ‘Song #’ command, use a timer to iterate through an n-long global list of ‘default’ commands, then after a pause send out any commands specific to the song?

Sounds good, but want to make sure I understand the concept before I delve into the programming itself.

Yes, that is the idea. Initial setup may be a pain but after that, things should run smoothly for you.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

Ok. I’m on board in a conceptual sense, but I’m not clear on your instructions. (Part of this is because for all my posting about bome box, I have done very little BMT work thus far.)
How many translators are you involving in the solution you provided? If I understand things, I believe there are three. Is that correct?
#1 – Listens for any ‘new song’ trigger event, loads the iterator variable value, and starts up the defaults timer
#2 – Listens for any ‘new song’ trigger event, waits 600ms, and then sets parameters specific to a song (I would think by calling another translator based on an incoming midi value to specify the song?)
#3 – The ‘Reset Parameters’ timer – Iterates through a list of midi commands meant to ‘default’ our settings. Must be set to complete iterations before the song-specific commands are sent, plus a 100ms buffer. Your example provides a template for resetting literal CC parameters using variables. As my settings are a mix of CCs, Program Changes, and Note events, I would probably need to create multiple translators containing groups of these commands, plus a ‘manager’ translator which reads the incoming iterated variable and calls the corresponding ‘default’ translator. (The ‘manager’ translator could be coded directly into the defaults timer if I preferred)
Are my assumptions near the mark?

You are correct.

If your reset parameter timer is handling multiple types of output events, the output of the timer should probably be another 1 shot timer (ie Dispatch Timer) that uses global variables to set the type (note, cc or program change), MIDI channel, note or cc number, and value).

Then you could have 3 translators monitoring for that timer and only take action the parameters indicate that it is the type you want. They could use the global variables that you set in the reset parameter timer.

Your note translator would look at the type and if it not type note, would exit without output.

Your CC translator would look at the type and if not type CC would exit without.

Same with PC translator

 

Summary

————-

Song Change -> Outgoing Reset Iterator Timer

Song Change -> Outgoing New Song Timer with 600 ms delay

Incoming Reset Iterator Timer (iterate and Set parameters call in order you want them processed ) -> Dispatch Timer

Incoming Dispatch Timer 1 Note (triggered by Dispatch Timer) . Look for note event type and abort if not note otherwise process parameters

Incoming Dispatch Timer 2 CC (triggered by Dispatch Timer) . Look for CC event type and abort if not note otherwise process parameters

Incoming Dispatch Timer 3 PC (triggered by Dispatch Timer) . Look for PC event type and abort if not note otherwise process parameters

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 

That’s slick. Thanks Steve!

You’re welcome!