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.

Monitoring directly from input block vs. output block in AB using Loopy

Looking for a little help please. When you set monitoring to off in Loopy while Loopy was in the output slot of audiobus, didn't you used to be able to monitor whatever effect was in the input slot directly from the input slot? I've bounced between using hardware amp modeling and iOS modeling so much that I can't remember, since they behave differently, but now that Tonestack is really getting good, I am considering going all iOS for everything again.

Example preset (with only two lanes):

Input: Tonestack,
Effect: None,
Output: Loopy HD

Input: Loopy HD,
Effect: Effectrix,
Output: Speaker

What I want to do is gradually turn my recorded loops into chaos using Effectrix while still being able to play guitar unaffected by Effectrix over the top of it all. What is happening is that as soon as Effectrix is engaged, not only are my loops effected by it but also my live guitar is too since it is being monitored through Loopy. If I turn monitoring off in loopy, I can't hear any live guitar at all. If I turn monitoring on in loopy, then everything goes through loopy and also Effectrix. I could have sworn in a previous release of audiobus if you set Monitoring to off in Loopy, you could still hear the output of the input block directly (in this case tonestack) but it doesn't do this. It also cut down on latency IIRC. Anyone know if this changed, and/or another way I could achieve this?

Comments

  • @Ringleader - what might work for you, is to select the Loopy tracks ( circled "i" to the right) in the AB input slot that feeds Effectrix. That way only the track(s) will go to Effectrix and the Loopy Monitor won't. Also, you can feed only the tracks you want to Effectrix and still have other track play unaltered.

  • edited August 2014

    Thank you. I hadn't even considered doing that and while it seems odd to stack all 12 tracks up in the input slot to feed Effectrix, it does indeed work so thanks again.

  • Ok so there is still something odd going on here. Here's my chain: tonestack, echo pad, loopy.

    When it is just tonestack to loopy, input monitoring needs to be on. If I add echo pad in the effects slot then I can turn input monitoring off and still hear direct signal coming straight out of echo pad. The results aren't consistent, depending on what order the apps are enabled in audiobus, I can sometimes hear signal with direct monitoring in loopy off.

  • edited October 2014

    (Double post)

  • edited August 2014

    I guess my question is how is it supposed to behave. Should I be able to hear the output of the input/effects slot with loopy input monitoring set to off or not?

  • I've come across this strange loopy monitoring behaviour as well. I've pinned it down a little further. In Audiobus with an input selected and with loopy selected as the output with loopy monitoring OFF: if you add anything to the effects slot, it will set loopy monitoring ON while still leaving the loopy monitoring switch set to OFF. There is yet a further complication...if you subsequently go into loopy and turn the monitoring switch ON and then OFF again, things go back to 'normal' & the monitoring switch now correctly governs the situation.

    Some more detail: if you get things back to 'normal' by flipping the monitoring switch on and off, but subsequently add another effect in the effects slot while monitoring is set to off, then the discrepancy described above will return.

    Note: even if loopy is completely closed down with monitoring OFF, it always defaults to ON when opened and loaded into the audiobus output slot, so this strange behaviour only arises when the monitoring is turned OFF prior to loading an effect. But also note that if loopy is already on, with monitoring off, and then loaded into the output slot, then the discrepancy between monitoring state and monitoring switch can occur even though the effects slot hasn't been used.

    This behaviour would be perhaps useful in certain situations but my guess is that it wasn't covered during software testing and we probably shouldn't rely on it being there in future updates.

  • edited October 2014

    Nice sleuthing. Agree that there is some weirdness going on. Odd behavior aside, there also needs to be a way to disable input monitoring for physical inputs (such as external guitar effects pedals, vocals, etc.) where you want to use direct hardware monitoring (to reduce latency and not hear a doubled/latency phased signal), yet still monitor virtual instruments via software monitoring.

    I know for a fact that I used to be able to do this at one point, because I used a Zoom G3 with direct hardware monitoring and Sampletank together and could hear everything, but somewhere along the way it got changed.

  • I'm sure @Michael would like to know this. Has anyone entered a support ticket with Loopy

  • Hey guys - this is deliberate behaviour, as designed for the 2.x version of the SDK.

    People were having problems doing what @Ringleader describes, turning off monitoring altogether, as the prior scheme was to have the input app take over the monitoring if the output app wasn't doing so. The new scheme is to have monitoring the exclusive responsibility of the output app. That means when the output app stops monitoring, the sound should stop (if it doesn't, it's probably a bug in the input app).

    Also, within Loopy I have it so that if monitoring's off when you connect it to an input, it should turn on monitoring again, so you can always hear the input the first time by default (except that change should be reflected in the switch state in settings! I'll fix that). I'm open to the possibly that that's the wrong call, though. Taking feedback!

    The behaviour you describe with Tonestack and Echo Pad, @Ringleader, is very odd though - that's not right. Can you reproduce that with any other app combinations? I can't seem to make it happen with another input and Echo Pad (I don't own Tonestack).

    I'd say @Ganthofer's solution is the way to go right now, just send the track outputs to the final effect.

  • edited November 2014

    @Michael said:

    People were having problems doing what @Ringleader describes, turning off monitoring altogether, as the prior scheme was to have the input app take over the monitoring if the output app wasn't doing so. The new scheme is to have monitoring the exclusive responsibility of the output app. That means when the output app stops monitoring, the sound should stop (if it doesn't, it's probably a bug in the input app).

    I've been bothering Michael too much about this already (sorry @Michael!) but I'm wondering if this change has caused any issues for anyone else? Most notably, not being able to hear virtual instrument apps (synths, etc.) when combined with a hardware direct monitored input (i.e. vocal mic, pre-processed guitar signal, any hardware input source where you would want absolute lowest possible latency).

    Could anyone please explain a situation where someone would want to turn off monitoring of a virtual instrument app altogether? The old "scheme" that ensured that virtual instruments would still be monitored makes much more sense to me.

Sign In or Register to comment.