Request new Mozaic Scripts *HERE*

ztones

@wim said:
Btw, @ztones, what host(s) are you using Mozaic in?
If you're interested, Loopy Pro has various tap detections built-in.

AUM... I don't loop at all, which I know is not a requirement in Loopy Pro, but....still I think its geared for that use. I have AUM so nicely setup otherwise, I'd just love to get more functionality out of my buttons.

wim

@ztones said:

@wim said:
Btw, @ztones, what host(s) are you using Mozaic in?
If you're interested, Loopy Pro has various tap detections built-in.

AUM... I don't loop at all, which I know is not a requirement in Loopy Pro, but....still I think its geared for that use. I have AUM so nicely setup otherwise, I'd just love to get more functionality out of my buttons.

👍🏼

ztones

BTW, in your timed script for my auto turn on/off based on movement, in the @InMotion section I put my action to activate the plugin, like this:

@InMotion
// Substitute your own in-motion actions here...
SendMIDICC 1, 36, 127
Log {Chan. }, (exp_ch+1), { - cc}, exp_cc, {: }, value
@End

The CC 36 127 value is being continuously sent over and over as I move the pedal. Its not causing any issues, but is there a way to only send it once (to activate the plugin)? The 0 value (to bypass) is sent correctly after motion is stopped for 2 seconds.

wim

@ztones said:
BTW, in your timed script for my auto turn on/off based on movement, in the @InMotion section I put my action to activate the plugin, like this:

@InMotion
// Substitute your own in-motion actions here...
SendMIDICC 1, 36, 127
Log {Chan. }, (exp_ch+1), { - cc}, exp_cc, {: }, value
@End

The CC 36 127 value is being continuously sent over and over as I move the pedal. Its not causing any issues, but is there a way to only send it once (to activate the plugin)? The 0 value (to bypass) is sent correctly after motion is stopped for 2 seconds.

That's interesting. So you're not making use of the expression pedal's output? Or are you making use of it by parallel routing it to the FX?

ztones

@wim said:

@ztones said:
BTW, in your timed script for my auto turn on/off based on movement, in the @InMotion section I put my action to activate the plugin, like this:

@InMotion
// Substitute your own in-motion actions here...
SendMIDICC 1, 36, 127
Log {Chan. }, (exp_ch+1), { - cc}, exp_cc, {: }, value
@End

The CC 36 127 value is being continuously sent over and over as I move the pedal. Its not causing any issues, but is there a way to only send it once (to activate the plugin)? The 0 value (to bypass) is sent correctly after motion is stopped for 2 seconds.

That's interesting. So you're not making use of the expression pedal's output? Or are you making use of it by parallel routing it to the FX?

I am! The expression pedals output CC23 is going through and is moving the pedal without writing anything specific into the InMotion command. I am NOT parallel routing it into the FX plugin. Is that not supposed to be happening? Along with the moving the pedal, the only other thing I wanted was to UNbypass (CC 36, 127) ONCE when I start moving the pedal and then 2 sec's after stop moving it, bypass it (CC 36, 0). The bypass 0 value is correctly going through once, but the 127 is continous... which I guess it makes sense, since I continue moving it. But wondering if there is a way to only send once? Here is the entire code as a reminder:

@Description
Listen for a changing cc value and do one thing if values are changing and another if not.
Switch to log view for this demo.
@End

@OnLoad
exp_ch = 0 // The channel to listen to
exp_cc = 23 // The message to listen for
timeout = 2000 // Wait time to detect stopped movement

lastTime = -1
value = -1
lastValue = -1
running = NO
SetTimerInterval 10 //Increase if CPU use is too high (unlikely)

Log {Waiting for movement...}
@End

@OnMidiCC
if (MIDIChannel = exp_ch) and (MIDIByte2 = exp_cc)
value = MIDIByte3
lastTime = SystemTime
if not running
StartTimer
running = YES
endif
else
SendMIDIThru
endif
@End

@OnMidiInput
// Pass all other MIDI Thru (cc messages are handled above)
if MIDICommand <> 0xB0 //CC message
SendMIDIThru
endif
@End

@OnTimer
now = SystemTime
if (now - lastTime) < timeout
// Take the in-motion action, but only after checking that values have
// actually changed, to avoid spamming unnecessary messages.
if value <> lastValue
lastValue = value
Call @InMotion
endif
else
// Take the stopped action
StopTimer
running = NO
Call @Stopped
endif
@End

@InMotion
// Substitute your own in-motion actions here...
Log {Chan. }, (exp_ch+1), { - cc}, exp_cc, {: }, value
@End

@Stopped
// Substitute your own resting actions here.
Log {Waiting for movement...}
@End

wim

@ztones said:
I am! The expression pedals output CC23 is going through and is moving the pedal without writing anything specific into the InMotion command. I am NOT parallel routing it into the FX plugin. Is that not supposed to be happening? Along with the moving the pedal, the only other thing I wanted was to UNbypass (CC 36, 127) ONCE when I start moving the pedal and then 2 sec's after stop moving it, bypass it (CC 36, 0). The bypass 0 value is correctly going through once, but the 127 is continous... which I guess it makes sense, since I continue moving it. But wondering if there is a way to only send once? Here is the entire code as a reminder:

Something is off here. The script doesn't pass CC23 through. Unless I'm overlooking something, if CC23 is getting to the app then it should be coming from somewhere else. Can I see a screenshot of your routing matrix in AUM?

(And yes, I understand what you want. But I need to get this issue understood before proceeding. Maybe I'm missing something.)

ztones

@wim said:

@ztones said:
I am! The expression pedals output CC23 is going through and is moving the pedal without writing anything specific into the InMotion command. I am NOT parallel routing it into the FX plugin. Is that not supposed to be happening? Along with the moving the pedal, the only other thing I wanted was to UNbypass (CC 36, 127) ONCE when I start moving the pedal and then 2 sec's after stop moving it, bypass it (CC 36, 0). The bypass 0 value is correctly going through once, but the 127 is continous... which I guess it makes sense, since I continue moving it. But wondering if there is a way to only send once? Here is the entire code as a reminder:

Something is off here. The script doesn't pass CC23 through. I think if CC23 is getting to the app then it should be coming from somewhere else. Can I see your routing matrix in AUM?

(And yes, I understand what you want. But I need to get this issue understood before proceeding. Maybe I'm missing something.)

Of course! I appreciate you wanting to understand it! Me too! . Here is the midi routing. The Wah effect is in ToneStack Pro. As you can see, only Mosaic’s midi is routed to it. The midi controller/expression pedals is all coming from TSMEGA.

ztones

Also, here the “adapted” code. The way I adapted your code into mine…
PS: I changed cc23 to cc24.

`@OnLoad
ShowLayout 2
LabelKnob 0, {V}
LabelKnob 1, {W}
LabelPad 0, {1}
LabelPad 1, {2}
LabelPad 2, {3}
LabelPad 3, {4}
LabelPad 8, {A}
LabelPad 9, {B}
LabelPad 10, {C}
LabelPad 11, {D}

for i = 0 to 3
ColorPad i, 4
endfor
for i = 8 to 11
ColorPad i, 4
endfor

// this part is for Z timed
exp_ch = 0 // The channel to listen to
exp_cc = 24 // The message to listen for
timeout = 2000 // Wait time to detect stopped movement

lastTime = -1
value = -1
lastValue = -1
running = NO
SetTimerInterval 10 //Increase if CPU use is too high (unlikely)

Log {Waiting for movement...}

@End

@OnKnobChange
if LastKnob = 0
setting = GetKnobValue 0
SendMIDICC 0, 0, setting
endif
@End

@Description
Listen for a changing cc value and do one thing if values are changing and another if not.
Switch to log view for this demo.
@End

@OnMidiCC
if (MIDIChannel = exp_ch) and (MIDIByte2 = exp_cc)
value = MIDIByte3
lastTime = SystemTime
if not running
StartTimer
running = YES
endif
else
SendMIDIThru
endif
@End

@OnMidiInput
// Pass all other MIDI Thru (cc messages are handled above)
if MIDICommand <> 0xB0 //CC message
SendMIDIThru
endif
@End

@OnTimer
now = SystemTime
if (now - lastTime) < timeout
// Take the in-motion action, but only after checking that values have
// actually changed, to avoid spamming unnecessary messages.
if value <> lastValue
lastValue = value
Call @InMotion
endif
else
// Take the stopped action
StopTimer
running = NO
Call @Stopped
endif
@End

@InMotion
// Substitute your own in-motion actions here...
SendMIDICC 1, 36, 127
Log {Chan. }, (exp_ch+1), { - cc}, exp_cc, {: }, value
@End

@Stopped
// Substitute your own resting actions here.
SendMIDICC 1, 36, 0
Log {Waiting for movement...}
@End

@OnPadDown
if LastPad = 0
//SendMIDICC 2, 0, 127
SendMIDIProgramChange 2, 0
endif

if LastPad = 1
SendMIDIProgramChange 2, 1
endif

if LastPad = 2
SendMIDIProgramChange 2, 2
endif
@End `

wim

@ztones - The routing looks correct, but I just can't understand why the WAH pedal is moving in Tonestack. I loaded your script and checked the midi output. There is no output of CC 24 on MIDI Channel 1 coming from the script. Is Tonestack somehow mapped to relative CC on channel 2, CC 36?

wim

@ztones - I'm trying to do some testing here, but Tonestack Pro doesn't show up in the routing matrix for me. Is there a setting in TS that I'm missing?

ztones

Got it! I had turn off this in advanced MIDI settings inside Tonastack. Sneaky! . Now CC 24 is NOT getting through, pedal is not moving.

wim

@ztones said:
Got it! I had turn off this in advanced MIDI settings inside Tonastack. Sneaky! . Now CC 24 is NOT getting through, pedal is not moving.

That's on for me, but there's no way for me to route anything to Tonestack in AUM.

I wonder, is Tonestack listening directly to your hardware pedal? AU's don't usually do that, but it's the only thing that would explain this. I guess I'll dig out my expression pedal ...

ztones

@wim said:

I wonder, is Tonestack listening directly to your hardware pedal? AU's don't usually do that, but it's the only thing that would explain this. I guess I'll dig out my expression pedal ...

It must be, because as soon as I turned that off, the pedal stopped working. But, the bypass on/off cc36 was still working, so yeah, it was listening to my hardware port even though I did not have it connected in wiring.

wim

OK, that's odd, but if it works, it works. Here's the way to stop the spammed cc 36 messages. Note the changes to @OnLoad, @InMotion, and @Stopped.

@Description
Listen for a changing cc value and do one thing if values are changing and another if not.
Switch to log view for this demo.
@End

@OnLoad
  exp_ch = 0          // The channel to listen to
  exp_cc = 24         // The message to listen for
  timeout = 2000      // Wait time to detect stopped movement
  
  lastTime = -1
  value = -1
  lastValue = -1
  running = NO
  SetTimerInterval 10  //Increase if CPU use is too high (unlikely)
  
  if Unassigned engaged
    engaged = NO
  endif
  
  Log {Waiting for movement...}
@End

@OnMidiCC
  if (MIDIChannel = exp_ch) and (MIDIByte2 = exp_cc)
    value = MIDIByte3
    lastTime = SystemTime
    if not running
      StartTimer
      running = YES
    endif
  else
    SendMIDIThru
  endif
@End

@OnMidiInput
  // Pass all other MIDI Thru (cc messages are handled above)
  if MIDICommand <> 0xB0  //CC message
    SendMIDIThru
  endif
@End

@OnTimer
  now = SystemTime
  if (now - lastTime) < timeout
    // Take the in-motion action, but only after checking that values have 
    // actually changed, to avoid spamming unnecessary messages.
    if value <> lastValue
      lastValue = value
      Call @InMotion
    endif
  else
    // Take the stopped action
    StopTimer
    running = NO
    Call @Stopped
  endif
@End

@InMotion
    // Substitute your own in-motion actions here...
    if engaged = NO
      SendMIDICC 1, 36, 127
      engaged = YES
    endif
    // Log {Chan. }, (exp_ch+1), { - cc}, exp_cc, {: }, value
@End

@Stopped
  engaged = NO
  SendMIDICC 1, 36, 0
  // Log {Waiting for movement...}
@End

btw, when you post code, if you put three back-ticks on a line by themselves before and after the code block, it'll stop the forum from messing with the formatting.

ztones

That's on for me, but there's no way for me to route anything to Tonestack in AUM.

Do you have the second toggle on for virtual devices turned on?

espiegel123

@wim : Tonestack Pro' MIDI AU has some odd behaviors. In Loopy Pro, to get midi to it you send it to Loopy Pro's virtual out port....and someone reported some behavior that implies that sometimes it is listening to MIDI hardware ports even if you have turned off the setting to listen to external MIDI.

wim

@espiegel123 said:
@wim : Tonestack Pro' MIDI AU has some odd behaviors. In Loopy Pro, to get midi to it you send it to Loopy Pro's virtual out port....and someone reported some behavior that implies that sometimes it is listening to MIDI hardware ports even if you have turned off the setting to listen to external MIDI.

What's really weird is @ztones has ToneStack showing in his AUM routing matrix. With the same settings I don't get that unless I run the standalone alongside AUM, and even then I can't route midi to the AU like they can, only to the standalone.

I'm too lazy to bust out my expression pedal to find out.

wim

@ztones said:

That's on for me, but there's no way for me to route anything to Tonestack in AUM.

Do you have the second toggle on for virtual devices turned on?

yup. 🤷🏼‍♂️

ztones

@wim said:
OK, that's odd, but if it works, it works. Here's the way to stop the spammed cc 36 messages. Note the changes to @OnLoad, @InMotion, and @Stopped.

@Description
Listen for a changing cc value and do one thing if values are changing and another if not.
Switch to log view for this demo.
@End

@OnLoad
  exp_ch = 0          // The channel to listen to
  exp_cc = 24         // The message to listen for
  timeout = 2000      // Wait time to detect stopped movement
  
  lastTime = -1
  value = -1
  lastValue = -1
  running = NO
  SetTimerInterval 10  //Increase if CPU use is too high (unlikely)
  
  if Unassigned engaged
    engaged = NO
  endif
  
  Log {Waiting for movement...}
@End

@OnMidiCC
  if (MIDIChannel = exp_ch) and (MIDIByte2 = exp_cc)
    value = MIDIByte3
    lastTime = SystemTime
    if not running
      StartTimer
      running = YES
    endif
  else
    SendMIDIThru
  endif
@End

@OnMidiInput
  // Pass all other MIDI Thru (cc messages are handled above)
  if MIDICommand <> 0xB0  //CC message
    SendMIDIThru
  endif
@End

@OnTimer
  now = SystemTime
  if (now - lastTime) < timeout
    // Take the in-motion action, but only after checking that values have 
    // actually changed, to avoid spamming unnecessary messages.
    if value <> lastValue
      lastValue = value
      Call @InMotion
    endif
  else
    // Take the stopped action
    StopTimer
    running = NO
    Call @Stopped
  endif
@End

@InMotion
    // Substitute your own in-motion actions here...
    if engaged = NO
      SendMIDICC 1, 36, 127
      engaged = YES
    endif
    // Log {Chan. }, (exp_ch+1), { - cc}, exp_cc, {: }, value
@End

@Stopped
  engaged = NO
  SendMIDICC 1, 36, 0
  // Log {Waiting for movement...}
@End

btw, when you post code, if you put three back-ticks on a line by themselves before and after the code block, it'll stop the forum from messing with the formatting.

Thank you! Much appreciated! I'm thinking I should keep that hardware midi toggle off in tone stack just so things don't get messy in the future when I may not want certain things getting through. I would have 100% control through Mosaic. Wouldn't you agree? However that leads me to my next question, what's the best way to allow the CC for the pedal get through?

espiegel123

@ztones: are you running tonestack pro only as an AU or is the standalone running, too? If you reboot and launch AUM and load ToneStack Pro as an AU without launching the standalone, is that virtual midi port showing up?

Also, what OS are you running? There was an OS bug a few ios generations back where bogus midi ports were visible for apps that had run in the past.

ztones

I am running IOS 17.6.1. So…strange…I rebooted. Started AUM and TS was still listed in the virtual midi ports. However, even when I turned on that switch referenced earlier, my pedal was still NOT working like it was before. So now my pedal is not working at all. Then I turned that 2nd switch off (virtual ports) and the TS listing in connections disappeared. So now I don’t have it either. I must have at some point had the standalone running, but why it was still there after reboot and now it isn’t ??? Who knows.. TS has some great effects but sure has a wonky MIDI implementation!

ztones

@wim Code works perfectly! Only a single CC36, 127 is sent! Awesome! Thank you so much!

So now I just need to get CC 24 through again (through the code) and if possible, to implement the double/triple and perhaps long-hold functionality, you would make my post hurricane FL Sunday ever brighter! .

wim

@ztones said:
@wim Code works perfectly! Only a single CC36, 127 is sent! Awesome! Thank you so much!

So now I just need to get CC 24 through again (through the code) and if possible, to implement the double/triple and perhaps long-hold functionality, you would make my post hurricane FL Sunday ever brighter! .

Well, there's the problem. It's easy enough to let CC24 through. Just modify @OnMidiCC like so:

@OnMidiCC
  if (MIDIChannel = exp_ch) and (MIDIByte2 = exp_cc)
    value = MIDIByte3
    lastTime = SystemTime
    if not running
      StartTimer
      running = YES
    endif
  endif
  SendMIDIThru
@End

But now, how can we route Mozaic's output to ToneStack??

wim

@ztones - It won't be much use going further until the Tonestack routing issue is understood, but I did find the script I wrote over four years ago for the BlueBoard. It only supports four switches, but could be extended to eight I think. It sends on different midi channels depending on the type of tap: single, double, triple, hold, single+hold, and double+hold. It would also need to be modified to work with CC's rather than notes, but that probably wouldn't be too hard.

It's a complex script, so it would probably be better to keep separate from your script. It could aways be placed "upstream" of your script and your script could just react to the midi coming from it.

The script is called BlueMozaic. It replicates the functionality of the Blue Velvet Streambyter script, which could also be used. I never published it on patch storage but it was tested thoroughly by forum member @Janosax.

I'll post it below in case you're interested. As you can see, it's fairly involved...

@Description
BlueMozaic aims to be functionally equivalent to the Blue Velvet Streambyter script. The channel of the Blueboard messages is altered according to the combination of short and long presses.

* version 0.2 (beta)
* Switch to the Log tab. Logging can be customized in the @Logger section.
* There are two timeouts, one for the first tap and another for subsequent taps. Adjust to taste.
@End

@OnLoad
  // timer[0] is for first tap timer[1] for subsequent taps
  // adjust to taste.
  timeout = [300, 400]
  timer = 0
  
  // change this to NO if you don't want logging
  logging = YES
  
  // timer interval in ms - lower values increase accuracy but too low might lead to 
  // missed detections due to race conditions.
  interval = 10
  
  // midi channel for each type of detection
  single = 2
  double = 4
  triple = 6
  hold = 1
  singleAndHold = 3
  doubleAndHold = 5
  bbChannel = 0
  
  // tracking variables
  taps = 0
  longPress = NO
  downtime = 0
  down = NO
  
  // BlueBoard messages
  bbChannel = 0
  bbNotes = [60, 62, 64, 65]
  bbVelocity = 100
    
  SetTimerInterval interval
  //StartTimer
  
  LabelKnobs {BlueMozaic v0.2           See LOG tab}
    
@End

@OnMidiNoteOn

  Call @CheckNote
  if isBBNote
    
    // first tap can have a different timeout than subsequent taps
    // configure these in timer[ ] array in @OnLoad
    if taps = 0
      timer = 0
    else
      timer = 1
    endif
    
    // reset if more than three taps
    if taps = 3
      taps = 0
    else
      Inc taps
    endif
    
    down = YES
    downTime = SystemTime
    StartTimer
  endif
  
@End

@OnMidiNoteOff
  Call @CheckNote
  if isBBNote
    down = NO
  endif
@End

@OnTimer

  time = SystemTime - downtime
  
  // take immediate action on timeout
  if time >= timeout[timer]
    if down = YES
      // the last tap was really a long tap, so roll it back
      Dec taps
      longPress = YES
    else
      longPress = NO
    endif
    
    StopTimer
    
    if longPress = YES or taps > 0
      Call @SendMessage
    endif
    
  endif
  
@End

@SendMessage
  channel = -1
  
  if longPress = NO
    if taps = 1
      channel = single
    elseif taps = 2
      channel = double
    elseif taps = 3
      channel = triple
    endif
  elseif longPress = YES
    if taps = 0
      channel = hold
    elseif taps = 1
      channel = singleAndHold
    elseif taps = 2
      channel = doubleAndHold
    endif
  endif
  
  if channel <> -1
    SendMIDINoteOn channel,MIDINote,bbVelocity
    Call @Logger
    
    // Do cleanup for the next detection
    downTime = 0
    longPress = NO
    taps = 0
    down = NO
  endif
@End

@Logger
  // Note: channels are logged as scripts use them (0-15), change channel to (channel+1)
  // if you prefer channels logged as 1-16.
  
  if logging = YES
    if longPress = YES
      Log {Taps: }, taps, {, Hold: Yes}, {, Ch: }, channel, {, Note: (}, MIDINote, {) }, (NoteName MIDINote,YES), {, Vel: }, bbVelocity, {, Timeout: }, time, {ms}
    else
      Log {Taps: }, taps, {, Hold: No}, {, Ch: }, channel, {, Note: (}, MIDINote, {) }, (NoteName MIDINote,YES), {, Vel: }, bbVelocity, {, Timeout: }, time, {ms}
    endif
  endif
  
@End

@CheckNote
  isBBNote = NO
  if MIDIChannel = bbChannel
    for idx = 0 to 3
     if MIDINote = bbNotes[idx]
       isBBNote = YES
     endif
    endfor
  endif
@End

ztones

So I think I finally figured out how to get midi into Tonestack and how to make it stick! I did have to fire up the standalone version to make the midi port to show up in AUM midi routing. Then in my preset (inside TS) I setup the midi CC's and saved it as the default midi mapping for the unit. I also had to turn on the "Load CC Map from Patch" and the "Load Unit Default Map on Add". (not sure if the later was necessary, but I did and it works.) Same thing inside the plugin settings. After that I was able to reboot my laptop, NOT start TS standalone. Midi connection in AUM shows a broken icon for TS, BUT (!!!!) it still works! CC's are getting inside TS and wah pedal (in my case) and moving!

ztones

@wim I took a look at the multi-tap script. Yeah, very involved and impressive! This still seems to work with timers right? You and @espiegel123 mentioned timers may not have to be involved. Would that make it a simpler approach or would it also introduce some limitations? What I like to achieve is stepping on my foot controller buttons that sends out CC's. Currently it is set to activate the pads in mosaic. So the pads send out PC and pads get triggered via AUM controls by my pedals. What I would like is to be able to multi press my foot controller buttons and send out various messages from mosaic. So what is my best path forward? Editing the BlueMosaic script for CC (extending it to 8 buttons/pads if possible) or using the non-timer involved method? Either way I definitely need your help as this is above my head at this point.

wim

@ztones said:
@wim I took a look at the multi-tap script. Yeah, very involved and impressive! This still seems to work with timers right? You and @espiegel123 mentioned timers may not have to be involved. Would that make it a simpler approach or would it also introduce some limitations? What I like to achieve is stepping on my foot controller buttons that sends out CC's. Currently it is set to activate the pads in mosaic. So the pads send out PC and pads get triggered via AUM controls by my pedals. What I would like is to be able to multi press my foot controller buttons and send out various messages from mosaic. So what is my best path forward? Editing the BlueMosaic script for CC (extending it to 8 buttons/pads if possible) or using the non-timer involved method? Either way I definitely need your help as this is above my head at this point.

If I remember correctly the timer was necessary because of the particular requirements of that script. I'd have to refresh my memory - it's been four years. I think it's because on a long press, the message is sent out after a certain delay and doesn't need to wait for you to release the button.

I recommend not trying to incorporate this tap-detect script into yours, but rather to put it between your script and the pedal. It needs to be modified to accept CC's rather than notes, and to support eight buttons. I'll take a look later today to see how much work that might be. If your foot switch can be configured to send notes instead of CC's that would make things easier, but I suspect I can also alter it to work with CC's.

ztones

I recommend not trying to incorporate this tap-detect script into yours, but rather to put it between your script and the pedal. It needs to be modified to accept CC's rather than notes, and to support eight buttons. I'll take a look later today to see how much work that might be. If your foot switch can be configured to send notes instead of CC's that would make things easier, but I suspect I can also alter it to work with CC's.

Yeah, I put it into another instance of Mosaic, took your advice not to mess up the scripts. My foot controller has either PC or CC options only, but I suppose that could be converted somewhere if editing the script for CC's turns out to be too difficult.

I'm just stabbing at "beginner's luck", but what about making the pads in mosaic send out notes and then I'll trigger the pads with my cc's? Thank you kindly for your time!

wim

@ztones said:

I recommend not trying to incorporate this tap-detect script into yours, but rather to put it between your script and the pedal. It needs to be modified to accept CC's rather than notes, and to support eight buttons. I'll take a look later today to see how much work that might be. If your foot switch can be configured to send notes instead of CC's that would make things easier, but I suspect I can also alter it to work with CC's.

Yeah, I put it into another instance of Mosaic, took your advice not to mess up the scripts. My foot controller has either PC or CC options only, but I suppose that could be converted somewhere if editing the script for CC's turns out to be too difficult.

It doesn't look like it will be hard to modify. I'll work on it some today.

I'm just stabbing at "beginner's luck", but what about making the pads in mosaic send out notes and then I'll trigger the pads with my cc's? Thank you kindly for your time!

That's what I recommend. Send the pedal to the script I'm modifying. From that script you'll get the CC from your pedal, but on a different midi channel depending on which tap type was detected. In your script you can do whatever you need to with the CC's arriving from the first script. You don't need to trigger pads to alter the midi messages sent out, but you can if that helps to visualize better.

Just realize that in Mozaic scripts, code to work with buttons labels, etc is often more complex than just dealing with midi messages. It's pretty simple to just detect a particular midi message and convert it to another message. Updating a pad's label and color takes more code than simply doing that.

You might even want to consider not bothering with another script. The messages that come out of this new script I'll provide can be directly mapped to any controls you need in AUM. If they do need to be converted, mfxConvert can do many such conversions without any coding.

wim

@ztones - a bit of clarification please ...
Will any of the output from the foot switches go to ToneStack?

If so, I need to do some checking to see if ToneStack can even receive from a Mozaic script. So far it's looking like maybe it's listening directly to the hardware pedal. If that's true then no script is going to help because it won't be able to intercept the midi between the pedal and ToneStack.