Audiobus or Reset Re-enables Live Monitoring

Anyone else experiencing problems with this? Causes volume issues with my live setup as enabling monitoring doubles the signal when I'm sending to Loopy. There a way to keep Monitoring from enabling? Thanks!


  • Noticed that also

  • edited January 2015

    This is absolutely a serious issue. Every single iOS based setup that I own uses direct monitoring in the audio interface itself to provide lowest latency for vocals and guitar. Some of my interfaces don't allow me to disable the direct monitoring so there is no other option.

    However, the monitoring in loopy HD is all or nothing. So, to monitor VIs I have no choice but to also monitor my live instruments which causes a phased doubling effect on my live instruments (direct monitor and loopy monitor signals being combined).

    These apps (AB, Loopy) did not used to behave like this. It was changed in recent updates. On top of this new mandatory output monitoring behavior, there is apparently some logic coded into loopy/AB to automatically enable monitoring whenever it is added to an AB chain to compensate for it.

    Michael - is there any way this current implementation could be rethought and worked on as a priority? I have posted threads about it over at AB forum but I am surprised there hasn't been an outpouring of people experiencing these issues. iOS8 and iPad Air 2 issues aside, the current monitoring implementation is a deal breaker for every iOS rig configuration I own/use.

  • Sorry to be dragging my feet on that one Steve - you're absolutely right. I've had some ideas about how I can address that in Loopy, by offering separate Audiobus vs mic input monitoring options. Mind you, if the mic input is coming in via Audiobus, that won't do it - but I suspect if you're micing in with effects you'd wanna monitor that anyway, and if you don't then you can put the effects after Loopy. Might that suffice?

  • edited January 2015

    Thanks Michael, and reading that back I hope you know that I (always) mean that with all due respect. It is just that my iOS setup has been sitting on the sidelines for months now unusable because of these issues.

    May I ask what the problems were with the old way that it worked? I still don't understand why anyone wouldn't want a virtual instrument app in the input/effect slot to take up the monitoring task if the output app isn't doing it. What purpose does the app serve if you can't hear it during live play? I still feel like this monitoring solution needs to happen in Audiobus somehow so that other apps besides Loopy can benefit from it and it would be a more global solution.

    Personally, I do all guitar and vocal processing with dedicated processors outside of iOS to minimize latency and to ensure reliability. That way if the whole iOS thing glitches out or fails for any reason, I can unplug the USB cable and my guitar and vocals will still work and I only lose looping and VIs. So unfortunately, unless I am misunderstanding, the solution you are proposing wouldn't solve the issues for me.

  • edited January 2015

    Trying to think this through to narrow it down to a possible solution...

    Since the audio interface is handling the direct monitoring for the live instruments, the issue is that there needs to be a way to monitor only the virtual instrument/effect apps. There wouldn't need to be anything done with the live input channels as this is handled by the interface.

    Take for example the setup below. Imagine that the mic is being direct monitored by the hardware.

    1 - If loopy input monitoring is on, you hear Thumbjam but duplicate mic signals (direct and loopy).

    2 - If loopy input monitoring is off, you hear the hardware direct monitoring for the mic but no Thumbjam.

    In the second example, if there was just some way to monitor Thumbjam from either the input or effects slot, it seems it would all work itself out. Then I would think the logic to auto engage Loopy's input monitoring could be removed and the user could manage this manually.

    If the mic is not being direct monitored by the hardware, you wouldn't want to turn off loopy input monitoring anyways so it's a non-issue, again unless I am totally overlooking some other use scenario.

  • Glad I'm not the only one having this issue, and thanks for the insightful feedback. @Michael I get the logic of having it auto-enable, i.e. inserting it at the end of a stream and wanting to hear your VI's by default. However I would prefer the monitoring option to "stick" off or on depending on how I set it previously. To this point, I'd prefer the monitoring option to be more accessible. Perhaps on the orange sidebar with the metronome, etc.

    @Ringleader you make excellent points. I run a setup that consists of input from an FX send (post fader) on my analog mixer to my iRig HD, as well as internal apps, so flexible monitoring is needed. Here are some possible solutions I thought of:

    A) As you alluded to, an Audiobus feature of "slot monitoring". That little speaker icon could show up on any app in the chain to mirror it straight to the system output. Loopy keeps monitoring off, everyone's happy.

    B) Loopy could have a "record arm" or "monitor" option on tracks which would turn on monitoring on a track by track basis. So @Ringleader, in your example you could have two streams going to separate Loopy tracks, one with monitoring and the other without. @Michael I don't know if that's technically possible on your end, but it would solve this.

    Either way I'd like the monitoring preference to "stick" as mentioned before, or maybe making it an option to "remember my preference". Thanks!

  • edited January 2015

    Good points. Reading your post made me wonder if I am thinking of this whole thing bass-ackwards because of the way it USED to work. Instead of having devs modify their apps to add a monitoring option or adding a monitor button to the input and effects slots, maybe it IS only the live input channels that need to be modified since they seem to be the cause of the issue.

    Could an option be added in the audio interface panel to select whether or not the live input channel audio is live monitored in Audiobus? So I would set loopy to input monitoring "on" so VIs are heard, but then disable the live monitoring per live input channel in Audiobus (using my interface direct monitoring instead), while still sending the audio through the AB stream to the output app (in this case loopy) in the background? Something like the edited attached image.

    And I agree that the input monitoring should only ever do what you select and never sneak back to a different setting when you aren't looking. :) Would this solve the issue for everyone, and if so, be possible to implement?

  • This gets kind of hairy, doesn't it?

    @Ringleader Let me see if I understand your suggestion. Loopy is either monitoring or is not. So any flexibility with monitoring ("per channel" etc.) has to take place within Audiobus. If we mute a stream that has live input going to Loopy, we won't hear our recorded loops unless Loopy is also in a separate "non-muted" stream. So could your solution also be described as a simple "mute stream" feature? I think that could work.

    One other idea I just had is to allow multiple Output selections like we have with Input and Effects. You could leave monitoring off in Loopy, then set the Outputs in your stream as both Loopy and System Output (parallel). So @Ringleader, in your Thumbjam/Live Input example you could hear both the app and live input, and loop/record them all in one stream. This is similar technically to mirroring the output at the Effects stage as we mentioned before. @Michael is this possible?

    And Re: the workaround of keeping monitoring off but then putting effects in a new stream to hear them, that won't work if you want to record/loop the wet signal.

    Also an edit to my post: since you can't set distinct destinations within Loopy, only distinct sources, my suggestion of "per track" monitoring isn't possible.

  • Sorry to bring this back on topic, but the Monitoring switch turns on whenever just about ANYTHING happens in Audiobus. I won't even touch Loopy. I'll add a stream, delete a stream, add an app...if anything gets changed in Audiobus, Monitoring turns back on and to confirm @Ringleader's observation, the switch won't reflect its state.

    In summary, if Loopy is running in a dynamic Audiobus environment turning off Monitoring is a full-time job.

    Please fix. Thanks!

  • @Michael said:
    Sorry to be dragging my feet on that one Steve - you're absolutely right. I've had some ideas about how I can address that in Loopy, by offering separate Audiobus vs mic input monitoring options. Mind you, if the mic input is coming in via Audiobus, that won't do it - but I suspect if you're micing in with effects you'd wanna monitor that anyway, and if you don't then you can put the effects after Loopy. Might that suffice?

    Who am I kidding, you would know best what would work to solve this. So if you think this is it, then yes please! I'm willing to try anything at this point. Thanks!

  • That isn't it, you were right =)

    But this is: deal with Audiobus sources separately - streams that begin with the AB system input, and all other streams. The latter respects the monitor control; the former doesn't. Done.

  • Sounds great to me! I got a new little rig/interface all ready to go waiting for the update. ;) Can ya give any hints on a timeframe when we might be able to get our hands on it?

  • Pretty soon, I think - I'm aiming for sometime within the next 30 days or so =)

  • Thank you sir!

  • So wait this requires an update to AB too, or just loopy? Just so I know what I'm looking out for...

  • Just Loopy!

  • Wow - this is actually really hard. Lots of tricky buffer juggling/pipeline splitting. I'm not sure it's gotta make it into the next update (which is a bit pressing), I'm afraid. I can't wrap my head around this today! I'll do my best, but I just wanted to give you a heads-up, it's less trivial than I thought it'd be.

  • edited January 2015

    That's what she said!

    Edit: Ha sorry, just kidding around. It's NAMM week so I've been hanging out on thegearpage. You know what they say: You can take a guy out of TGP, but you can't take TGP out of the guy.

    If it doesn't make it this time then I guess we'll just have to wait until the next one. Thanks for giving it a shot!

  • @Michael is it not easier to add a parallel system output to the output stage of Audiobus streams? I really have no idea what's hard or easy on your end.

    My concern is with streams that have both a system input as well as an app as their source, for situations when you want both sources to share an effect.

  • edited January 2015

    I was under the impression that if you started with an AB system input but had an app in the effects slot, the new logic would be overridden. You wouldn't likely add a direct monitored AB system input to an effects stream or you'd get the same doubling problem we have now, unless the effect was 100% wet, but then that 100% wet signal is all that would be recorded in Loopy too.

    But good question. Probably another reason it's turning out to be such a bugger.

  • If monitoring's off in Loopy:

    • If the system input's in a pipeline of its own, with or without effects, then it'll be silent
    • If it's in a pipeline along with another app, but with no effect, then it'll be silent
    • If it's in a pipeline along with another app, and it goes through an effect, then there's no choice: it'll be audible, because it's mixed together before it gets to Loopy. iOS doesn't support multiple instances of an app, and it's not as simple as just running two separate streams through the one filter (that's like trying to pass two different streams of water through a hose simultaneously and keep them separate ;-))
  • So worst case scenario, if you wanted to use both effected and non-effected AB system inputs, you'd have to add an input app to the AB system input effects stream you wanted to monitor just so it would mix and become audible. I can live with this.

  • Oh... And THANK YOU for working on this!!,

  • That's right, yeah - of course, it doesn't give you much dry/wet control doing it that way. Ideally that'd be in the effects app.

    No worries =)

  • @Michael - would you please verify what version all this doubled/auto-enabled monitoring began? I spent the afternoon with an Air on 7.1.2 trying to install previous IPAs to get a working rig again and I can't figure it out.

  • It was probably 1.4.8, I think.

  • edited August 2015

    For any of you who are using direct monitored audio inputs simultaneously with VIs into Loopy and experiencing issues as described above, the developer of MiMiX is going to take a shot at providing a solution. Hopefully this works out! More info here:

    Edit: to clarify, Michael fixed the auto monitor enable a while back. This future MiMiX update should fix the other half of the issue, being able to monitor VIs and also direct hardware monitor inputs simultaneously.

Sign In or Register to comment.