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.

Any low CPU tape looping (sound on sound) apps that can be set to 100% wet?

I’m looking for a simple implementation of a sound on sound style tape looper. The only requirement I have really is that it be possible to set it to 100% wet so that I can use it as a send and monitor the guitar it’ll process directly. Tried out a couple of apps but didn’t find the right one yet. Can anyone throw any more potential candidates in?

Tried Kosmonaut and RE-1.

Kosmonaut — can’t be used as a send (always contains dry signal due to the Haas function)

RE-1 Tape Looper — love this app but it’s never been stable for me and always issues with reloading audio is sessions as well as cpu usage spikes

Have thought about Audio Damage Enso, but I’d like to know if the technical issues it previously suffered are still a problem, and more importantly how the CPU performance is? A few of the AD apps I’ve used seemed to require more CPU than equivalent competitors.

Cheers,
Oscar

Comments

  • Have you tried Bram's Gauss?

  • Enso is very stable and low on cpu.

  • edited January 2021

    @richardyot said:
    Have you tried Bram's Gauss?

    I've had a look at it but wasn't convinced yet that it'll get what I want from it -- really to just keep running and have a feedback/decay dial that I can control with an expression pedal (basically Kosmonaut with a wet/dry control). I wasn't sure because it seemed more designed to make a one shot pass of audio which is then sequenced. The extra functionality of Gauss does look really cool though and if it did do the job required then I'd actually love to go with it and play with its additional functionality.

  • edited January 2021

    @OscarSouth said:

    @richardyot said:
    Have you tried Bram's Gauss?

    I've had a look at it but wasn't convinced yet that it'll get what I want from it -- really to just keep running and have a feedback/decay dial that I can control with an expression pedal (basically Kosmonaut with a wet/dry control). I wasn't sure because it seemed more designed to make a one shot pass of audio which is then sequenced. The extra functionality of Gauss does look really cool though and if it did do the job required then I'd actually love to go with it and play with its additional functionality.

    Ah hold up -- found an update thread and it looks more probable this functionality exists! Decision time coming closer .. (anyone got any comments on cpu performance & functionality of Enso vs Gauss?)

    Also, can anyone confirm whether Gauss can be a 'wet signal only' send, so that I can monitor the incoming signal directly? (latency free). It looks like this is the case with the 'monitor' control, but I'd rather be sure.

  • Enso has different monitor modes:

  • edited January 2021

    @OscarSouth said:

    @OscarSouth said:

    @richardyot said:
    Have you tried Bram's Gauss?

    I've had a look at it but wasn't convinced yet that it'll get what I want from it -- really to just keep running and have a feedback/decay dial that I can control with an expression pedal (basically Kosmonaut with a wet/dry control). I wasn't sure because it seemed more designed to make a one shot pass of audio which is then sequenced. The extra functionality of Gauss does look really cool though and if it did do the job required then I'd actually love to go with it and play with its additional functionality.

    Ah hold up -- found an update thread and it looks more probable this functionality exists! Decision time coming closer .. (anyone got any comments on cpu performance & functionality of Enso vs Gauss?)

    Also, can anyone confirm whether Gauss can be a 'wet signal only' send, so that I can monitor the incoming signal directly? (latency free). It looks like this is the case with the 'monitor' control, but I'd rather be sure.

    There’s no wet / dry in Gauss, not exactly. ‘Monitor’ will monitor the incoming signal as it is, but not what’s just been recorded to the tape loop. In this regard, it’s like the monitor tape head is before the record head, not after. So yeah, latency free monitoring - you’ll hear the loop in its degraded glory on the next pass through, or directly after recording stops.

    In summary - you don’t hear the loop itself as it’s being recorded

  • @Janosax said:
    Enso has different monitor modes:

    Thanks, that's very useful to see.

    @aleyas said:

    @OscarSouth said:

    @OscarSouth said:

    @richardyot said:
    Have you tried Bram's Gauss?

    I've had a look at it but wasn't convinced yet that it'll get what I want from it -- really to just keep running and have a feedback/decay dial that I can control with an expression pedal (basically Kosmonaut with a wet/dry control). I wasn't sure because it seemed more designed to make a one shot pass of audio which is then sequenced. The extra functionality of Gauss does look really cool though and if it did do the job required then I'd actually love to go with it and play with its additional functionality.

    Ah hold up -- found an update thread and it looks more probable this functionality exists! Decision time coming closer .. (anyone got any comments on cpu performance & functionality of Enso vs Gauss?)

    Also, can anyone confirm whether Gauss can be a 'wet signal only' send, so that I can monitor the incoming signal directly? (latency free). It looks like this is the case with the 'monitor' control, but I'd rather be sure.

    There’s no wet / dry in Gauss, not exactly. ‘Monitor’ will monitor the incoming signal as it is, but not what’s just been recorded to the tape loop. In this regard, it’s like the monitor tape head is before the record head, not after. So yeah, latency free monitoring - you’ll hear the loop in its degraded glory on the next pass through, or directly after recording stops.

    In summary - you don’t hear the loop itself as it’s being recorded

    That's exactly what I want to do! Thanks. The direct guitar signal will be central and highly present whereas the loops will be routed (by footpedal) to the left and right sides of the tape and leave 'trails' in the extremes of the stereo field. Is based on some music composition harmonic concepts that I've been working on based on sets of overlapping altered pentatonic scales generating viable keys with more than 7 notes. I think it'll sound interesting to let the different harmonic ingredients separate out in time while they overlap in space. Picture is a page of my weird glyphs from the notepad I've been sketching the ideas in.

    I love the idea that the signal will be written to tape at the speed that it's running, sequencer and all.

  • I have no problems with Enso. Gauss is more like a gimmick, but really good marketing.

  • edited January 2021

    @aleyas said:

    @OscarSouth said:

    @OscarSouth said:

    @richardyot said:
    Have you tried Bram's Gauss?

    I've had a look at it but wasn't convinced yet that it'll get what I want from it -- really to just keep running and have a feedback/decay dial that I can control with an expression pedal (basically Kosmonaut with a wet/dry control). I wasn't sure because it seemed more designed to make a one shot pass of audio which is then sequenced. The extra functionality of Gauss does look really cool though and if it did do the job required then I'd actually love to go with it and play with its additional functionality.

    Ah hold up -- found an update thread and it looks more probable this functionality exists! Decision time coming closer .. (anyone got any comments on cpu performance & functionality of Enso vs Gauss?)

    Also, can anyone confirm whether Gauss can be a 'wet signal only' send, so that I can monitor the incoming signal directly? (latency free). It looks like this is the case with the 'monitor' control, but I'd rather be sure.

    There’s no wet / dry in Gauss, not exactly. ‘Monitor’ will monitor the incoming signal as it is, but not what’s just been recorded to the tape loop. In this regard, it’s like the monitor tape head is before the record head, not after. So yeah, latency free monitoring - you’ll hear the loop in its degraded glory on the next pass through, or directly after recording stops.

    In summary - you don’t hear the loop itself as it’s being recorded

    I did buy Gauss, but aside from being amazing it also unfortunately doesn't do what I need.

    The 'monitor' on/off toggle only disables monitoring while the tape is not recording, so as soon as you hit record then the monitoring of the input comes back in full, adding a really distinct (and unwanted) slapback delay effect to the live signal while recording is in progress.

    For use in 'overdub' mode, since 'record' is enabled constantly it then appears to be impossible to disable monitoring, meaning that the processor is not able to be used in parallel with a live signal.

    I love every other part of the functionality though, so I'm hoping that a polite feature request might be enough to add in this simple functionality tweak :)

    @brambos -- is there any possibility that the option to fully disable monitoring (including while recording) can be included in a future update? That's all that I'd need to put this amazing sounding thing to use!

  • @neinneinnein said:
    I have no problems with Enso. Gauss is more like a gimmick, but really good marketing.

    I would disagree that Gauss is just a gimmick. Maybe, it just isn't a fit for what you are looking for.

    Enso is also very good, and different. So while there is some overlap, there are use-cases where on or the other might be a better fit. Also, for some of us Enso has not been super-stable with multiple instances running.

  • Enso looks great to me but I chose Gauss as how the sequencer interacts with the loop looked very directly usable and creative to me. After having a big Gauss jam here for the last hour, I can confirm that there's not one single control on that app that isn't immediately practical and 'playable' for my purposes. It crosses the subjective line from 'app' to 'instrument' for me.

    I'm sure that Enso is equally awesome in it's own way but I'm still hoping that I can get this parallel monitoring issue with Gauss resolved right now ('live/direct' input can't be disabled while recording is active).

  • @OscarSouth said:
    Enso looks great to me but I chose Gauss as how the sequencer interacts with the loop looked very directly usable and creative to me. After having a big Gauss jam here for the last hour, I can confirm that there's not one single control on that app that isn't immediately practical and 'playable' for my purposes. It crosses the subjective line from 'app' to 'instrument' for me.

    I'm sure that Enso is equally awesome in it's own way but I'm still hoping that I can get this parallel monitoring issue with Gauss resolved right now ('live/direct' input can't be disabled while recording is active).

    Maybe use a toggle on a send triggered by the same midi that will toggle recording so that the dry signal is only reaching Gauss while it is recording?

  • @espiegel123 said:

    @OscarSouth said:
    Enso looks great to me but I chose Gauss as how the sequencer interacts with the loop looked very directly usable and creative to me. After having a big Gauss jam here for the last hour, I can confirm that there's not one single control on that app that isn't immediately practical and 'playable' for my purposes. It crosses the subjective line from 'app' to 'instrument' for me.

    I'm sure that Enso is equally awesome in it's own way but I'm still hoping that I can get this parallel monitoring issue with Gauss resolved right now ('live/direct' input can't be disabled while recording is active).

    Maybe use a toggle on a send triggered by the same midi that will toggle recording so that the dry signal is only reaching Gauss while it is recording?

    I don't think there'll be any viable workaround as if I was to toggle off the output while recording mode is active, then it'll silence any currently running recorded audio that's already looping.

  • @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:
    Enso looks great to me but I chose Gauss as how the sequencer interacts with the loop looked very directly usable and creative to me. After having a big Gauss jam here for the last hour, I can confirm that there's not one single control on that app that isn't immediately practical and 'playable' for my purposes. It crosses the subjective line from 'app' to 'instrument' for me.

    I'm sure that Enso is equally awesome in it's own way but I'm still hoping that I can get this parallel monitoring issue with Gauss resolved right now ('live/direct' input can't be disabled while recording is active).

    Maybe use a toggle on a send triggered by the same midi that will toggle recording so that the dry signal is only reaching Gauss while it is recording?

    I don't think there'll be any viable workaround as if I was to toggle off the output while recording mode is active, then it'll silence any currently running recorded audio that's already looping.

    No. I don’t think so; unless I misunderstand.

    Put your input on its own channel (I am assuming AUM as host). Have a send a node that sends to a bus.

    Put Gauss on that bus with input monitoring off in Gauss.

    Set up a midi cc or note that will both toggle whether the send is engaged and the recording state.

    Set it up so that the send is only on while Gauss is recording.

    When recording stops, you will still Gauss playing on its bus/channel but you won’t have an input signal going to it. Toggling the send won’t have any effect on Gauss’s output. It just guarantees that your input signal only reaches Gauss when it is recording.

  • What if you inserted a delay before Gauss? So if you are recording 8 bars in Gauss on a send, insert an 8 bar delay (at 100%)... that way you won’t hear your playing until the expected 8 bars later when it then records to Gauss. I’m probably way wrong with that idea... 😜

  • @OscarSouth You don't use Drambo, do you?

  • @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:
    Enso looks great to me but I chose Gauss as how the sequencer interacts with the loop looked very directly usable and creative to me. After having a big Gauss jam here for the last hour, I can confirm that there's not one single control on that app that isn't immediately practical and 'playable' for my purposes. It crosses the subjective line from 'app' to 'instrument' for me.

    I'm sure that Enso is equally awesome in it's own way but I'm still hoping that I can get this parallel monitoring issue with Gauss resolved right now ('live/direct' input can't be disabled while recording is active).

    Maybe use a toggle on a send triggered by the same midi that will toggle recording so that the dry signal is only reaching Gauss while it is recording?

    I don't think there'll be any viable workaround as if I was to toggle off the output while recording mode is active, then it'll silence any currently running recorded audio that's already looping.

    No. I don’t think so; unless I misunderstand.

    Put your input on its own channel (I am assuming AUM as host). Have a send a node that sends to a bus.

    Put Gauss on that bus with input monitoring off in Gauss.

    Set up a midi cc or note that will both toggle whether the send is engaged and the recording state.

    Set it up so that the send is only on while Gauss is recording.

    When recording stops, you will still Gauss playing on its bus/channel but you won’t have an input signal going to it. Toggling the send won’t have any effect on Gauss’s output. It just guarantees that your input signal only reaches Gauss when it is recording.

    Unless I'm missing something, this will just create the exact same behaviour as disabling input monitoring in Gauss (no input monitoring unless active recording is enabled -- which would be all the time with sound on sound looping), but with extra steps. Thank you for taking the time to think about and explain solutions though -- I really appreciate it.

  • edited January 2021

    @stown said:
    What if you inserted a delay before Gauss? So if you are recording 8 bars in Gauss on a send, insert an 8 bar delay (at 100%)... that way you won’t hear your playing until the expected 8 bars later when it then records to Gauss. I’m probably way wrong with that idea... 😜

    This is some pretty smart thinking and could work as a stopgap. There was some side effect to this which occurred to me as I was walking and thinking about it that wouldn't be ideal, but I can't think of what it was right this second. Not a solution but a potential band aid that might add some cool advantages/musical character of it's own -- thanks.

  • edited January 2021

    @rs2000 said:
    @OscarSouth You don't use Drambo, do you?

    Don't tempt me -- I can't afford 'speculative purchases' until future gigs or I manage to launch some other viable business approach ;)

  • tbh - I don't see the problem with enso. Of course you can set to 100% wet. just dial down the dry output...
    Am I missing something?

  • @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:
    Enso looks great to me but I chose Gauss as how the sequencer interacts with the loop looked very directly usable and creative to me. After having a big Gauss jam here for the last hour, I can confirm that there's not one single control on that app that isn't immediately practical and 'playable' for my purposes. It crosses the subjective line from 'app' to 'instrument' for me.

    I'm sure that Enso is equally awesome in it's own way but I'm still hoping that I can get this parallel monitoring issue with Gauss resolved right now ('live/direct' input can't be disabled while recording is active).

    Maybe use a toggle on a send triggered by the same midi that will toggle recording so that the dry signal is only reaching Gauss while it is recording?

    I don't think there'll be any viable workaround as if I was to toggle off the output while recording mode is active, then it'll silence any currently running recorded audio that's already looping.

    No. I don’t think so; unless I misunderstand.

    Put your input on its own channel (I am assuming AUM as host). Have a send a node that sends to a bus.

    Put Gauss on that bus with input monitoring off in Gauss.

    Set up a midi cc or note that will both toggle whether the send is engaged and the recording state.

    Set it up so that the send is only on while Gauss is recording.

    When recording stops, you will still Gauss playing on its bus/channel but you won’t have an input signal going to it. Toggling the send won’t have any effect on Gauss’s output. It just guarantees that your input signal only reaches Gauss when it is recording.

    Unless I'm missing something, this will just create the exact same behaviour as disabling input monitoring in Gauss (no input monitoring unless active recording is enabled -- which would be all the time with sound on sound looping), but with extra steps. Thank you for taking the time to think about and explain solutions though -- I really appreciate it.

    I see. I should have tested this before posting.

    After testing, I see now that in Overdub mode record monitors the input signal. I mistakenly thought that it behaved the same in Overdub and Replace modes with respect to the monitor input setting.

    @brambos: this feels like a bug to me. The input monitor setting is ignored while recording with overdub on. It seems like in overdub mode should work the same as replace mode currently does on this regard.

    It also explains a source of confusion that I had when I first started using it.

  • @electronicsfordogs said:
    tbh - I don't see the problem with enso. Of course you can set to 100% wet. just dial down the dry output...
    Am I missing something?

    This is the backup plan if I can't get Gauss to do what I need :)

    Enso looks awesome but I do love the Gauss sequencer!

  • edited January 2021

    @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:
    Enso looks great to me but I chose Gauss as how the sequencer interacts with the loop looked very directly usable and creative to me. After having a big Gauss jam here for the last hour, I can confirm that there's not one single control on that app that isn't immediately practical and 'playable' for my purposes. It crosses the subjective line from 'app' to 'instrument' for me.

    I'm sure that Enso is equally awesome in it's own way but I'm still hoping that I can get this parallel monitoring issue with Gauss resolved right now ('live/direct' input can't be disabled while recording is active).

    Maybe use a toggle on a send triggered by the same midi that will toggle recording so that the dry signal is only reaching Gauss while it is recording?

    I don't think there'll be any viable workaround as if I was to toggle off the output while recording mode is active, then it'll silence any currently running recorded audio that's already looping.

    No. I don’t think so; unless I misunderstand.

    Put your input on its own channel (I am assuming AUM as host). Have a send a node that sends to a bus.

    Put Gauss on that bus with input monitoring off in Gauss.

    Set up a midi cc or note that will both toggle whether the send is engaged and the recording state.

    Set it up so that the send is only on while Gauss is recording.

    When recording stops, you will still Gauss playing on its bus/channel but you won’t have an input signal going to it. Toggling the send won’t have any effect on Gauss’s output. It just guarantees that your input signal only reaches Gauss when it is recording.

    Unless I'm missing something, this will just create the exact same behaviour as disabling input monitoring in Gauss (no input monitoring unless active recording is enabled -- which would be all the time with sound on sound looping), but with extra steps. Thank you for taking the time to think about and explain solutions though -- I really appreciate it.

    I see. I should have tested this before posting.

    After testing, I see now that in Overdub mode record monitors the input signal. I mistakenly thought that it behaved the same in Overdub and Replace modes with respect to the monitor input setting.

    @brambos: this feels like a bug to me. The input monitor setting is ignored while recording with overdub on. It seems like in overdub mode should work the same as replace mode currently does on this regard.

    It also explains a source of confusion that I had when I first started using it.

    It's not a bug. I actually spent 2 weeks rewriting my entire engine to be able to let it behave like this. Hainbach was quite adamant that this is the way to go: being able to hear what you're recording, while you're recording.

    Disabling this behavior will probably be very tricky (=nigh impossible without making lots of very fundamental changes). It has to do with being able to achieve the what-you-hear-is-what-you-get with all the overdubbing-speed-changing-warbling effects immediately audible. It's a little bit more involved to do than with a regular looper that doesn't do realtime continuous speed-changes while overdubbing.

    So unfortunately it's not a matter of adding a checkbox and two lines of code :|

  • @brambos said:

    @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:
    Enso looks great to me but I chose Gauss as how the sequencer interacts with the loop looked very directly usable and creative to me. After having a big Gauss jam here for the last hour, I can confirm that there's not one single control on that app that isn't immediately practical and 'playable' for my purposes. It crosses the subjective line from 'app' to 'instrument' for me.

    I'm sure that Enso is equally awesome in it's own way but I'm still hoping that I can get this parallel monitoring issue with Gauss resolved right now ('live/direct' input can't be disabled while recording is active).

    Maybe use a toggle on a send triggered by the same midi that will toggle recording so that the dry signal is only reaching Gauss while it is recording?

    I don't think there'll be any viable workaround as if I was to toggle off the output while recording mode is active, then it'll silence any currently running recorded audio that's already looping.

    No. I don’t think so; unless I misunderstand.

    Put your input on its own channel (I am assuming AUM as host). Have a send a node that sends to a bus.

    Put Gauss on that bus with input monitoring off in Gauss.

    Set up a midi cc or note that will both toggle whether the send is engaged and the recording state.

    Set it up so that the send is only on while Gauss is recording.

    When recording stops, you will still Gauss playing on its bus/channel but you won’t have an input signal going to it. Toggling the send won’t have any effect on Gauss’s output. It just guarantees that your input signal only reaches Gauss when it is recording.

    Unless I'm missing something, this will just create the exact same behaviour as disabling input monitoring in Gauss (no input monitoring unless active recording is enabled -- which would be all the time with sound on sound looping), but with extra steps. Thank you for taking the time to think about and explain solutions though -- I really appreciate it.

    I see. I should have tested this before posting.

    After testing, I see now that in Overdub mode record monitors the input signal. I mistakenly thought that it behaved the same in Overdub and Replace modes with respect to the monitor input setting.

    @brambos: this feels like a bug to me. The input monitor setting is ignored while recording with overdub on. It seems like in overdub mode should work the same as replace mode currently does on this regard.

    It also explains a source of confusion that I had when I first started using it.

    It's not a bug. I actually spent 2 weeks rewriting my entire engine to be able to let it behave like this. Hainbach was quite adamant that this is the way to go: being able to hear what you're recording, while you're recording.

    Disabling this behavior will probably be very tricky (=nigh impossible without making lots of very fundamental changes). It has to do with being able to achieve the what-you-hear-is-what-you-get with all the overdubbing-speed-changing-warbling effects immediately audible. It's a little bit more involved to do than with a regular looper that doesn't do realtime continuous speed-changes.

    One could still hear what you’ll get by turning input monitoring on when you overdub, no? It seems like that method would add choice and flexibility. From a user perspective it is odd that the overdub and non-overdub modes work differently in this regard.

  • @espiegel123 said:

    @brambos said:

    @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:
    Enso looks great to me but I chose Gauss as how the sequencer interacts with the loop looked very directly usable and creative to me. After having a big Gauss jam here for the last hour, I can confirm that there's not one single control on that app that isn't immediately practical and 'playable' for my purposes. It crosses the subjective line from 'app' to 'instrument' for me.

    I'm sure that Enso is equally awesome in it's own way but I'm still hoping that I can get this parallel monitoring issue with Gauss resolved right now ('live/direct' input can't be disabled while recording is active).

    Maybe use a toggle on a send triggered by the same midi that will toggle recording so that the dry signal is only reaching Gauss while it is recording?

    I don't think there'll be any viable workaround as if I was to toggle off the output while recording mode is active, then it'll silence any currently running recorded audio that's already looping.

    No. I don’t think so; unless I misunderstand.

    Put your input on its own channel (I am assuming AUM as host). Have a send a node that sends to a bus.

    Put Gauss on that bus with input monitoring off in Gauss.

    Set up a midi cc or note that will both toggle whether the send is engaged and the recording state.

    Set it up so that the send is only on while Gauss is recording.

    When recording stops, you will still Gauss playing on its bus/channel but you won’t have an input signal going to it. Toggling the send won’t have any effect on Gauss’s output. It just guarantees that your input signal only reaches Gauss when it is recording.

    Unless I'm missing something, this will just create the exact same behaviour as disabling input monitoring in Gauss (no input monitoring unless active recording is enabled -- which would be all the time with sound on sound looping), but with extra steps. Thank you for taking the time to think about and explain solutions though -- I really appreciate it.

    I see. I should have tested this before posting.

    After testing, I see now that in Overdub mode record monitors the input signal. I mistakenly thought that it behaved the same in Overdub and Replace modes with respect to the monitor input setting.

    @brambos: this feels like a bug to me. The input monitor setting is ignored while recording with overdub on. It seems like in overdub mode should work the same as replace mode currently does on this regard.

    It also explains a source of confusion that I had when I first started using it.

    It's not a bug. I actually spent 2 weeks rewriting my entire engine to be able to let it behave like this. Hainbach was quite adamant that this is the way to go: being able to hear what you're recording, while you're recording.

    Disabling this behavior will probably be very tricky (=nigh impossible without making lots of very fundamental changes). It has to do with being able to achieve the what-you-hear-is-what-you-get with all the overdubbing-speed-changing-warbling effects immediately audible. It's a little bit more involved to do than with a regular looper that doesn't do realtime continuous speed-changes.

    One could still hear what you’ll get by turning input monitoring on when you overdub, no? It seems like that method would add choice and flexibility. From a user perspective it is odd that the overdub and non-overdub modes work differently in this regard.

    It's not that simple. What you hear is what you've recorded combined with the overdubbed material. I can't separate the two anymore at that point. So you either hear everything, or get complete silence.

  • edited January 2021

    @electronicsfordogs said:
    tbh - I don't see the problem with enso. Of course you can set to 100% wet. just dial down the dry output...
    Am I missing something?

    +1 Enso can handle this easily, exactly as described here.

  • @brambos said:

    @espiegel123 said:

    @brambos said:

    @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:
    Enso looks great to me but I chose Gauss as how the sequencer interacts with the loop looked very directly usable and creative to me. After having a big Gauss jam here for the last hour, I can confirm that there's not one single control on that app that isn't immediately practical and 'playable' for my purposes. It crosses the subjective line from 'app' to 'instrument' for me.

    I'm sure that Enso is equally awesome in it's own way but I'm still hoping that I can get this parallel monitoring issue with Gauss resolved right now ('live/direct' input can't be disabled while recording is active).

    Maybe use a toggle on a send triggered by the same midi that will toggle recording so that the dry signal is only reaching Gauss while it is recording?

    I don't think there'll be any viable workaround as if I was to toggle off the output while recording mode is active, then it'll silence any currently running recorded audio that's already looping.

    No. I don’t think so; unless I misunderstand.

    Put your input on its own channel (I am assuming AUM as host). Have a send a node that sends to a bus.

    Put Gauss on that bus with input monitoring off in Gauss.

    Set up a midi cc or note that will both toggle whether the send is engaged and the recording state.

    Set it up so that the send is only on while Gauss is recording.

    When recording stops, you will still Gauss playing on its bus/channel but you won’t have an input signal going to it. Toggling the send won’t have any effect on Gauss’s output. It just guarantees that your input signal only reaches Gauss when it is recording.

    Unless I'm missing something, this will just create the exact same behaviour as disabling input monitoring in Gauss (no input monitoring unless active recording is enabled -- which would be all the time with sound on sound looping), but with extra steps. Thank you for taking the time to think about and explain solutions though -- I really appreciate it.

    I see. I should have tested this before posting.

    After testing, I see now that in Overdub mode record monitors the input signal. I mistakenly thought that it behaved the same in Overdub and Replace modes with respect to the monitor input setting.

    @brambos: this feels like a bug to me. The input monitor setting is ignored while recording with overdub on. It seems like in overdub mode should work the same as replace mode currently does on this regard.

    It also explains a source of confusion that I had when I first started using it.

    It's not a bug. I actually spent 2 weeks rewriting my entire engine to be able to let it behave like this. Hainbach was quite adamant that this is the way to go: being able to hear what you're recording, while you're recording.

    Disabling this behavior will probably be very tricky (=nigh impossible without making lots of very fundamental changes). It has to do with being able to achieve the what-you-hear-is-what-you-get with all the overdubbing-speed-changing-warbling effects immediately audible. It's a little bit more involved to do than with a regular looper that doesn't do realtime continuous speed-changes.

    One could still hear what you’ll get by turning input monitoring on when you overdub, no? It seems like that method would add choice and flexibility. From a user perspective it is odd that the overdub and non-overdub modes work differently in this regard.

    It's not that simple. What you hear is what you've recorded combined with the overdubbed material. I can't separate the two anymore at that point. So you either hear everything, or get complete silence

    I think I understand now.

  • @brambos said:

    @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:
    Enso looks great to me but I chose Gauss as how the sequencer interacts with the loop looked very directly usable and creative to me. After having a big Gauss jam here for the last hour, I can confirm that there's not one single control on that app that isn't immediately practical and 'playable' for my purposes. It crosses the subjective line from 'app' to 'instrument' for me.

    I'm sure that Enso is equally awesome in it's own way but I'm still hoping that I can get this parallel monitoring issue with Gauss resolved right now ('live/direct' input can't be disabled while recording is active).

    Maybe use a toggle on a send triggered by the same midi that will toggle recording so that the dry signal is only reaching Gauss while it is recording?

    I don't think there'll be any viable workaround as if I was to toggle off the output while recording mode is active, then it'll silence any currently running recorded audio that's already looping.

    No. I don’t think so; unless I misunderstand.

    Put your input on its own channel (I am assuming AUM as host). Have a send a node that sends to a bus.

    Put Gauss on that bus with input monitoring off in Gauss.

    Set up a midi cc or note that will both toggle whether the send is engaged and the recording state.

    Set it up so that the send is only on while Gauss is recording.

    When recording stops, you will still Gauss playing on its bus/channel but you won’t have an input signal going to it. Toggling the send won’t have any effect on Gauss’s output. It just guarantees that your input signal only reaches Gauss when it is recording.

    Unless I'm missing something, this will just create the exact same behaviour as disabling input monitoring in Gauss (no input monitoring unless active recording is enabled -- which would be all the time with sound on sound looping), but with extra steps. Thank you for taking the time to think about and explain solutions though -- I really appreciate it.

    I see. I should have tested this before posting.

    After testing, I see now that in Overdub mode record monitors the input signal. I mistakenly thought that it behaved the same in Overdub and Replace modes with respect to the monitor input setting.

    @brambos: this feels like a bug to me. The input monitor setting is ignored while recording with overdub on. It seems like in overdub mode should work the same as replace mode currently does on this regard.

    It also explains a source of confusion that I had when I first started using it.

    It's not a bug. I actually spent 2 weeks rewriting my entire engine to be able to let it behave like this. Hainbach was quite adamant that this is the way to go: being able to hear what you're recording, while you're recording.

    Disabling this behavior will probably be very tricky (=nigh impossible without making lots of very fundamental changes). It has to do with being able to achieve the what-you-hear-is-what-you-get with all the overdubbing-speed-changing-warbling effects immediately audible. It's a little bit more involved to do than with a regular looper that doesn't do realtime continuous speed-changes while overdubbing.

    So unfortunately it's not a matter of adding a checkbox and two lines of code :|

    @brambos said:

    @espiegel123 said:

    @brambos said:

    @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:

    @espiegel123 said:

    @OscarSouth said:
    Enso looks great to me but I chose Gauss as how the sequencer interacts with the loop looked very directly usable and creative to me. After having a big Gauss jam here for the last hour, I can confirm that there's not one single control on that app that isn't immediately practical and 'playable' for my purposes. It crosses the subjective line from 'app' to 'instrument' for me.

    I'm sure that Enso is equally awesome in it's own way but I'm still hoping that I can get this parallel monitoring issue with Gauss resolved right now ('live/direct' input can't be disabled while recording is active).

    Maybe use a toggle on a send triggered by the same midi that will toggle recording so that the dry signal is only reaching Gauss while it is recording?

    I don't think there'll be any viable workaround as if I was to toggle off the output while recording mode is active, then it'll silence any currently running recorded audio that's already looping.

    No. I don’t think so; unless I misunderstand.

    Put your input on its own channel (I am assuming AUM as host). Have a send a node that sends to a bus.

    Put Gauss on that bus with input monitoring off in Gauss.

    Set up a midi cc or note that will both toggle whether the send is engaged and the recording state.

    Set it up so that the send is only on while Gauss is recording.

    When recording stops, you will still Gauss playing on its bus/channel but you won’t have an input signal going to it. Toggling the send won’t have any effect on Gauss’s output. It just guarantees that your input signal only reaches Gauss when it is recording.

    Unless I'm missing something, this will just create the exact same behaviour as disabling input monitoring in Gauss (no input monitoring unless active recording is enabled -- which would be all the time with sound on sound looping), but with extra steps. Thank you for taking the time to think about and explain solutions though -- I really appreciate it.

    I see. I should have tested this before posting.

    After testing, I see now that in Overdub mode record monitors the input signal. I mistakenly thought that it behaved the same in Overdub and Replace modes with respect to the monitor input setting.

    @brambos: this feels like a bug to me. The input monitor setting is ignored while recording with overdub on. It seems like in overdub mode should work the same as replace mode currently does on this regard.

    It also explains a source of confusion that I had when I first started using it.

    It's not a bug. I actually spent 2 weeks rewriting my entire engine to be able to let it behave like this. Hainbach was quite adamant that this is the way to go: being able to hear what you're recording, while you're recording.

    Disabling this behavior will probably be very tricky (=nigh impossible without making lots of very fundamental changes). It has to do with being able to achieve the what-you-hear-is-what-you-get with all the overdubbing-speed-changing-warbling effects immediately audible. It's a little bit more involved to do than with a regular looper that doesn't do realtime continuous speed-changes.

    One could still hear what you’ll get by turning input monitoring on when you overdub, no? It seems like that method would add choice and flexibility. From a user perspective it is odd that the overdub and non-overdub modes work differently in this regard.

    It's not that simple. What you hear is what you've recorded combined with the overdubbed material. I can't separate the two anymore at that point. So you either hear everything, or get complete silence.

    Ok, this is fair enough and I appreciate the explanation -- the technical details make sense to me as much so as is possible from a high level explanation! I'll see if I can figure out a way to get it to work as I really do love the sequencer (the pre-looper delay mentioned above is a good idea).

    Just in case there's any ambiguity over this use case still, I did a little searching on youtube and found a video of some guy explaining how he sets his own equipment up to run in parallel to his looping software:

    The way I do it uses different gear (one channel on mixing desk for direct signal and a return channel on same desk for the return signal which has has digital latency) but overall the same principle applies. The advantage of this flow is that you can turn up your digital latency buffer much higher and still play your instrument with zero latency.

  • edited January 2021

    @brambos said:
    It's not a bug. I actually spent 2 weeks rewriting my entire engine to be able to let it behave like this. Hainbach was quite adamant that this is the way to go: being able to hear what you're recording, while you're recording.

    I like it this way too. Just makes more sense with how the loop is effected by the sequencer/controls.

Sign In or Register to comment.