Mozaic: How to detect a "long tap" (0.5secs) on my BlueBoard?

josh83

Yeah, this seems overkill.

I just asked in the GTL forums for some feature like this: https://forum.grouptheloop.com/index.php?p=/discussion/323/display-executed-midi-commands-in-some-notification/p1?new=1

wim

Woah ... hang on guys. This is so much easier than you think.

You can turn the BlueBoard LEDs on and off by sending the same notes to it that it sends out. SendMIDINoteOn, 0, 60, 100 will turn the button A light on, SendMIDINoteOff, 0, 60, 100 will turn it off.

So, all you need to do is set up a route from Mozaic to the BlueBoard, then add code to light the switches when you want. But, you will also need to hard-code your output channels and use a channel other than 0 for the GTL note-on/off messages.

_ki

Cool, then the rest is easy.

GroupTheLoop needs to only listen to channel 0 and the BlueBoard to channel 15.

@OnLoad
  SetShortName {Joshua} 

  Log {Joshua wants to be a pop band}
  // BlueBoard (BB) pads
  bbA_in = 60
  bbB_in = 62
  bbC_in = 64
  bbD_in = 65

  // BlueBoard pad states
  bbDown = 100
  bbUp   = 0

  spaceA = 0
  spaceB = 1
  spaceC = 2
  spaceD = 3

  activeSpace = spaceA

  bbOutChannel = 15
  SendMidiNoteOn bbOutChannel, bbA_in, 100
  SendMidiNoteOff bbOutChannel, bbB_in, 100
  SendMidiNoteOff bbOutChannel, bbC_in, 100
  SendMidiNoteOff bbOutChannel, bbD_in, 100
  bbLed = bbA_in

  longTapTime = 200 // Milli seconds
@End

@OnMidiNoteOn
  DownStartTime = SystemTime
@End

@OnMidiNoteOff
  If SystemTime - DownStartTime <= longTapTime
    Call @ShortTap
  Else
    Call @LongTap
  Endif
@End

@ShortTap
  // Log {Short Tap: }, MidiNote

  Call @SendNoteFromCurrentSpace
@End

@LongTap
  // Log {Long Tap: }, MidiNote

  Call @ActivateSpace
@End

@ActivateSpace
  SendMidiNoteOff bbOutChannel, bbLed, 0

  if MidiNote = bbA_in
    activeSpace = spaceA    
  elseif MidiNote = bbB_in
    activeSpace = spaceB
  elseif MidiNote = bbC_in
    activeSpace = spaceC
  elseif MidiNote = bbD_in
    activeSpace = spaceD
  else
    Log {ERROR - Unexpected MidiNote: }, MidiNote
  endif

  bbLed = MidiNote
  SendMidiNoteOn bbOutChannel, bbLed, 0
  Log {Activated space: }, activeSpace
@End

@SendNoteFromCurrentSpace
  baseNote = -1
  noteToSend = -1

  if activeSpace = spaceA
    baseNote = 0
  elseif activeSpace = spaceB
    baseNote = 4
  elseif activeSpace = spaceC
    baseNote = 8
  elseif activeSpace = spaceD
    baseNote = 12
  endif

  if MidiNote = bbA_in
    noteToSend = baseNote + 0
  elseif MidiNote = bbB_in
    noteToSend = baseNote + 1
  elseif MidiNote = bbC_in
    noteToSend = baseNote + 2
  elseif MidiNote = bbD_in
    noteToSend = baseNote + 3
  endif

  SendMidiNoteOn MIDIChannel, noteToSend, 100
  SendMidiNoteOff MIDIChannel, noteToSend, 0, 50
  Log {Sent Midi: }, noteToSend
@End 

If it is not possible to ‚limit‘ the input channel in either the BlueBoard or GroupTheLoop, you can use AUM to ‚split‘ the main midi stream into two different midi streams that can be routed individually

Add two instances of Moazic with this super-simple script

@OnMidiInput
  SendMidiThru
@End

Or use any other ‚midi-transparent‘ plugin, something that will just output the midi it was receiving (maybe StreamByter or mfxStrip, mfxConvert...)

Now

• No longer route the main script to GroupTheLoop
• The first instance reads from the main script, but limit its input to channel 0 using AUMs channel settings.
• Route the output of this first instance to GroupTheLoop
• The second instance reads from the main script, but limit its input to channel 15 using AUMs channel settings.
• Route the output of this second instance to the Blueboard

wim

@_ki said:
Cool, then the rest is easy.

GroupTheLoop needs to only listen to channel 0 and the BlueBoard to channel 15.

Actually, the BlueBoard can only listen to channel 0, GTL is going to need to listen on another channel, such as 15.

_ki

Or - in the simple script instances use

@OnMidiInput
  SendMidiThruOnCh 0
@End

So both new streams will send on channel 0 (regardless of input channel its filtered to) and still can be routed inpendently

wim

@_ki said:
Or - in the simple script instances use

@OnMidiInput
  SendMidiThruOnCh 0
@End

So both new streams will send on channel 0 (regardless of input channel its filtered to) and still can be routed inpendently

Eh? I don't get it. Unless I misunderstand you, I think you've got the wrong idea here. You can't pick which routing is going out of the Mozaic script, you can only pick channel. Both the BB and GTL are going to receive whatever comes out of Mozaic. BB will ignore anything not on channel 0. We don't want GTL reacting to the messages we send to the BB to turn LEDs on and off, so anything midi-learned in GTL needs to be on a different channel. Likewise we don't want the BB reacting to any messages we send to GTL. Since the BB can only listen to channel 0, we can't use channel 0 for GTL.

The Blueboard is sending on channel 0. It also has to receive on channel 0. The OP does not want the notes sent from the BB to trigger the LEDs. He wants the LEDs to be turned on and off at other times based on what the script is sending out to GTL. If the BB switch presses are echoed back to itself that will not accomplish this.

Since the BB can only receive on ch 0, GTL needs to listen on any other channel than 0. And 0 needs to be used to send separate commands to the BB to turn the lights on and off.

Maybe the misunderstanding is over the midi flow: Nothing is ever to passed from the BB thru to anything else here. The script is reacting to messages from the BB, then deciding on notes to send out to GTL and BB independently.

_ki

Hi @wim,

i meant a different routing incooperating the mini MidiThruTo scripts that i posted below the updated main script:

In the AUM midi matrix, you have two destinct MidiThruTo Moazic instances, GroupTheLoop reads from the one filtered to channel 1, the BlueBoard input comes from the other. I only added these instances to be able to direct their channel-filtered output to two different destinations in the midi matrix.
I used channel 1 to 16 in the diagram, since that’s what AUM channel filter displays, in the midi streams thats still channel 0 and 15)

@josh83
I also changed my latest posted version of the script to set all 4 LED states in the OnLoad, so that changing AUM sessions to a new one also incoorperating the BlueBoard script will now fully restore the LEDs. Please use the updated version

wim

.

josh83

Damn guys this looks really awesome!

I will take a look at it soon. But just for now: would it be possible to let more than one button glow at the same time? So I could use combinations of buttons to communicate different statuses?

josh83

@wim said:
.

So that's all you have to say?

_ki

Currently the LEDs should show the active space with a ‚permanent lit‘ led. The other presses are all less than the longTapTime, lighting these while beeing pressed would make the script a bit more complicated and i don‘t think it would help on stage since you still have to ‚find‘ the correct button while its unlit.

Showing some other state (mutes, solos, channel switches) with LED combinations would require the script to know what each of the output-notes changes in GroupTheLoop - not impossible to script, but very specific and in my eyes not as general as the current script is.

_ki

BTW: If the midi learn in Group the loop includes the channel (and not only the note), you could get rid of the extra instances. We just need to send the control notes on channel 15 and the blueboard led notes on channel 0.

For this just add & change in Onload

   ....
   mainChannel  = 15
   bbOutChannel = 0

And in SendNoteFromCurrentSpace

   ....
  SendMidiNoteOn mainChannel, noteToSend, 100
  SendMidiNoteOff mainChannel, noteToSend, 0, 50 

As wim stated, the BlueBoard will ony read notes from channel 1 (ie. internally bbOutChannel=0 ), and the midi learn of GroupTheLoop should learn the notes from channel 16 (ie. internally mainChannel=15). The channel 1 notes for the BlueBoard still reach GroupTheLoop, but since they are not learned i hope they don‘t do any harm.

No additional instances for channel separation needed, simpler setup etc - just like @wim suggested in his answer. I should have read it more carefully

josh83

I tried to follow your instructions, @_ki, but my BlueBoard's buttons do not glow when long-pressing.

Here's what's the code looks like:

@OnLoad
  SetShortName {Joshua} 

  Log {Joshua wants to be a pop band}
  // BlueBoard (BB) pads
  bbA_in = 60
  bbB_in = 62
  bbC_in = 64
  bbD_in = 65

  // BlueBoard pad states
  bbDown = 100
  bbUp   = 0

  spaceA = 0
  spaceB = 1
  spaceC = 2
  spaceD = 3

  activeSpace = spaceA

  mainChannel  = 15
  bbOutChannel = 0
  SendMidiNoteOn bbOutChannel, bbA_in, 100
  SendMidiNoteOff bbOutChannel, bbB_in, 100
  SendMidiNoteOff bbOutChannel, bbC_in, 100
  SendMidiNoteOff bbOutChannel, bbD_in, 100
  bbLed = bbA_in

  longTapTime = 200 // Milli seconds
@End

@OnMidiNoteOn
  DownStartTime = SystemTime
@End

@OnMidiNoteOff
  If SystemTime - DownStartTime <= longTapTime
    Call @ShortTap
  Else
    Call @LongTap
  Endif
@End

@ShortTap
  // Log {Short Tap: }, MidiNote

  Call @SendNoteFromCurrentSpace
@End

@LongTap
  // Log {Long Tap: }, MidiNote

  Call @ActivateSpace
@End

@ActivateSpace
  SendMidiNoteOff bbOutChannel, bbLed, 0

  if MidiNote = bbA_in
    activeSpace = spaceA    
  elseif MidiNote = bbB_in
    activeSpace = spaceB
  elseif MidiNote = bbC_in
    activeSpace = spaceC
  elseif MidiNote = bbD_in
    activeSpace = spaceD
  else
    Log {ERROR - Unexpected MidiNote: }, MidiNote
  endif

  bbLed = MidiNote
  SendMidiNoteOn bbOutChannel, bbLed, 0
  Log {Activated space: }, activeSpace
@End

@SendNoteFromCurrentSpace
  baseNote = -1
  noteToSend = -1

  if activeSpace = spaceA
    baseNote = 0
  elseif activeSpace = spaceB
    baseNote = 4
  elseif activeSpace = spaceC
    baseNote = 8
  elseif activeSpace = spaceD
    baseNote = 12
  endif

  if MidiNote = bbA_in
    noteToSend = baseNote + 0
  elseif MidiNote = bbB_in
    noteToSend = baseNote + 1
  elseif MidiNote = bbC_in
    noteToSend = baseNote + 2
  elseif MidiNote = bbD_in
    noteToSend = baseNote + 3
  endif

  SendMidiNoteOn mainChannel, noteToSend, 100
  SendMidiNoteOff mainChannel, noteToSend, 0, 50 
  Log {Sent Midi: }, noteToSend
@End 

Could there be any difference in BlueBoards? Mine is a very old version, which I updated with the newest firmware though.

wim

@josh83 said:

Could there be any difference in BlueBoards? Mine is a very old version, which I updated with the newest firmware though.

If you have the latest firmware then that isn't the problem. I think the only problem is with the velocity on the command to turn the LED on.

SendMidiNoteOn bbOutChannel, bbLed, 0

should be

SendMidiNoteOn bbOutChannel, bbLed, 100.

josh83

Doesn't seem to work. I tried the following dead simple script but it has no effect at all:

@OnLoad
  bbA_in = 60
  bbB_in = 62
  bbC_in = 64
  bbD_in = 65

  SendMidiNoteOn 0, bbA_in, 100
  SendMidiNoteOn 0, bbB_in, 100
  SendMidiNoteOn 0, bbC_in, 100
  SendMidiNoteOn 0, bbD_in, 100
@End

wim

@josh83 said:
Doesn't seem to work. I tried the following dead simple script but it has no effect at all:

@OnLoad
  bbA_in = 60
  bbB_in = 62
  bbC_in = 64
  bbD_in = 65

  SendMidiNoteOn 0, bbA_in, 100
  SendMidiNoteOn 0, bbB_in, 100
  SendMidiNoteOn 0, bbC_in, 100
  SendMidiNoteOn 0, bbD_in, 100
@End

Are you sure you have a routing in AUM from Mozaic to BlueBoard? Mozaic needs to be able to send to the BB to control the LEDs.

Your other script will require a route from the BB to Mozaic, and from Mozaic to both GTL and to the BB.

josh83

@wim said:
Are you sure you have a routing in AUM from Mozaic to BlueBoard?

Damn, so much to think about when learning to navigate a new eco system! I definitely did not have a routing, and now I have one, and it works beautifully!

Thanks so much for your patience, @wim! Good to have you guys on my side.

wim

@josh83 said:

@wim said:
Are you sure you have a routing in AUM from Mozaic to BlueBoard?

Damn, so much to think about when learning to navigate a new eco system! I definitely did not have a routing, and now I have one, and it works beautifully!

Thanks so much for your patience, @wim! Good to have you guys on my side.

No problem. @_ki did all the heavy lifting. I'm just the guy who happens to have a BlueBoard to do testing.

josh83

@wim said:
No problem. @_ki did all the heavy lifting. I'm just the guy who happens to have a BlueBoard to do testing.

Anyway, thanks to both of you guys! I would have already given up without your help, I'm pretty sure of that.

_ki

Cool that it works now and sorry for the led note-on velocity of 0, that slipped through.

@wim All main parts of the script were by josh83, i only did the bugfix and later added just a few lines for the led handling. Doing the graphics in Affinity Designer took some time, but was a nice diversion. And if i would have understood your idea, there would have been no need to create them at all

josh83

It's a team effort then!

I'll happily continue to code in a few days and keep you updated with news... and probably with a lot of questions!

wim

@josh83 - your idea for "workspaces" based on long-press is outstanding. I've never really come to grips with a good looping workflow with the BlueBoard.

@Janosax detailed a really good mapping setup that he uses with Loopy HD. The logic behind the mappings hasn't fully lodged in my brain. I'm sure would with more practice though. It's really well thought out.

Your way of grouping things under different modes activated by a long-press really resonates with me. I may be giving this a shot to see if I adapt more easily.

I'm so glad for all the creative input people share on this forum.

SNystrom

Definitely!

I've never coded in my life, but this thread and @josh83's earlier one (with the amazingly deep @Janosax contribution) may finally be the push to get me coding for my long-neglected Blueboard.

No quite clear on the concept and options within the "workspaces," but if it's what I believe it to be, it would make AUM vastly more valuable than it already is to me now.

Would love to see a video of it with the possible options with guitar.

Thanks, @josh83 for your meticulous and dogged persistence on expanding the functionality of the humble Blueboard.

wim

@SNystrom said:
Definitely!

No quite clear on the concept and options within the "workspaces," but if it's what I believe it to be, it would make AUM vastly more valuable than it already is to me now.

It's a tidy way of extending the number of messages you can send from the BlueBoard. You enter one of four "workspaces" by long-pressing a button. After that, normal-taps send out whatever notes you configured for that workspace. So, instead of just four possibilities you now have 16.

Would love to see a video of it with the possible options with guitar.

Well, I'm not gonna do a video, but one application could be to have one workspace controlling pre-amp FX, one controlling the amp, one for post-amp FX, and one for overall channel control (volume, mute, etc). It would really depend on your creativity.

Thanks, @josh83 for your meticulous and dogged persistence on expanding the functionality of the humble Blueboard.

This has really got me thinking now. There's no reason you couldn't go more levels deep. For instance long-pressing button A followed by long pressing button B gets you to a fifth workspace, etc. I can envision 64 controls easily accessible.

SNystrom

"Well, I'm not gonna do a video, but one application could be to have one workspace controlling pre-amp FX, one controlling the amp, one for post-amp FX, and one for overall channel control (volume, mute, etc). It would really depend on your creativity."

One option I would like is the ability to have one button to switch through the presets on TH-U, GE Labs or ToneStack, while the other buttons would turn various present effects off or on as needed and perhaps assign one of the two expression pedals to control a pot on an either an effect or amp.

When I first purchased my Blueboard I was rather disappointed in the "either/or" limitations the base software provided.

wim

Well, anything that you can midi learn can be controlled by the BlueBoard. The difference is, with a script like this, rather than having 4 basic choices, you can have 16 or even more to midi learn.

There are other approaches a script could take, such as sending different messages based on double-tap, etc. But I find @josh83 's "workplace" approach easier to get my head around and less needful of tap-dancing skills.

wim

Hey @josh83 - I just thought I'd let you know that I'm getting some inconsistent behavior from the BlueBoard. I've been turning on the LED of the switch corresponding to the active space. So far so good. But on my short-taps I'm sometimes getting random LEDs lighting.

The BlueBoard shouldn't be responding to these short taps because the messages are going out on channel 16. I've checked this carefully with a midi monitor. But sometimes at random the BlueBoard will turn on a LED when it shouldn't. I don't know the cause.

I just thought I'd let you know that there's something odd going on so that you don't tear your hair out looking for bugs in the code that may not be there.

SNystrom

Yeah, workplace will definitely be my first area of exploration.

wim

@josh83 - Follow up...

I found the issue. The BlueBoard is responding on ALL channels, not just channel 0 for the LED messages.

So, you have to avoid using the notes that the BlueBoard uses for your outbound notes to GTL. Or, block all but channel 0 going to the BlueBoard with an external tool such as Mozaic or mfxStrip.

_ki

For Mozaic‘s SHIFT button, we have script code to detect tap, hold, double-tap, double-tap hold etc, all based on the timing, but no ‚long tap‘ detection like you implemented in your code.

When mixing the ideas, i think with one’s foot one can easily do double-taps on the BlueBoard buttons which would add another layer of 4 workspaces.

There are some drawbacks:
1. All actions of the script are delayed until the analysis time runs up (≈200 msec). Currently everything happens on button release, so a fast tap does it‘s thing immediately
2. I don‘t know if the BlueBoard knobs ‚bounce‘ (sometimes double-trigger even when just pressed once) - bouncing would kill the idea of double-tap detection

To visually indicate the 4 new workspaces, i suggest to use ‚inverted‘ leds - a single lit led shows workspaces 1 to 4, and a single unlit led (three lit) shows workspaces 5 to 8 (on,off,on,on could indicate workspace 6). Both easy to read and understand in the heat of a live-gig.

.

@wim and @josh83 If there is a problem with the messages on channel 16, you could detour the midi meant for the BlueBoard through a

@OnMidiInput
  SendMidiThru
@End

script instance and apply an AUM filter to channel 1. This would remove all ‚channel 16‘ messages that seem to cause random problems.
Just like in my first graphics. But only do this for the BlueBoard midi, for the GroupTheLoop it’s not needed as channel filtering already works.