Mozaic Footswitch Plus Keyboard Note to send PC and Session load in AUM.

Bellows

Hi Friends
If I am posting this to the wrong area please spin me around and head me the right way😎
I have returned after a long time gone. Mozaic is a great tool.
I am trying to use make my setup very small and portable. I want to use only one switch on my Airturn Bluetooth pedal combined with one midi note from my keyboard to make PC and/or Session load in AUM.
The plan is whenever I want to send such a message I will hold down the footswitch sending a CC VALUE of 127 to AUM. This value will be added to a note number selected on my keyboard (a small Roland V-Accordion🪗). The result will select a PC or Session Load in AUM.
I have written some script and the footswitch portion works well. I have also triggered PCs and Session loads in AUM properly.I don’t know a good way to add the values together to select which PC# gets sent. This is my obstacle at the moment.
BTW, the message to AUM cab be CC, PC, or Note#.
I don’t remember how you post code here properly.
Any help appreciated.
Bruce

espiegel123

@Bellows : what do you mean by “I will hold down the footswitch sending a CC VALUE of 127 to AUM. This value will be added to a note number selected on my keyboard”

Midi values (for anything other than pitchbend) are limited to 0 to 127. So you can’t add 127 to a midi value.

Can you describe differently what you want? Do you want the next note number after the pedal is pressed to be sent as a PC value?

wim

@Bellows - It sounds as though you want to pass notes from your V-Accordion through except for when you're holding down the foot switch. When the switch is held down you want the notes to be passed through as a PC message.

Is that correct?

Bellows

Thanks for the fast response. Good point about the 127 value. I was sending on/off CC # info and just picked 0 for off and 127 for on. I see the problem with that and will use 1 to represent “on”.
I have not explained my intention well enough.
When I press the footswitch I will change into a mode that will send a signal that will initiate a program change or a session load based on a key that is pressed on my keyboard.
I see from talking to you that the addition will not be necessary.
The switch activates the process and only then the keyboard will send out the note number information to select a new program or session.
When the footswitch is released the keyboard will resume its normal function.
Another way to think of it is that the footswitch redirects a note from the keyboard to effect a program change. The different keys on the keyboard will each select a different program..

The idea is I will be playing normally. Then stop playing momentarily, push the footswitch, press a keyboard key effecting a program change, release the footswitch and continue playing normally with a different program or session.

I hope this explains my plan. You have already helped immensely. Any other thoughts will be appreciated also.

espiegel123

@Bellows : that’s simple.

Create a variable called something like pcMode

Set it to 0 on load.

If your on message gets sent, set pcMode to 1. If off comes in set pcMode to 0

If a note on comes in, check to see if pcMode is 1. If it is, send a PC message out with whatever number is convenient. It could be the note number or calculated from the note number.

If pcMode is 0, send out a copy of the note message you received.

wim

It sounds as if my guess at what is wanted is correct. Here's a basic script I wrote while you two were discussing:

@Description
When foot switch is pressed, convert note On messages to Program Change. Otherwise, pass all midi through.
Configure the foot switch message in @OnLoad
Release the PC note before the foot switch to avoid extra Note-Off messages.
@End

@OnLoad
  // set the incoming cc, channel, and velocity from the footswitch
  cc = 20
  chan = 0
  velocity = 127
  passThru = YES
@End

@OnMidiCC
  if (MIDIChannel = chan) and (MIDIByte2 = cc)
    if MIDIByte3 = velocity
      passThru = NO
    else
      passThru = YES
    endif
  endif
@End

@OnMidiNote
  if not passThru
    if MIDICommand = 0x90   //Note ON only
      SendMIDIProgramChange chan,MIDINote
    endif
  else
    SendMIDIThru
  endif
@End

@OnMidiInput
// pass through midi messages not handled above
// 0x90 = Note ON, 0x80 = Note OFF, 0xB0 = CC
  if MIDICommand <> 0x90 and MIDICommand <> 0x80 and MIDICommand <> 0xB0
    SendMIDIThru
  endif
@End

@OnSysex
  SendSysexThru
@End

Bellows

Many thanks to both of you for your help.
Wim, your script works perfectly and I can understand it🤔😀
I will have a couple of more questions in the future but right now I am having a great time playing with it.
Thanks,
Bellows

wim

👍🏼

It was actually a really great idea for getting the most out of such a controller.

Bellows

@wim said:
👍🏼

It was actually a really great idea for getting the most out of such a controller.

Thanks Wim, I saw it years ago in an accompaniment program called Live Styler.
In Live Styler you sacrificed a key on the keyboard (usually the lowest least used key). When you held that key down with your thumb you could send a PC by adding another note with your fingers. There were also other functions performed by your fingers only when the lowest key was held down.
I did not do that here because my keyboard is already only two octaves as many controllers are today.
Thanks so much for your help.🪗🎶

Bellows

Hi Wim, just wanted to let you know how very well this script is working with AUM. It is soooo good.
I am using the first octave of my keyboard to initiate sessions.
I am using the second octave to call presets after the session is active.
Thank you so much for your help.
LooseBruce

wim

Hi @belllows - that's great to know.
I may polish it up a bit and post it on Patchstorage in case someone else can get use out of it.

Bellows

Hi Friends,
I am reviving this thread because I need a little help. I have been using this script for a couple of years and it is essential to my performances.I use it in every session for live performance. I recently tried to incorporate cc#64 controlling sustain in some of my sessions and ran into difficulties.

I would like to repost my version of the script in case it is different before we discuss it.
I forgot the procedure for posting code . Please enlighten me.

To get sustain working I had to midi map it directly to the apps involved. My guess is this made a duplicate path that conflicted with this script. This caused great instability resulting in crashes, erratic tuning, stuck notes, you name it.
Please help.
Thanks, Bruce

uncledave

Posting code: 3 backticks alone on a line before and after the code block results in code formatting.

Are you using CC64 for the footswitch to enable the PC and session load as well? That would be confusing, since the script doesn't know what you intend.

Bellows

Thanks uncle Dave. No I am using cc#20 for the PC enable signal.
It seems like some apps the cc#64 is built in and some you have to go through the midi controls on the AUM channel and assign it.

Bellows

Thank you.Here is the code:

@Description
When foot switch is pressed, convert note On messages to Program Change. Otherwise, pass all midi through.
Configure the foot switch message in @OnLoad
Release the PC note before the foot switch to avoid extra Note-Off messages.
@End

@OnLoad
  // set the incoming cc, channel, and velocity from the footswitch
  cc = 20
  chan = 0
  velocity = 127
  passThru = YES
@End

@OnMidiCC
  if (MIDIChannel = chan) and (MIDIByte2 = cc)
    if MIDIByte3 = velocity
      passThru = NO
    else
      passThru = YES
    endif
  endif
@End

@OnMidiNote
  if not passThru
    if MIDICommand = 0x90   //Note ON only
      SendMIDIProgramChange chan,MIDINote
    endif
  else
    SendMIDIThru
  endif
@End

@OnMidiInput
// pass through midi messages not handled above
// 0x90 = Note ON, 0x80 = Note OFF, 0xB0 = CC
  if MIDICommand <> 0x90 and MIDICommand <> 0x80 and MIDICommand <> 0xB0
    SendMIDIThru
  endif
@End

@OnSysex
  SendSysexThru
@End
@End

It would seem that cc#64 should pass through Mozaic when Mozaic is midi mapped to the app. In fact, other cc#s that I am using appear to do that.

Bellows

Here is a pic of my typical midi map. This session has 3 instances of Korg Module Pro acoustic Piano.
The sustain cc#64 does not work configured like this. I would expect it to work on Module Pro @ A3 because that instance is on midi channel one and so are the foot switches. It does not matter if the midi controls for that channel in AUM are set to use cc#64 or not.

If I make a connection where the white circle is the CC#64 will activate the sustain wether or not it is set or not.

I would have thought the connection with the red circle would work but it did not.
Thanks

uncledave

Your Mozaic script blocks all CCs; the test for 0xB0 in @OnMidiInput ensures they are not transmitted. So the red circle connection will not work.

Have you tried a MIDI monitor to see what data the various sources/apps are sending?

Bellows

@uncledave said:
Your Mozaic script blocks all CCs; the test for 0xB0 in @OnMidiInput ensures they are not transmitted. So the red circle connection will not work.

Have you tried a MIDI monitor to see what data the various sources/apps are sending?

I thought this command did not block but instead passed thru all CCs.

Bellows

As far as midi monitoring goes, yes, I have monitored much when looking for the instability problem. I have not looked for the sustain CC#64 as a path. I will see what I can find.

BTW, I remade the cc#20 direct to an app and the instability returned.

uncledave

@Bellows said:

@uncledave said:
Your Mozaic script blocks all CCs; the test for 0xB0 in @OnMidiInput ensures they are not transmitted. So the red circle connection will not work.

Have you tried a MIDI monitor to see what data the various sources/apps are sending?

I thought this command did not block but instead passed thru all CCs.

if MIDICommand <> 0x90 and MIDICommand <> 0x80 and MIDICommand <> 0xB0
SendMIDIThru
endif

Says "if the command is not (<>) Note On and not Note Off and not CC, then send it to output". So it blocks all note and CC messages, passing only the other 5 MIDI message types.

wim

@uncledave said:

@Bellows said:

@uncledave said:
Your Mozaic script blocks all CCs; the test for 0xB0 in @OnMidiInput ensures they are not transmitted. So the red circle connection will not work.

Have you tried a MIDI monitor to see what data the various sources/apps are sending?

I thought this command did not block but instead passed thru all CCs.

if MIDICommand <> 0x90 and MIDICommand <> 0x80 and MIDICommand <> 0xB0
SendMIDIThru
endif

Says "if the command is not (<>) Note On and not Note Off and not CC, then send it to output". So it blocks all note and CC messages, passing only the other 5 MIDI message types.

The script is OK for sending through the relevant cc messages. Yes, CC's are blocked in the @OnMidiInput event, but that's because they're handled in the @OnMidiCC event. It's necessary to exclude them being handled twice.

uncledave

What MIDI messages is the BT500S sending? On press and on release?

What are you using the two MIDI busses for? If they're both enabled, you will be receiving duplicates of all the messages from "widijack" (your accordion?) at Module Pro @A3.

wim

@Bellows - I hope you don't mind, I fixed the formatting in your post with the code. To get the code block to format correctly, you need three back ticks on a line by themselves before and after the code. You used apostrophes and they weren't on a line by themselves.

If you open that post for editing, You will be able to see how I placed the back ticks.

Here's what might be an easier way: Paste your code, then highlight all the code and use the paragraph format (backwards P) in the formatting bar to select Code. This will indent all the selected lines 4 spaces, which accomplishes the same thing.

As for the script problem, I'll try to take a look to see what might be going wrong.

Bellows

Big thanks to both of you. I appreciate the explanation and believe it.
This pic shows what comes out of Mozaic. No CCs as you both have explained.
All the CCs come out of the footswitch as expected (not shown).

They go from there to midi control which I don’t know how to monitor.

wim

You've got an extra @End at the bottom of the script. Be sure to take that out. It's not likely the problem, but it's good to be sure when debugging.

wim

Let me see if I understand what is happening based on the routing matrix:

• Play notes from AUM keyboard:

  • Plays notes on Module Pro on A3
  • Sends notes to Aum MIDI Control. Why?

• Send midi from devices via widijack bluetooth

  • Sends all midi directly to all Module instances
  • Also sends all midi directly to midi busses that are also routing to Module Pro on A3. Possible duplication to A3
  • Sends midi to AUM midi control. Why?
  • Also sends midi to Mozaic for processing, then on to AUM Midi control. Possible duplication to midi control?

• Send midi from BT5005

  • Sends directly to AUM midi control Why?
  • Also sends to Mozaic for processing then on to AUM Midi control. Possible duplication

I don't fully understand what you're sending and exactly what you're trying to do with the midi messages, but at first glance, it looks like you have a lot of potential for duplicated routing. When using Mozaic, you normally would route through Mozaic only, not in parallel. If there's a reason for those duplicated routings, that's important to understand.

Bellows

@wim said:
Let me see if I understand what is happening based on the routing matrix:

• Play notes from AUM keyboard:

  • Plays notes on Module Pro on A3
  • Sends notes to Aum MIDI Control. Why?

• Send midi from devices via widijack bluetooth

  • Sends all midi directly to all Module instances
  • Also sends all midi directly to midi busses that are also routing to Module Pro on A3. Possible duplication to A3
  • Sends midi to AUM midi control. Why?
  • Also sends midi to Mozaic for processing, then on to AUM Midi control. Possible duplication to midi control?

• Send midi from BT5005

  • Sends directly to AUM midi control Why?
  • Also sends to Mozaic for processing then on to AUM Midi control. Possible duplication

I don't fully understand what you're sending and exactly what you're trying to do with the midi messages, but at first glance, it looks like you have a lot of potential for duplicated routing. When using Mozaic, you normally would route through Mozaic only, not in parallel. If there's a reason for those duplicated routings, that's important to understand.

I understand your questions, I see I may need a different approach. This all sort of evolved over time.

1) The AUM keyboard is just for when I am testing from my armchair. It is eliminated now.

2) My controller is a Roland electronic accordion. It sends out midi on three channels:

Midi Channel 1 is the piano keyboard. Besides playing notes this is where the sessions/programs are selected. (Module Pro @A3)

Midi Channel 2 is the bass buttons. (Module Pro @A1)

Midi Channel 3 is the chord buttons (Module Pro @A2)

3) Often in other sessions the above three channels each have a different synth.
In this case there are three instances of the same program so I can balance the volumes between them. These three channels are sent from the accordion on a WIDI JACK wireless Tx named widijackipad6Bluetooth.

4) The widijackipad6Bluetooth is routed to midibuss A and midibuss B where only channel one is allowed through the filter. Only one of these busses is enabled at a time and one them is transposed up by one octave. This allows me to use one of my footswitches (CC#65) to act as an octave select. I only want the piano keyboard to have this octave transpose function.

5 ) The footswitches and a couple of expression pedals are the BT500s Airturn pedal sending all of its data on channel 1. (CC#20) is used in Mozaic to start the session/preset selection.
CC#16 is usually used to control volume via channel sliders in AUM via an expression pedal.
CC#17 is the other expression pedal and its uses vary by session.
The other CC switches control whatever depending on session.

6) As you can see ALL of the control functions come from channel one.

I understand what you are telling me about routing everything through Mozaic first. The way the code is now is that possible?
Thanks for your help,
Bruce

uncledave

@wim said:

@uncledave said:

@Bellows said:

@uncledave said:
Your Mozaic script blocks all CCs; the test for 0xB0 in @OnMidiInput ensures they are not transmitted. So the red circle connection will not work.

Have you tried a MIDI monitor to see what data the various sources/apps are sending?

I thought this command did not block but instead passed thru all CCs.

if MIDICommand <> 0x90 and MIDICommand <> 0x80 and MIDICommand <> 0xB0
SendMIDIThru
endif

Says "if the command is not (<>) Note On and not Note Off and not CC, then send it to output". So it blocks all note and CC messages, passing only the other 5 MIDI message types.

The script is OK for sending through the relevant cc messages. Yes, CC's are blocked in the @OnMidiInput event, but that's because they're handled in the @OnMidiCC event. It's necessary to exclude them being handled twice.

I don't believe so. There is no Send MIDIThru in @OnMidiCC, so all CCs are blocked there. The passThru flag only determines whether notes are allowed to pass, or generate PC messages.

wim

Thanks for the detailed explanation. That helps a lot.

Try removing the direct from your bluetooth midi sources to both midi control and through mozaic to midi control. The midi should only go to Mozaic and from there Midi Control. I don't think you need to touch any of the direct to plugin and bus routings.

I think where things are tripping up is not with the midi flow to your plugins, but with the duplicate flow to midi control.

wim

@uncledave said:

@wim said:

@uncledave said:

@Bellows said:

@uncledave said:
Your Mozaic script blocks all CCs; the test for 0xB0 in @OnMidiInput ensures they are not transmitted. So the red circle connection will not work.

Have you tried a MIDI monitor to see what data the various sources/apps are sending?

I thought this command did not block but instead passed thru all CCs.

if MIDICommand <> 0x90 and MIDICommand <> 0x80 and MIDICommand <> 0xB0
SendMIDIThru
endif

Says "if the command is not (<>) Note On and not Note Off and not CC, then send it to output". So it blocks all note and CC messages, passing only the other 5 MIDI message types.

The script is OK for sending through the relevant cc messages. Yes, CC's are blocked in the @OnMidiInput event, but that's because they're handled in the @OnMidiCC event. It's necessary to exclude them being handled twice.

I don't believe so. There is no Send MIDIThru in @OnMidiCC, so all CCs are blocked there. The passThru flag only determines whether notes are allowed to pass, or generate PC messages.

You're right. Sorry. I missed that.

Bellows

There is no @OnMidiCC, so all CCs are blocked there. The passThru flag only determines whether notes are allowed to pass, or generate PC messages.

This is true. I checked with the midi monitor. I am not exactly sure the right way to add it to the code but I will try.