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.

MIDI sync / clock from iOS to external gear, 2019

13»

Comments

  • rs2000rs2000

    @[Deleted User] said:

    @rs2000 said:

    @[Deleted User] said:

    @rs2000 said:

    @[Deleted User] said:

    @rs2000 said:

    @[Deleted User] said:
    I believe the issue is 1ms or more jitter means phasing of the transients. Not only that it can double or completely cancel out a wave form.

    No! This is MIDI, no audio and 1ms was the measurement precision, not the actual MIDI clock!
    Guess I should have explained it better...

    I am referring to the midi jitter of 1ms or more?

    Again, it's the measurement interval. I could develop another utility with microsecond timestamp precision but that's not the point. On the receiver side, averaging the clock stream using windows of 100..200ms length will even out tiny jitter easily while keeping the clock slave instance fast enough to follow bpm changes. What do you mean by "cancel out" if not talking about audio? MIDI is a serial data stream with 100% fixed clock.

    MIDI clock over usb gives a jitter of 1ms or more meaning the generate audio also has this jitter to my understanding.

    Not if you sequence samples. It totally depends on the implementation on the client side and
    it's up to the client to do a little clock smoothing. It's not even that critical when triggering samples and sampled instruments, the real challenge is to synchronize audio tracks or loops with MIDI clock or Ableton LINK. One could just re-pitch the audio to always match the LINK or MIDI clock, but that would sound terrible. One could also just leave the audio clips as they are (like in Gadget for example) but that only works for short clips. So the apps that support it (like BlocsWave, LaunchPad, Loopy HD) have to do some kind of time stretching.
    Developers often follow an approach involving two steps: After smoothing out the incoming MIDI clock, when a tempo change occurs, the audio is time-compressed or -stretched using a real-time algorithm with lower quality while rendering the stretched loop in higher quality in the background. As soon as rendering is finished, the HQ stretched version is played instead.

    Long story short: Whenever possible, use the app with audio tracks as a clock master and the one with MIDI tracks or sequenced samples as a clock slave.
    And make sure you're using apps that have solid MIDI clock support.

    I think I stick with Ableton link when available and completely avoid the jitter issue.

    You're not using WiFi then? Jitter over WiFi is even higher 😯

  • BroCoastBroCoast

    @rs2000 said:

    @BroCoast said:

    @rs2000 said:
    .So the apps that support it (like BlocsWave, LaunchPad, Loopy HD) have to >do some kind of time stretching.

    Flux:FX does not do time stretching and gives 100% accurate loops when slaved to MIDI clock.

    Really? Almost forgot this one!
    Good to know.

    It does micro drift out of time eventually but that takes a while.> @rs2000 said:

    @[Deleted User] said:

    @rs2000 said:

    @[Deleted User] said:

    @rs2000 said:

    @[Deleted User] said:

    @rs2000 said:

    @[Deleted User] said:
    I believe the issue is 1ms or more jitter means phasing of the transients. Not only that it can double or completely cancel out a wave form.

    No! This is MIDI, no audio and 1ms was the measurement precision, not the actual MIDI clock!
    Guess I should have explained it better...

    I am referring to the midi jitter of 1ms or more?

    Again, it's the measurement interval. I could develop another utility with microsecond timestamp precision but that's not the point. On the receiver side, averaging the clock stream using windows of 100..200ms length will even out tiny jitter easily while keeping the clock slave instance fast enough to follow bpm changes. What do you mean by "cancel out" if not talking about audio? MIDI is a serial data stream with 100% fixed clock.

    MIDI clock over usb gives a jitter of 1ms or more meaning the generate audio also has this jitter to my understanding.

    Not if you sequence samples. It totally depends on the implementation on the client side and
    it's up to the client to do a little clock smoothing. It's not even that critical when triggering samples and sampled instruments, the real challenge is to synchronize audio tracks or loops with MIDI clock or Ableton LINK. One could just re-pitch the audio to always match the LINK or MIDI clock, but that would sound terrible. One could also just leave the audio clips as they are (like in Gadget for example) but that only works for short clips. So the apps that support it (like BlocsWave, LaunchPad, Loopy HD) have to do some kind of time stretching.
    Developers often follow an approach involving two steps: After smoothing out the incoming MIDI clock, when a tempo change occurs, the audio is time-compressed or -stretched using a real-time algorithm with lower quality while rendering the stretched loop in higher quality in the background. As soon as rendering is finished, the HQ stretched version is played instead.

    Long story short: Whenever possible, use the app with audio tracks as a clock master and the one with MIDI tracks or sequenced samples as a clock slave.
    And make sure you're using apps that have solid MIDI clock support.

    I think I stick with Ableton link when available and completely avoid the jitter issue.

    You're not using WiFi then? Jitter over WiFi is even higher 😯

    There is no jitter as Ableton Link is buffered. It's just big fixed amount of latency over wifi.

  • [Deleted User][Deleted User]
    edited July 2019

    @rs2000 said:

    @[Deleted User] said:

    @rs2000 said:

    @[Deleted User] said:

    @rs2000 said:

    @[Deleted User] said:

    @rs2000 said:

    @[Deleted User] said:
    I believe the issue is 1ms or more jitter means phasing of the transients. Not only that it can double or completely cancel out a wave form.

    No! This is MIDI, no audio and 1ms was the measurement precision, not the actual MIDI clock!
    Guess I should have explained it better...

    I am referring to the midi jitter of 1ms or more?

    Again, it's the measurement interval. I could develop another utility with microsecond timestamp precision but that's not the point. On the receiver side, averaging the clock stream using windows of 100..200ms length will even out tiny jitter easily while keeping the clock slave instance fast enough to follow bpm changes. What do you mean by "cancel out" if not talking about audio? MIDI is a serial data stream with 100% fixed clock.

    MIDI clock over usb gives a jitter of 1ms or more meaning the generate audio also has this jitter to my understanding.

    Not if you sequence samples. It totally depends on the implementation on the client side and
    it's up to the client to do a little clock smoothing. It's not even that critical when triggering samples and sampled instruments, the real challenge is to synchronize audio tracks or loops with MIDI clock or Ableton LINK. One could just re-pitch the audio to always match the LINK or MIDI clock, but that would sound terrible. One could also just leave the audio clips as they are (like in Gadget for example) but that only works for short clips. So the apps that support it (like BlocsWave, LaunchPad, Loopy HD) have to do some kind of time stretching.
    Developers often follow an approach involving two steps: After smoothing out the incoming MIDI clock, when a tempo change occurs, the audio is time-compressed or -stretched using a real-time algorithm with lower quality while rendering the stretched loop in higher quality in the background. As soon as rendering is finished, the HQ stretched version is played instead.

    Long story short: Whenever possible, use the app with audio tracks as a clock master and the one with MIDI tracks or sequenced samples as a clock slave.
    And make sure you're using apps that have solid MIDI clock support.

    I think I stick with Ableton link when available and completely avoid the jitter issue.

    You're not using WiFi then? Jitter over WiFi is even higher 😯

    its a set latency, its not jittering. That's the point to my understanding.

  • rs2000rs2000
    edited July 2019

    @BroCoast said:
    There is no jitter as Ableton Link is buffered. It's just big fixed amount of latency over wifi.

    There's no jitter when MIDI clock is buffered too - when done correctly.

    @[Deleted User] said:
    its a set latency, its not jittering. That's the point to my understanding.

    LINK usually uses UDP over WiFi and on a network with low load (!) the inter-arrival packet jitter is about 3..8ms. The difference is that with the LINK SDK, Ableton have done the hard work for developers already while with MIDI clock, the information is spread in tiny bits all over the net. I'm sure that's why some apps are great and some are barely usable in this regard.

  • ThinAirXThinAirX

    I'm the OP, reporting back for the benefit of future lurkers. I got MIDI clock working to sync external gear by using Loopy as the master. I've discovered that I can change the tempo in AUM or AB3 or Loopy and everything else syncs with it.

    I set MIDI Clock Out in AB3. Settings | Sync Settings | MIDI Clock Sync. | Destinations. I disabled it in AUM.

    For a long time I had the problem in which every time I changed the tempo it would jump to 400, or sometimes 999. Sometimes it would crash AB and AUM (I think from the centrifugal force of Loopy spinning around). Problem was caused by having MIDI Clock Sync in AB3 going both IN and OUT, source and destination, to/from the same DIN port. MIDI clock feedback, I guess.

    I did discover that Loopy has to be running or the MIDI clock is not sent out. As soon as I start it, it all syncs up. And the external gear stays at that setting even if I turn Loopy off.

    Once I got the clock going out the DIN port it was just a matter of reading the manuals for the external stomp boxes to get them to respond. It's fun changing the tempo in Loopy or AB and watching the changes cascade through the stomp boxes.

    Thank you for all your guidance.

    Steve
    ThinAirX.com

  • rs2000rs2000
    edited July 2019

    @ThinAirX said:
    I'm the OP, reporting back for the benefit of future lurkers. I got MIDI clock working to sync external gear by using Loopy as the master. I've discovered that I can change the tempo in AUM or AB3 or Loopy and everything else syncs with it.

    I set MIDI Clock Out in AB3. Settings | Sync Settings | MIDI Clock Sync. | Destinations. I disabled it in AUM.

    For a long time I had the problem in which every time I changed the tempo it would jump to 400, or sometimes 999. Sometimes it would crash AB and AUM (I think from the centrifugal force of Loopy spinning around). Problem was caused by having MIDI Clock Sync in AB3 going both IN and OUT, source and destination, to/from the same DIN port. MIDI clock feedback, I guess.

    I did discover that Loopy has to be running or the MIDI clock is not sent out. As soon as I start it, it all syncs up. And the external gear stays at that setting even if I turn Loopy off.

    Once I got the clock going out the DIN port it was just a matter of reading the manuals for the external stomp boxes to get them to respond. It's fun changing the tempo in Loopy or AB and watching the changes cascade through the stomp boxes.

    Thank you for all your guidance.

    Steve
    ThinAirX.com

    Thanks for posting!
    I bet that if more musicians took the time to set up everything properly, syncing iOS apps with gear over MIDI would be used a lot more.
    I love it. Although I prefer to have the hardware send MIDI clock and iOS apps receive it because I like to hit physical hardware transport buttons and turn bpm knobs B)

  • OptahealthOptahealth

    @knewspeak said:
    It is really saying something when an Atari ST holds better midi clock timing than practically every iOS app.

    Commodore Amiga too! I'm really stretching the memory banks here but I wanna say the Commodore 64 as well.

  • palmspalms

    @rs2000 said:

    @ThinAirX said:
    I'm the OP, reporting back for the benefit of future lurkers. I got MIDI clock working to sync external gear by using Loopy as the master. I've discovered that I can change the tempo in AUM or AB3 or Loopy and everything else syncs with it.

    I set MIDI Clock Out in AB3. Settings | Sync Settings | MIDI Clock Sync. | Destinations. I disabled it in AUM.

    For a long time I had the problem in which every time I changed the tempo it would jump to 400, or sometimes 999. Sometimes it would crash AB and AUM (I think from the centrifugal force of Loopy spinning around). Problem was caused by having MIDI Clock Sync in AB3 going both IN and OUT, source and destination, to/from the same DIN port. MIDI clock feedback, I guess.

    I did discover that Loopy has to be running or the MIDI clock is not sent out. As soon as I start it, it all syncs up. And the external gear stays at that setting even if I turn Loopy off.

    Once I got the clock going out the DIN port it was just a matter of reading the manuals for the external stomp boxes to get them to respond. It's fun changing the tempo in Loopy or AB and watching the changes cascade through the stomp boxes.

    Thank you for all your guidance.

    Steve
    ThinAirX.com

    Thanks for posting!
    I bet that if more musicians took the time to set up everything properly, syncing iOS apps with gear over MIDI would be used a lot more.
    I love it. Although I prefer to have the hardware send MIDI clock and iOS apps receive it because I like to hit physical hardware transport buttons and turn bpm knobs B)

    yeah, I agree about the physical controls being much preferred.

    I finally got AUM to sync to my Squarp Pyramid from AB3's midi sync running in the background. It kept losing connection, but the fix is to run at least one midi auv3 with link in AB3, otherwise it disconnects as soon as you leave the app.
    Syncs well, but the transport often starts 1 bar late. I'd love to have that sync self contained within AUM. Syncing directly in AB3 fixes the transport lag problem, but AUM is my daw of choice, with its multi-outs and superlative workflow.

  • rs2000rs2000
    edited July 2020

    @palms That's the problem with Ableton LINK. They could have implemented a timer that always runs and will allow a master/slave configuration with instant start from a pre-defined position but they missed the opportunity.
    If I remember correctly, the LINK protocol would allow a "master" to enforce a certain beat position but I'm not sure how the majority of LINK apps would handle that and if it would really enable instant start from 1:1.
    For now, MIDI clock is the only solution.
    But who knows, maybe @j_liljedahl is already at it ;)

Sign In or Register to comment.