Audiobus: Use your music apps together.

What is Audiobus?Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.

Download on the App Store

Audiobus is the app that makes the rest of your setup better.

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

135

Comments

  • wimwim
    edited July 2020

    I think it's easier just to avoid the four notes used by the BlueBoard from the notes that go to GTL than to get into channel filtering, etc. The problem with the LEDs isn't random. It's predictable and of a known cause. My assumption that the BlueBoard only listens on channel 0 was wrong. It listens on all channels.

    I think double-tap, triple-tap can be avoided and still make it possible to expand the number of workspaces. Let's call our existing workspaces A-D. If we're in workspace A and long-press switch A again, it could toggle a workspace (call it A2) on and off. This would give up to four more workspaces easily. You could go as many layers deep as you wanted.

    As for visual indication, I would have A2 light up switch A and B, B2 would light B and C, C2 would light C and D. What to do with D2 ... I dunno maybe don't have a D2, or maybe light D and A.

    Anyway, this gets rid of the need for tap-dance lessons. Double-tap, etc is really tough to do on those switches. It's not that they bounce or anything (they don't) it's just hard to get the timings right (I've tried). Keeping it restricted to Long-press vs. tap keeps it way simpler.

    I'm working on a script that will go this route. It will also have some visual feedback in the plugin for the work space and the last tapped switch, settable outbound messages, and will support both modes of the BlueBoard (Notes and CC's). I've no timetable for this one and may or may not publish it anyway, so @josh83, you should plan on completing your own script. Don't wait on me. B)

  • edited July 2020

    Very interesting approach, very clever and good job, I have to try that!!!

    One limitation however is that you can access only 4 actions per workspace, so when you will need to go back and forth between workspaces often that will be a lot of hold actions to do and that will be hard to trigger while playing. But like I said in the other thread, the goal here is to find an approach which fits individual musical, creative and performance needs so multiple paths are possible.

    I use all backlits ON on the BB via MidiFire for using it in the dark. I use a very simple code:

    IF LOAD
    SND 90 3C 7F
    SND 90 3E 7F
    SND 90 40 7F
    SND 90 41 7F
    END

    Filtering in Mozaic should be made in the initial script, not in the routing IMO, because this is different from what I do with all ON/OFF rules installed manually.

    @_ki Any reasons for that huge 200 ms delay in this Mozaic multiple taps script? MidiFire works properly with a double 60ms (simple and hold taps) and 80 ms (tap + hold, triple taps, etc) delay setup, and it’s more dependent on foot speed aka proper script recognition. I’m super happy with MidiFire but I need an app setup backup as every app can be abandoned...

  • edited July 2020

    Hey guys, this is so great that my simple idea gives you new inspirations! :smiley:

    In general: after trying to work with double taps etc. for a short while, I also realised that my "tap dancing" skills are not enough, especially when performing live. So I came up with the long-hold idea, which is much simpler to accomplish.

    I love many of your suggestions, and I see good ways to implement their advantages and reduce their drawbacks. For example, to avoid a general delay resulting from implementing double taps, double tapping should only be available in specific situations, and not as a general thing. For example, only in Workspace B, the keys A and C would listen to double taps (both of which would not have any time sensitive functions). This adds some complexity to the code, but it could be worth it!

    In addition to that, most functions that I want to do in a live looping sessions are not overly time critical (thanks to GTL's CUE feature). And if there's a way to know about the looper's time/rhythm situation and thus delaying some functionality and let Mozaic fire it in the right situation, it would even more reduce time-criticalness of manual pressing. For example, to switch between two Tonebridge presets while recording two loops in a row, the switching needs to take place exactly between the 1st loop ends and the 2nd loop starts. This could be something that could easily be left to the script. But I don't know what time/rhythm info is available from GTL (it uses Ableton Link). This is definitely something I want to inspect deeper soon, so if anybody has some idea or even code fragments, please share!

    I also love the idea of displaying workspaces A2, B2, etc. by letting all buttons glow except the workspace's one.

    I'll be offline for a few days but will definitely check back. Thanks guys for this very inspiring and nourishing exchange of ideas, experience and knowledge.

  • @josh83 said:
    In addition to that, most functions that I want to do in a live looping sessions are not overly time critical (thanks to GTL's CUE feature). And if there's a way to know about the looper's time/rhythm situation and thus delaying some functionality and let Mozaic fire it in the right situation, it would even more reduce time-criticalness of manual pressing. For example, to switch between two Tonebridge presets while recording two loops in a row, the switching needs to take place exactly between the 1st loop ends and the 2nd loop starts. This could be something that could easily be left to the script. But I don't know what time/rhythm info is available from GTL (it uses Ableton Link). This is definitely something I want to inspect deeper soon, so if anybody has some idea or even code fragments, please share!

    Since both AUM and GTL are using Link, you can leverage @OnNewBar for timed actions. GTL and AUM should be on the same sync quantum, so you shouldn't need to worry about GTL providing any bar information.

    I also love the idea of displaying workspaces A2, B2, etc. by letting all buttons glow except the workspace's one.

    Ahh. That is a good solution. Better than I had figured out. I'm gonna steal that one.

  • edited July 2020

    @wim said:
    Since both AUM and GTL are using Link, you can leverage @OnNewBar for timed actions. GTL and AUM should be on the same sync quantum, so you shouldn't need to worry about GTL providing any bar information.

    Very good to know. Does AUM also know anything about GTL's longest currently running loop? I.e. how many bars it still takes until the current group repeats (or switching to another group is possible)?

  • wimwim
    edited July 2020

    @Janosax said:
    @_ki Any reasons for that huge 200 ms delay in this Mozaic multiple taps script? MidiFire works properly with a double 60ms (simple and hold taps) and 80 ms (tap + hold, triple taps, etc) delay setup, and it’s more dependent on foot speed aka proper script recognition. I’m super happy with MidiFire but I need an app setup backup as every app can be abandoned...

    Answering for myself, the 200ms is just an arbitrary amount based on personal preferences. 65ms is too short for me. If doing double tap detection, 65 is definitely better because you don't want to have to wait 400ms to detect what's going on. But, this changing control sets thing isn't very time dependent.

    Like you've said, it all comes down to personal workflow. I have a tremendously difficult time with anything time sensitive with foot taps on the BlueBoard, so need something with larger tolerances for error than 65ms. ;)

  • I have set the timeout for long taps to even 300ms at the moment! :tongue:

  • wimwim
    edited July 2020

    @josh83 said:

    @wim said:
    Since both AUM and GTL are using Link, you can leverage @OnNewBar for timed actions. GTL and AUM should be on the same sync quantum, so you shouldn't need to worry about GTL providing any bar information.

    Very good to know. Does AUM also know anything about GTL's longest currently running loop? I.e. how many bars it still takes until the current group repeats (or switching to another group is possible)?

    No, it doesn't know anything about what's going on in GTL. But they should** both know when Link's bar beginnings come along. So, you'd either have to hit your button somewhere in the last measure, then defer the resulting action until the next bar start.

    ** not tested, but based on my meager understanding of Link

  • edited July 2020

    @wim said:
    No, it doesn't know anything about what's going on in GTL. But they both know when Link's measures come along. So, you'd either have to hit your button somewhere in the last measure, then defer the resulting action until the next bar start.

    Hm I don't understand this yet. Where can I find more information about Link, so I can learn the vocabulary of it? And what do you mean with "either"? Where's the "or"? :smile:

  • wimwim
    edited July 2020

    Sorry either I made a typo. ;)

    https://ableton.github.io/link/

  • @wim Adding a second level of workspaces if one long-taps the current active workspace button is a clever idea. A lot better than adding double-taps detection with its delay all actions :)

    .

    @Janosax Regarding the delay used in the pad interaction demo - the 200msec were just a number i came up after testing. I logged the timing i was able to achieve on the pads, but wanted to be sure that slower double-taps are picked up as i don‘t know how fast other people can double-tap (not that i get complaints that the script isn’t working). The delay time is configurable in the script snippet.

  • @_ki said:
    @wim Adding a second level of workspaces if one long-taps the current active workspace button is a clever idea. A lot better than adding double-taps detection with its delay all actions :)

    It just adds another level of complexity in the way that you're not able to access the functions of A and A2 at the same moment, but you have to manually switch between the spaces. I think it's a matter of preference and whether you need to access the functions within a short amount of time. And again: one idea doesn't rule out the other! Yay!

  • edited July 2020

    About triggering abilities, I don’t know if that’s something obvious or not, but I strongly advice to practice on the BlueBoard with hand first, then foot. Become familiar with all actions in GroupTheLoop/LoopyHD and other effects. This will help when you will add instrument playing. Anticipation is the key. Practice as often as possible, everyday is the best way to get better and help muscle memory do its job.

  • @Janosax said:
    About triggering abilities, I don’t know if that’s something obvious or not, but I strongly advice to practice on the BlueBoard with hand first, then foot. Become familiar with all actions in GroupTheLoop/LoopyHD and other effects. This will help when you will add instrument playing. Anticipation is the key. Practice as often as possible, everyday is the best way to get better and help muscle memory do its job.

    Yes, I definitely need to practice much, much more with the BlueBoard and with looping in general. Thanks for all your inspiring posts on the subject. I've learned a lot and expanded my skills somewhat. I think I mostly need to work harder at refining my workflow, then stick with one workflow and practice, practice, practice. 👍🏼

    I'm always so amazed at what skilled performers can do with looping. We have some amazing people playing at restaurants, etc. where I live (well at least before the KillJoy-19 virus anyway). The gap between where they are and where I am is immense. 😂

  • "KillJoy-19"

    Gotta love it! 👍🏻

  • edited July 2020

    @wim said:

    @Janosax said:
    About triggering abilities, I don’t know if that’s something obvious or not, but I strongly advice to practice on the BlueBoard with hand first, then foot. Become familiar with all actions in GroupTheLoop/LoopyHD and other effects. This will help when you will add instrument playing. Anticipation is the key. Practice as often as possible, everyday is the best way to get better and help muscle memory do its job.

    Yes, I definitely need to practice much, much more with the BlueBoard and with looping in general. Thanks for all your inspiring posts on the subject. I've learned a lot and expanded my skills somewhat. I think I mostly need to work harder at refining my workflow, then stick with one workflow and practice, practice, practice. 👍🏼

    I'm always so amazed at what skilled performers can do with looping. We have some amazing people playing at restaurants, etc. where I live (well at least before the KillJoy-19 virus anyway). The gap between where they are and where I am is immense. 😂

    I’m sure you will have lot of fun. Just find what you want to achieve and how, practice and always search for fun. We are so lucky to have such great tools today to make music in new ways. Also glad to give some inspiration to some of you with my own process description :)

  • @Janosax - if you're interested in seeing what a script that mimics your StreamByter script looks, I may be able to recreate it if you provide me the StreamByter script. Then you can decide whether or not Mozaic is suitable as a "backup" in case StreamByter becomes no longer available.

  • edited July 2020

    @wim thanks a lot, I’m super interested!!
    I will send you a pm :)

  • @wim said:
    @Janosax - if you're interested in seeing what a script that mimics your StreamByter script looks, I may be able to recreate it if you provide me the StreamByter script. Then you can decide whether or not Mozaic is suitable as a "backup" in case StreamByter becomes no longer available.

    Keep us updated about it, please!

  • edited July 2020

    So I wanted to play around a little more with making the BlueBoard's buttons glow, but I had several strange side-effects whose causes I couldn't track down completely (especially when re-uploading scripts there seemed to be some strange after-effects of the previous upload).

    I hoped that resetting all buttons (making them un-glow) would fix it, so I wrote the following script just for testing purposes, and surprisingly it doesn't un-glow all the buttons and then glow button C. Instead, nothing happens at all (even an already glowing pad doesn't un-glow).

    Can anyone see the problem?

    // Make sure to start the BlueBoard while pressing the B pad!
    @OnLoad
      bbA_in = 60
      bbB_in = 62
      bbC_in = 64
      bbD_in = 65
    
      bbChannel = 0   // BlueBoard's channel => do not change this!
    
      Call @UnglowEverything
      Call @GlowC
    @End
    
    @UnglowEverything
      Log {Unglowing everything!}
    
      SendMidiNoteOff bbChannel, bbA_in, 100
      SendMidiNoteOff bbChannel, bbB_in, 100
      SendMidiNoteOff bbChannel, bbC_in, 100
      SendMidiNoteOff bbChannel, bbD_in, 100
    @End
    
    @GlowC
      Log {Glowing C!}
    
      SendMidiNoteOn bbChannel, bbC_in, 100
    @End
    
    
  • Sorry, i don‘t see the problem. Your code sends four note-offs with the correct blueboard notes and then a note-on for led-c.

    Maybe the note-on is ‚too fast‘ for the BlueBoard to chatch, as it is send right after the note-offs. As a test, try adding a delay of 100ms as last param to the SendMidiNoteOn.

    For completenes, i nedd to ask: Did you route the output correctly to the Blueboard ?

  • @josh83 - it works here. I think it must be your routing.

    It makes no functional difference, but I would send velocity zero, not 100 for the note off messages SendMidiNoteOff, bbChannel, bbB_in, 0.

    Also, the bbChannel isn't significant as the bb LEDs will light in response to any channel. Just a reminder in case you're tempted to rely on the channel to filter messages. It won't work. Note 60, 62, 64, or 65 sent to the bb will light the LEDs. When you have a routing to the bb, you have to avoid sending those notes except when you want to light the leds. Or you need to put a channel filter between Mozaic and the bb to filter out all but your designated bb channel.

  • Hey guys

    It's really freaking me out. I tried a lot with restarting AUM, the BlueBoard, re-creating channels and projects within AUM, and there's definitely something suspicious going on here.

    While sometimes it's working pretty well, other times it doesn't work at all. And it never worked 100% as expected so far.

    To prove it I made a short video, where you can see exactly what I'm doing. The script is now available on GitHub, see https://github.com/jmuheim/mozaic-blueboard/blob/master/script. Maybe you want to work with me there?

    And please can someone try to reproduce the problem?

    Here's the exact sequence of the buttons I pressed:

    • (Starting with glowing A)
    • C
    • B
    • D
    • A
    • C => two glowing buttons A and C!
    • B
    • A
    • C
    • D
    • B
    • A
    • C
    • B
    • A
    • C => again two glowing buttons A and C!
    • D
    • C
    • B
    • A
    • D
    • C
    • B
    • A
    • C => again A and C!
    • D
    • B
    • C
    • A
    • D
    • B => now B and D!
    • C
    • ...

    I tried to reproduce it, but the same sequence doesn't result in the same problems.

    The good news is: this problem seems only related to making the buttons glow; the script itself in the background seems to yield the correct results (i.e. sending the correct MIDI).

    Any idea?

  • _ki_ki
    edited July 2020

    In your video you didn‘t do the advised channel filtering before sending the scripts output to the Blueboard - therefore also the notes for the ‚short taps‘ on channel 15 reach the BlueBoard, maybe these notes are causing the troubles.

    You need to add a filtering midi plugin instance before sending out to the BlueBoard, either a mfxStrip, a StreamByter without script (so it only forwards) or another Mozaic instance with the minimal script i supplied and then setup AUMs input filtering for this intermediate instance to only allow channel 1

    BB -> JoshuaScript -> AUM channel 1 input filter -> midi forward plugin -> BlueBoard

  • edited July 2020

    @_ki said:
    In your video you didn‘t do the advised channel filtering before sending the scripts output to the Blueboard - therefore also the notes for the ‚short taps‘ on channel 15 reach the BlueBoard, maybe these are causing the troubles.

    You need to add a filtering midi plugin instance before sending out to the BlueBoard, either a mfxStrip, a StreamByter with script or another Mozaic instance with the minimal script i supplied and then setup AUMs input filtering for this intermediate instance to only allow channel 1

    Oh - but I thought that I would not need any of this filtering if I didn't use (i.e. send) the MIDI codes of the 4 buttons?? I only use MIDI codes 0 to 15, and the BlueBoard has something around 60+.

  • _ki_ki
    edited July 2020

    I know that the notes for the BB or are in a different note range (0-15 vs 60+), but maybe there is still a problem.

    If i understood correctly, wim needed the filtering otherwise problems occured as the BB listens to all channels - if they implemented it ‚not 100% to their own spec‘ then the BB may react to several notes (maybe undocumented features, or side-effects)

  • edited July 2020

    I applied both the velocity 0 suggestion on SendMidiNoteOff suggestion (https://github.com/jmuheim/mozaic-blueboard/commit/77d1dacbae5f0b1213dd8164e64cd2a7cd3915fe) as well as the 100ms delay before SendMidiNoteOn (https://github.com/jmuheim/mozaic-blueboard/commit/c22d1439af9bc453b8740caf1a375109405e7e68). Didn't seem to change a thing.

    I then tried to add the channel filter that you suggest, @_ki. I'm not sure whether I've done it correctly:

    First I added another Mozaic instance:

    Then I added your script (although I don't really seem to understand what it's useful for... where does the filtering happen? It seems to just send through everything):

    Then I changed the route from BB (out of view on the left due to narrow iPhone screen) to Mozaic 1:1, then Mozaic 1:1 to Mozaic 1:2 for filtering, then Mozaic 1:2 to BB.

    Anyway, didn't change much, it still behaves very oddly. @wim could you please verify?

  • edited July 2020

    What's interesting is the fact that after sending some messages to the BB to make its buttons glow or unglow, after some time, the BB always stops reacting to any of the glow/unglow messages. I have to physically restart it (on/off) to make it work again. (Restarting AUM or reconnecting it using midimittr app doesn't have any effect.)

    This makes it even more clear that it has to do something with BB, and either we're not sending the right 100% messages, or its internal handling of those is buggy.

  • _ki_ki
    edited July 2020

    Yes, the script only routes through - the idea was to use the channel filtering of AUM instead of writing a more complex script.
    For this, open the plugin and press the ‚snake-like‘ cable icon in the window bar - this will show the popup i also used in my graphics. There you can select the input sources, and at the bottom of the list you select which channel AUM will forward to the plugin (and transpose all notes, apply a note range filter etc which we don‘t need in your case) .
    Press ‚None‘ and the „1“ to only select channel 1 to be send to the plugin.

    My first version of the intermediate script had a GUI with two knobs, one for the input channel and one for the output channel, with state saving and restoring knob positions etc.
    When trying out, i realized that i forgot about AUMs buildin filtering and that the plugin only needs to ‚forward‘ the midi after AUM did all the work :)

  • Ah, I see. Good to know.

    I changed the options there and now I only let channel 1 (resp. 0) through to the BlueBoard.

    Still, the BB is acting weird.

Sign In or Register to comment.