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.

StepPolyArp Unit/App sync and other issues

Hi,

I desperately try to use StepPolyArp or StepPolyArp with Audiobus and/or AUM. My use case is almost always the same. I define a chord progression in a MIDI sequencer (Xequence2 or Atom), I feed it to StepPolyArp, and it produces a bass line or a keyboard comping using the pattern I define and the chord it eats up. To this, I add a drum track using mostly Lumbeat apps.

At first, I was using StepPolyArp in the « middle slot » of Audiobus MIDI channel. For my use case, I understand that I should use StepPolyArp in ARP mode, and I am syncing it using Ableton Link.

My first issue is that with exactly the same setting, sometime it works (e.g. proper sync and notes going out of SPA), but sometimes it doesn’t (no note going out of StepPolyArp). I should also mention that I don’t have the feeling that the issue is with the upstream software (mainly Xequence), because if I put any other app instead of SPA in the middle slot, it works as expected. On the other hand, if I keep SPA and put another app in the input slot, it doesn’t work (even with ChordPolyPad).

My second issue is that I usually need two instances, so that I can produce the bass line and the chord comping. So I bought the « Unit » version, which was a bit unpleasant due to the price tag of each of this app. If I use the « Unit » version as the app, it seems to have the same behavior as the one I reported in previous paragraph. If I use the Audio Unit, I get another unexpected behavior: the note that should go first, doesn’t, so instead of starting my bass line on the root note, it starts on the second note... Which makes it quite unusable... (which is unacceptable due to the price tag of each of this app).

This is quite surprising, because the workflow I use seems quite straightforward. Does anyone got the same issue? Is there a known workaround?

Kind regards,
Pim

Comments

  • @Pim999 said:
    Hi,

    I desperately try to use StepPolyArp or StepPolyArp with Audiobus and/or AUM. My use case is almost always the same. I define a chord progression in a MIDI sequencer (Xequence2 or Atom), I feed it to StepPolyArp, and it produces a bass line or a keyboard comping using the pattern I define and the chord it eats up. To this, I add a drum track using mostly Lumbeat apps.

    At first, I was using StepPolyArp in the « middle slot » of Audiobus MIDI channel. For my use case, I understand that I should use StepPolyArp in ARP mode, and I am syncing it using Ableton Link.

    My first issue is that with exactly the same setting, sometime it works (e.g. proper sync and notes going out of SPA), but sometimes it doesn’t (no note going out of StepPolyArp). I should also mention that I don’t have the feeling that the issue is with the upstream software (mainly Xequence), because if I put any other app instead of SPA in the middle slot, it works as expected. On the other hand, if I keep SPA and put another app in the input slot, it doesn’t work (even with ChordPolyPad).

    My second issue is that I usually need two instances, so that I can produce the bass line and the chord comping. So I bought the « Unit » version, which was a bit unpleasant due to the price tag of each of this app. If I use the « Unit » version as the app, it seems to have the same behavior as the one I reported in previous paragraph. If I use the Audio Unit, I get another unexpected behavior: the note that should go first, doesn’t, so instead of starting my bass line on the root note, it starts on the second note... Which makes it quite unusable... (which is unacceptable due to the price tag of each of this app).

    This is quite surprising, because the workflow I use seems quite straightforward. Does anyone got the same issue? Is there a known workaround?

    Kind regards,
    Pim

    Hi! I had same issues with StepPolyArp in Audiobus+Xequence. No luck of finding workaround (I asked guys here on the forum few month ago). In NanoStudio it seems to work as expected

  • You could try playing around with sync in Xequence. Maybe you can send the chord a little early and see if that helps?

    Also have you spoken to the Xequence developer about this?

  • I also tried with Atom and it is not working properly: I still have my note sequence with the first note as the last one.

  • I wonder if SPA AU is Ableton Link start/stop enabled?

  • It doesn’t seem so. StepPolyArp can be Link synced, but not when used as a AU.

  • I guess as AU it works with the host.

  • Yes, but it stills starts arpeggiating from the second note. And I don’t think the problem is with Xequence, because it doesn’t work properly with Atom neither, and if I replace SPA by the Rozeta ARP, Rozeta starts arpeggiating by the proper note.

    I think this will ends by me looking for a replacement for SPA... But it’s a real shame, because it has interesting features.

  • edited March 2020

    @Pim999 said:
    Hi,

    I desperately try to use StepPolyArp or StepPolyArp with Audiobus and/or AUM. My use case is almost always the same. I define a chord progression in a MIDI sequencer (Xequence2 or Atom), I feed it to StepPolyArp, and it produces a bass line or a keyboard comping using the pattern I define and the chord it eats up. To this, I add a drum track using mostly Lumbeat apps.

    At first, I was using StepPolyArp in the « middle slot » of Audiobus MIDI channel. For my use case, I understand that I should use StepPolyArp in ARP mode, and I am syncing it using Ableton Link.

    My first issue is that with exactly the same setting, sometime it works (e.g. proper sync and notes going out of SPA), but sometimes it doesn’t (no note going out of StepPolyArp). I should also mention that I don’t have the feeling that the issue is with the upstream software (mainly Xequence), because if I put any other app instead of SPA in the middle slot, it works as expected. On the other hand, if I keep SPA and put another app in the input slot, it doesn’t work (even with ChordPolyPad).

    My second issue is that I usually need two instances, so that I can produce the bass line and the chord comping. So I bought the « Unit » version, which was a bit unpleasant due to the price tag of each of this app. If I use the « Unit » version as the app, it seems to have the same behavior as the one I reported in previous paragraph. If I use the Audio Unit, I get another unexpected behavior: the note that should go first, doesn’t, so instead of starting my bass line on the root note, it starts on the second note... Which makes it quite unusable... (which is unacceptable due to the price tag of each of this app).

    This is quite surprising, because the workflow I use seems quite straightforward. Does anyone got the same issue? Is there a known workaround?

    Kind regards,
    Pim

    I just tried this out and I think you're right. I don't have Xequence, but I used Fugue Machine to sequence the chords feeding SPAUnit (I don't have the original SPA).

    In Audiobus there are discrepancies with how / when notes are triggered. In AUM it triggers consistently. So this seems to be an issue with Audiobus @Michael

    However, I'm also seeing the issue with the the arpeggio not starting with the root note. I can verify that that chord notes are sent simultaneously, however that shouldn't be an issue as SPA doesn't have an "as played" arpeggio mode, it should be playing from lowest note to highest, but instead with a 3 note chord it's starting with 2, then goes to 3 then to 1, then 2, then 3...
    This happens in both Audiobus and AUM, so it seems to be an issue with StepPolyArp Unit

    Here's a videos showing the issues (timing issue in AB and play order issue in AUM):

  • Thanks for the heads up! I’ll look into this

  • @aplourde : thanks very much! I think (if you allow it) that I will point to your post to fill a bug report to SPA developer.

  • @Pim999 said:
    @aplourde : thanks very much! I think (if you allow it) that I will point to your post to fill a bug report to SPA developer.

    Please do, I will do the same, but multiple reports are harder to slip through the cracks!

  • Did so :) Thanks.

  • Update for SPAU that fixes the incorrect order is out!

    However, the timing issue is still there. While this initially seemed to be an Audiobus issue, I'm seeing it in AUM as well.
    It's definitely worse in Audiobus (it's always off), but it seems to be mainly a SPAU issue (and possibly an AUM issue?)
    @Michael @j_liljedahl

    OK, here's the order of events.

    After posting the video above, I saw the timing in SPAU off in AUM in another session I was working on. I had saved the test session from the video, so I loaded that up to test, but everything seemed fine with that.

    Then the update to SPAU dropped and I installed it and loaded up the test session. The note order issue was resolved, but now the same session I used in the video was having issues in AUM.

    However, the moment I load another app that has Link, the timing of SPAU in AUM is correct again.

    If I then save this now working session, close the other Link app and reload, it is again off. If I reload the session while the other app is still open, it keeps working correctly.

    I am now running the AUM beta and the issue is there as well.

    In Audiobus it's always off. Either it's inconsistent like in the video above, or it's consistent, but 1 beat late.
    Loading another Link-enabled app has no effect.

  • Of course now that SPAU is playing the notes in the correct order, it's made a track I was working on sound different.

    I didn't think this through...

  • I really think the timing issue might be a latency problem. FWIW.

  • @cian said:
    I really think the timing issue might be a latency problem. FWIW.

    No doubt, but that should be taken into account with timestamps, etc. E.g. Rozeta Arp doesn't have this issue.

    That said, I don't think it's just SPAU. As noted, the performance is different between Audiobus and AUM. Additionally, there's the weird situation where a saved AUM session, after re-loading, is off until another Link-enabled app is started. Then that seems to nudge AUM into the correct timing.

  • Yeah this is an issue with audio buffer boundaries, I’d say. The correct way to respond to incoming timestamps in a generator app is to look at the last time a render happened and then act on any time stamps from then until the end of the current buffer. It seems like this app may be ignoring that and only acting on events from the beginning of the current buffer to the end of the current buffer so if there’s a time stamp that’s even one sample too late, it’s going to get missed.

    I’m confident I can work around the issue in Audiobus, will see what I can do.

  • @Michael said:
    Yeah this is an issue with audio buffer boundaries, I’d say. The correct way to respond to incoming timestamps in a generator app is to look at the last time a render happened and then act on any time stamps from then until the end of the current buffer. It seems like this app may be ignoring that and only acting on events from the beginning of the current buffer to the end of the current buffer so if there’s a time stamp that’s even one sample too late, it’s going to get missed.

    I’m confident I can work around the issue in Audiobus, will see what I can do.

    Excellent! But it does like it's really an issue with SPAU - perhaps you could ping Laurent and discuss a way for him to fix this?
    I can point to the problem, but you could point to the solution!

    I'm still really curious about the AUM situation of snapping into working order when another Link app is started.

  • edited March 2020

    @aplourde said:
    Of course now that SPAU is playing the notes in the correct order, it's made a track I was working on sound different.

    I didn't think this through...

    And, of course, SPAU is flexible enough that I can recreate the buggy way of working: Have my patterns start with the absolute position of the 2nd note (and then the 3rd note) before going back to the relative note position arrows.

    EDIT: actually, that doesn't work because I had octave shifts and because I was using polymeters with a sustaining root note...

  • Thank you very much to all of you and to the developer to help solving at least the AU issue very quickly. It's more acceptable to stay locked in at home if music makins apps behave properly :smiley:

  • @Michael said:
    Yeah this is an issue with audio buffer boundaries, I’d say.

    Boundary issues are by far the trickiest part of making a solid MIDI Audio Unit in my experience. It took me weeks of experimenting to get a robust mechanism for Rozeta.

    I'm not sure if it can be solved on the host's end, it seems like something that the plugin needs to tackle?

  • @brambos said:

    @Michael said:
    Yeah this is an issue with audio buffer boundaries, I’d say.

    Boundary issues are by far the trickiest part of making a solid MIDI Audio Unit in my experience. It took me weeks of experimenting to get a robust mechanism for Rozeta.

    I'm not sure if it can be solved on the host's end, it seems like something that the plugin needs to tackle?

    You could be right – in general that’s probably true. I wonder if there might be some slight tweaking but I could do to make this work a little bit better from my end though.

  • @Pim999 said:
    Thank you very much to all of you and to the developer to help solving at least the AU issue very quickly. It's more acceptable to stay locked in at home if music makins apps behave properly :smiley:

    Unfortunately for me, the fix is worse than the cure because it's changed how existing patterns play... not really any good solution here except if Laurent can provide a setting to allow "buggy" mode so my old patterns play how they used to!

  • Honestly I sympathize with you :/

  • I'm also interested in progress of this issue.

Sign In or Register to comment.