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.

Loopy Pro misses the attack in the first note in a loop.

For some reason LP continuously softens the transient on the first note on a loop. Testing with just a snare sound as a metronome, I can see the full waveform being recorded, but it seems the attack is softened on playback. Always on the first note of the loop, unless I start the recording a little early...almost like a flam. I tried different audio interfaces, internal mic and triggering methods (midi, touchscreen, etc)...the result is generally the same. Any ideas?

Comments

  • Swipe up on the loop, and at the bottom of the dialog that pops up, turn off the “microfade” at the beginning of the loop.

  • @coolout said:
    For some reason LP continuously softens the transient on the first note on a loop. Testing with just a snare sound as a metronome, I can see the full waveform being recorded, but it seems the attack is softened on playback. Always on the first note of the loop, unless I start the recording a little early...almost like a flam. I tried different audio interfaces, internal mic and triggering methods (midi, touchscreen, etc)...the result is generally the same. Any ideas?

    By default, loopy microcrossfades the beginning and end to avoid clicks in addition to the microfade jebni mentioned. In global clip settings or individual settings you can reduce or eliminate that crossfade. The setting is loop boundary crossfade.

  • wimwim
    edited February 6

    Turning off "Play Outro in Loop" can also help with this sometimes. If you have an outro "tail" playing back over the first note, it can sometimes alter the beginning in unexpected ways.

  • edited February 7

    Thanks for the suggestions everyone, I'm now thinking there's some slight latency with either the mute/unmute follow actions or the recording toggle. It seems to miss the very start of the recording, yet it's also catching too much of the end of the recording. Even if I just use the touchscreen with the built-in mic, it will slightly miss the beginning of the recording and then include the sound of me tapping the screen (to stop recording) into the end of the loop. Strange. I have 2 hardware loop pedals so I know this isn't normal behavior with my usual finger drumming timing. Perhaps this is a ipad limitation. I'm using an ipad 8 at the lowest buffer.

    It may also be how I've set up Follow Actions in my project to work with my setup. I'm using a SP-404 MK2 for midi control over Loopy, external FX, and as an audio interface over USB. Although the project is simple, the audio routing is a little complex as the 404 has it's own internal routing. Loopy's audio input bus and Bus A stay muted unless it's recording a track. At that point, the color groups are muted, then on playback they switch.

    It's constantly flipping between muting the color groups and input/A busses depending if it's recording/overdubbing or playing back. That's the only way I've found to be able to use both the Loopy and 404 together seamlessly. I can record the 404's internal samples plus any other devices connected to the 404's analog inputs into Loopy Pro, then process the loops through the 404's FX. It's a great seamless combo except for this slight issue I'm having with recording latency. Worst case scenario, I'll just have to train myself to start the first loop recording a little early (as a flam) instead of hitting both pads simultaneous 'on the 1'.

  • wimwim
    edited February 7

    @coolout - Could be totally unrelated, but one thing I didn't realize in the beginning was that recording was starting on release of my finger from the screen, not press. There's a global setting to set preferences for that now.

  • @coolout : sounds like there are a few things sussing out independently.

    when triggering with touch, the trigger (unless you change the settings) is when you release not when you press. So, pre-plant your finger and release to start. To stop, pre-plant and release to stop recording. You can switch to press but it is less accurate. Michael’s video is worth watching.

    For midi triggering, first try a simple case where you create a new default project with Loopy’s default. Midi learn one clip. Test recording latency with that. Make sure auto-loop detection is off. Don’t add any follow-actions or any possibly confounding elements. Have all synchronization off. We just want to test the basics.

    After you record, if the first transient is blurred, set loop boundary crossfade to 0. Turn off the microfade for the clip.

  • Thanks again guys, I totally forgot it records on touch release vs press. I took a year off from first buying Loopy Pro. I’ll need to go back and test audio latency with the 404 and a more basic project now.

  • edited February 10

    SOLVED!!! After double checking my 404's latency (it's fine) and routing with a default project, it was really the follow actions of muting the input bus, which turned out to be unnecessary. It was cutting off the beginning of the recording. There seems to be a slight lag in Loopy Pro's mute behavior. I also noticed with my follow actions to mute/unmute the color groups during recording, if I don't order the mute/unmute of the group that's recording FIRST, there's slight bleed over from the other tracks right at the beginning. The mutes are not happening fast enough even though they're set for immediate. Perhaps that's something for the bug list.

    I guess a lot of folks are using mostly iOS internal routing or using Loopy Pro at the end of a hardware chain, where I'm using multiple send/return loops (analog, digital, and internal). Auto-flipping between color groups and a bus send is the only way I've been able to utilize everything without making feedback loops.

  • @coolout said:
    SOLVED!!! After double checking my 404's latency (it's fine) and routing with a default project, it was really the follow actions of muting the input bus, which turned out to be unnecessary. It was cutting off the beginning of the recording. There seems to be a slight lag in Loopy Pro's mute behavior. I also noticed with my follow actions to mute/unmute the color groups during recording, if I don't order the mute/unmute of the group that's recording FIRST, there's slight bleed over from the other tracks right at the beginning. The mutes are not happening fast enough even though they're set for immediate. Perhaps that's something for the bug list.

    I guess a lot of folks are using mostly iOS internal routing or using Loopy Pro at the end of a hardware chain, where I'm using multiple send/return loops (analog, digital, and internal). Auto-flipping between color groups and a bus send is the only way I've been able to utilize everything without making feedback loops.

    Are there effects on the channels you notice latency on when unmuting?

    Also , be aware that with follow actions that end recording happens a tiny bit later than one might think.

    Are the muting/unmuting happening in the follow actions?

    Can you summarize how you have it setup?

  • @espiegel123 said:

    @coolout said:
    SOLVED!!! After double checking my 404's latency (it's fine) and routing with a default project, it was really the follow actions of muting the input bus, which turned out to be unnecessary. It was cutting off the beginning of the recording. There seems to be a slight lag in Loopy Pro's mute behavior. I also noticed with my follow actions to mute/unmute the color groups during recording, if I don't order the mute/unmute of the group that's recording FIRST, there's slight bleed over from the other tracks right at the beginning. The mutes are not happening fast enough even though they're set for immediate. Perhaps that's something for the bug list.

    I guess a lot of folks are using mostly iOS internal routing or using Loopy Pro at the end of a hardware chain, where I'm using multiple send/return loops (analog, digital, and internal). Auto-flipping between color groups and a bus send is the only way I've been able to utilize everything without making feedback loops.

    Are there effects on the channels you notice latency on when unmuting?

    Also , be aware that with follow actions that end recording happens a tiny bit later than one might think.

    Are the muting/unmuting happening in the follow actions?

    Can you summarize how you have it setup?

    Nah, there are no AU plugins in Loopy adding latency. That's the first thing I checked. The muting/unmuting is all happening with follow actions. I agree the lag causing the bleed could be from other follow actions like end recording.

    Without going super deep into it, the setup is essentially 2 separate send/return loops (one analog, one over USB), but both types of I/O share the same channels on the SP-404. The 404 is also sending it's internal samples and applying hardware FX to all 3 sources (internal samples, ipad loops, and external stuff). I'm also using a row of 404 pads to control Loopy Pro, so it's more working in the background while the 404 is the centerpiece.

  • @coolout said:

    @espiegel123 said:

    @coolout said:
    SOLVED!!! After double checking my 404's latency (it's fine) and routing with a default project, it was really the follow actions of muting the input bus, which turned out to be unnecessary. It was cutting off the beginning of the recording. There seems to be a slight lag in Loopy Pro's mute behavior. I also noticed with my follow actions to mute/unmute the color groups during recording, if I don't order the mute/unmute of the group that's recording FIRST, there's slight bleed over from the other tracks right at the beginning. The mutes are not happening fast enough even though they're set for immediate. Perhaps that's something for the bug list.

    I guess a lot of folks are using mostly iOS internal routing or using Loopy Pro at the end of a hardware chain, where I'm using multiple send/return loops (analog, digital, and internal). Auto-flipping between color groups and a bus send is the only way I've been able to utilize everything without making feedback loops.

    Are there effects on the channels you notice latency on when unmuting?

    Also , be aware that with follow actions that end recording happens a tiny bit later than one might think.

    Are the muting/unmuting happening in the follow actions?

    Can you summarize how you have it setup?

    Nah, there are no AU plugins in Loopy adding latency. That's the first thing I checked. The muting/unmuting is all happening with follow actions. I agree the lag causing the bleed could be from other follow actions like end recording.

    Without going super deep into it, the setup is essentially 2 separate send/return loops (one analog, one over USB), but both types of I/O share the same channels on the SP-404. The 404 is also sending it's internal samples and applying hardware FX to all 3 sources (internal samples, ipad loops, and external stuff). I'm also using a row of 404 pads to control Loopy Pro, so it's more working in the background while the 404 is the centerpiece.

    Can you explain which follow actions and how they are used? it might not be latency. For example, if unmute is used in begin recording, the recording has already started when unmute is called.

  • @espiegel123 said:

    @coolout said:

    @espiegel123 said:

    @coolout said:
    SOLVED!!! After double checking my 404's latency (it's fine) and routing with a default project, it was really the follow actions of muting the input bus, which turned out to be unnecessary. It was cutting off the beginning of the recording. There seems to be a slight lag in Loopy Pro's mute behavior. I also noticed with my follow actions to mute/unmute the color groups during recording, if I don't order the mute/unmute of the group that's recording FIRST, there's slight bleed over from the other tracks right at the beginning. The mutes are not happening fast enough even though they're set for immediate. Perhaps that's something for the bug list.

    I guess a lot of folks are using mostly iOS internal routing or using Loopy Pro at the end of a hardware chain, where I'm using multiple send/return loops (analog, digital, and internal). Auto-flipping between color groups and a bus send is the only way I've been able to utilize everything without making feedback loops.

    Are there effects on the channels you notice latency on when unmuting?

    Also , be aware that with follow actions that end recording happens a tiny bit later than one might think.

    Are the muting/unmuting happening in the follow actions?

    Can you summarize how you have it setup?

    Nah, there are no AU plugins in Loopy adding latency. That's the first thing I checked. The muting/unmuting is all happening with follow actions. I agree the lag causing the bleed could be from other follow actions like end recording.

    Without going super deep into it, the setup is essentially 2 separate send/return loops (one analog, one over USB), but both types of I/O share the same channels on the SP-404. The 404 is also sending it's internal samples and applying hardware FX to all 3 sources (internal samples, ipad loops, and external stuff). I'm also using a row of 404 pads to control Loopy Pro, so it's more working in the background while the 404 is the centerpiece.

    Can you explain which follow actions and how they are used? it might not be latency. For example, if unmute is used in begin recording, the recording has already started when unmute is called.

    Begin Record:
    Mute (color)
    Unmute A

    Finish Record:
    Mute A
    Unmute (color)

    That's pretty much it.

  • @coolout said:

    @espiegel123 said:

    @coolout said:

    @espiegel123 said:

    @coolout said:
    SOLVED!!! After double checking my 404's latency (it's fine) and routing with a default project, it was really the follow actions of muting the input bus, which turned out to be unnecessary. It was cutting off the beginning of the recording. There seems to be a slight lag in Loopy Pro's mute behavior. I also noticed with my follow actions to mute/unmute the color groups during recording, if I don't order the mute/unmute of the group that's recording FIRST, there's slight bleed over from the other tracks right at the beginning. The mutes are not happening fast enough even though they're set for immediate. Perhaps that's something for the bug list.

    I guess a lot of folks are using mostly iOS internal routing or using Loopy Pro at the end of a hardware chain, where I'm using multiple send/return loops (analog, digital, and internal). Auto-flipping between color groups and a bus send is the only way I've been able to utilize everything without making feedback loops.

    Are there effects on the channels you notice latency on when unmuting?

    Also , be aware that with follow actions that end recording happens a tiny bit later than one might think.

    Are the muting/unmuting happening in the follow actions?

    Can you summarize how you have it setup?

    Nah, there are no AU plugins in Loopy adding latency. That's the first thing I checked. The muting/unmuting is all happening with follow actions. I agree the lag causing the bleed could be from other follow actions like end recording.

    Without going super deep into it, the setup is essentially 2 separate send/return loops (one analog, one over USB), but both types of I/O share the same channels on the SP-404. The 404 is also sending it's internal samples and applying hardware FX to all 3 sources (internal samples, ipad loops, and external stuff). I'm also using a row of 404 pads to control Loopy Pro, so it's more working in the background while the 404 is the centerpiece.

    Can you explain which follow actions and how they are used? it might not be latency. For example, if unmute is used in begin recording, the recording has already started when unmute is called.

    Begin Record:
    Mute (color)
    Unmute A

    Finish Record:
    Mute A
    Unmute (color)

    That's pretty much it.

    Finish recording executes after the post-recording calculations perform. It doesn't happen the exact instant that the end happens.

    If loop A is recording and then loop b starts recording when loop A ends. Loop B's begin recording follow action is executed before Loop A's end recording.

    Since the begin record action triggers as the recording starts, anything in the follow action might not fire exactly at the moment recording starts.

    You can see if quantizing the action to the beat improves the timing, but you are probably better off having the actions triggered with the recording action rather than inside the follow action.

  • I wonder: with your mute and unmute actions, what timing are you specifying — "With Last" or "After Last"?

  • I just checked and Mute and unmute have about a 10 ms ramp...without which one probably risks clicks. So if you have sharp transients firing simultaneous with the unmute, they could be blurred. I suspect any audio software with mute/unmute does the same otherwise clicks would be a problem. I checked AUM. It's ramp takes about 14ms.

  • edited February 12

    “but you are probably better off having the actions triggered with the recording action rather than inside the follow action.”

    @espiegel123 Wait…are you saying there’s a way to trigger mutes/unmutes with the recording action WITHOUT using follow actions? I don’t see the that option anywhere.

    I guess one way would be to assign mute toggles to the same midi buttons, but the mute states could easily get incorrectly flipped (and not record anything) when I hold to clear the recording. I guess I could map clear to different button.

  • @coolout said:
    “but you are probably better off having the actions triggered with the recording action rather than inside the follow action.”

    @espiegel123 Wait…are you saying there’s a way to trigger mutes/unmutes with the recording action WITHOUT using follow actions? I don’t see the that option anywhere.

    I guess one way would be to assign mute toggles to the same midi buttons, but the mute states could easily get incorrectly flipped (and not record anything) when I hold to clear the recording.

    I mean that however you are triggering the recording could also handle the musing etc at the same time.

    How are you initiating the recording?

  • You can add clear follow actions to set things to the proper state..vis-a-vis your comment about clearing.

    With all of this , keep in mind the microfades i mentioned.

  • @espiegel123 said:

    @coolout said:
    “but you are probably better off having the actions triggered with the recording action rather than inside the follow action.”

    @espiegel123 Wait…are you saying there’s a way to trigger mutes/unmutes with the recording action WITHOUT using follow actions? I don’t see the that option anywhere.

    I guess one way would be to assign mute toggles to the same midi buttons, but the mute states could easily get incorrectly flipped (and not record anything) when I hold to clear the recording.

    I mean that however you are triggering the recording could also handle the musing etc at the same time.

    How are you initiating the recording?

    For each of the color group I have assigned a pad on the SP-404 that starts recording, ends recording, overdubs, and clears the loop on hold. This is all from a single button.

    Also, I’m not using any count-in, preset length or preset tempo. The initial loop sets the master tempo with the other loops being multiples or divisions of the initial loop.

  • @coolout said:

    @espiegel123 said:

    @coolout said:
    “but you are probably better off having the actions triggered with the recording action rather than inside the follow action.”

    @espiegel123 Wait…are you saying there’s a way to trigger mutes/unmutes with the recording action WITHOUT using follow actions? I don’t see the that option anywhere.

    I guess one way would be to assign mute toggles to the same midi buttons, but the mute states could easily get incorrectly flipped (and not record anything) when I hold to clear the recording.

    I mean that however you are triggering the recording could also handle the musing etc at the same time.

    How are you initiating the recording?

    For each of the color group I have assigned a pad on the SP-404 that starts recording, ends recording, overdubs, and clears the loop on hold. This is all from a single button.

    Also, I’m not using any count-in, preset length or preset tempo. The initial loop sets the master tempo with the other loops being multiples or divisions of the initial loop.

    Whatever the sp-404 is triggering to start recording (whether a widget or a midi binding ) is calling an action. Let’s say it’s in a binding. Instead of just a play or record action, also have your mute etc in that action binding rather than a single action.

    You may need to experiment with whether they fire in series or at the same time.

    Is the sound that you are sampling coming from the sp?

    You might need to give us a more complete picture of what is connected to what.

    A screen recording demonstrating the issue might be helpful.

  • edited February 12

    @coolout said:
    “but you are probably better off having the actions triggered with the recording action rather than inside the follow action.”

    @espiegel123 Wait…are you saying there’s a way to trigger mutes/unmutes with the recording action WITHOUT using follow actions? I don’t see the that option anywhere.

    I guess one way would be to assign mute toggles to the same midi buttons, but the mute states could easily get incorrectly flipped (and not record anything) when I hold to clear the recording. I guess I could map clear to different button.

    I was having a bit of cognitive dissonance with these two paragraphs. I was thinking that if you could imagine assigning other actions to the same button, and also add multiple follow actions to a clip, then surely the option to mute and unmute without using a follow action would clearly be available to you, right?

    But then I realised that the UI to add follow actions has a “+” button right next to each condition, which advertises the ability to have multiple actions for a clip’s different event conditions:


    image

    Whereas I can only assume that you were creating one-action MIDI commands, each tied to a different event from the one button (press, hold). But you can add a sequence of actions to a single MIDI binding, just like follow actions, except the affordances aren’t quite as obvious:


    image

    As you can see, yes, it has big honking “Add Action” button, but it’s also also miles away from the items in question. Is this the option that you didn’t see?

    Also, if you move your time-critical follow actions to the same MIDI binding and you’re still having timing issues, I’ll return to my question about whether you’ve selected “With Last” or “After Last” for the actions’ timing, because while you said you’d set them to be “immediate”, the latter simply means without a specified delay, rather than “as soon as humanly possible”. A significant part of the timing stems from the type of sequencing you choose, rather than the unit of delay specified.


    image

    Quoting the manual:

    • After Last – perform the action after the previous one has completed. This includes waiting for any count-in for playback/record actions, for instance.

    • With Last – perform the action at the same time as the previous one (do not wait).

    • Next Trigger – perform the action the next time the trigger occurs (e.g. the next button press).

    I’m not sure how long it would take to execute each action (and I know you’re not using count-ins), but my assumption would be that performing those actions concurrently instead of sequentially would shave a couple of milliseconds off. I know you’ve ditched the input muting action because it was redundant, but this info might still be of some use to you.

  • edited February 12

    @Michael, I’m not sure if the UX issues I described in the previous post (which are debatable but compelling enough to me) are the source of @coolout’s issues, but regardless, it might be a good idea to further standardise action-adding UI patterns across the board. I know the button is huge, but it actually missed it the first few times I saw the popover.

    Suggestion:
    image

    And while I applaud your choice of concise language in the action timing UI, without the missing contextual words, i.e. “After the last action”, “After Last” for me reads a bit like word salad on first scan. I do think the UI does imply that context, but perhaps it needs assistance from more or different words. 😆 Sorry, UX designer here, being a dick. Everyone assumes that verbosity in a UI is to be avoided, but sometimes it really removes ambiguity.

  • @coolout : the more that I think of it , the more I think we need a detailed rundown. I can imagine from what you wrote that pressing a button on your SP-404 is both triggering sound locally and initiating actions in loopy pro…if that is the case, audio has already just started when unmuting (which has a microfade) and recording are triggered. That could play into why you are getting the results you are.

  • @espiegel123 said:
    @coolout : the more that I think of it , the more I think we need a detailed rundown. I can imagine from what you wrote that pressing a button on your SP-404 is both triggering sound locally and initiating actions in loopy pro…if that is the case, audio has already just started when unmuting (which has a microfade) and recording are triggered. That could play into why you are getting the results you are.

    The 404 is acting as both the audio interface and midi controller for loopy pro, with the loops playing back through the 404's hardware FX. Whatever audio is routed through the 404 (internal samples or external audio inputs) is recorded into loopy. In order to not create a feedback loop, this requires muting and un-muting different channels depending if loopy is recording or not. My initial issue of the sound being cutoff at the beginning has been solved. The issue I'm having now is kinda the opposite, there's slight bleed over from one color group to the other if I start the recording on "the one". The workaround I've found is after the initial loop, slightly start the record before 'the one' on the second loop (color group). Loopy auto-adjusts the timing so the second loop stays in sync.

  • @jebni said:

    @coolout said:
    “but you are probably better off having the actions triggered with the recording action rather than inside the follow action.”

    @espiegel123 Wait…are you saying there’s a way to trigger mutes/unmutes with the recording action WITHOUT using follow actions? I don’t see the that option anywhere.

    I guess one way would be to assign mute toggles to the same midi buttons, but the mute states could easily get incorrectly flipped (and not record anything) when I hold to clear the recording. I guess I could map clear to different button.

    I was having a bit of cognitive dissonance with these two paragraphs. I was thinking that if you could imagine assigning other actions to the same button, and also add multiple follow actions to a clip, then surely the option to mute and unmute without using a follow action would clearly be available to you, right?

    But then I realised that the UI to add follow actions has a “+” button right next to each condition, which advertises the ability to have multiple actions for a clip’s different event conditions:


    image

    Whereas I can only assume that you were creating one-action MIDI commands, each tied to a different event from the one button (press, hold). But you can add a sequence of actions to a single MIDI binding, just like follow actions, except the affordances aren’t quite as obvious:


    image

    As you can see, yes, it has big honking “Add Action” button, but it’s also also miles away from the items in question. Is this the option that you didn’t see?

    Also, if you move your time-critical follow actions to the same MIDI binding and you’re still having timing issues, I’ll return to my question about whether you’ve selected “With Last” or “After Last” for the actions’ timing, because while you said you’d set them to be “immediate”, the latter simply means without a specified delay, rather than “as soon as humanly possible”. A significant part of the timing stems from the type of sequencing you choose, rather than the unit of delay specified.


    image

    Quoting the manual:

    • After Last – perform the action after the previous one has completed. This includes waiting for any count-in for playback/record actions, for instance.

    • With Last – perform the action at the same time as the previous one (do not wait).

    • Next Trigger – perform the action the next time the trigger occurs (e.g. the next button press).

    I’m not sure how long it would take to execute each action (and I know you’re not using count-ins), but my assumption would be that performing those actions concurrently instead of sequentially would shave a couple of milliseconds off. I know you’ve ditched the input muting action because it was redundant, but this info might still be of some use to you.

    Thanks. I had the actions set as 'after last' instead of 'with last'. The helped a bit but the bleed is still there slightly. The workaround I've found is to start the recordings a little early after the initial loop as Loopy auto-adjusts the timing and doesn't record the bleed (for the most part).

  • @coolout said:

    @jebni said:

    @coolout said:
    “but you are probably better off having the actions triggered with the recording action rather than inside the follow action.”

    @espiegel123 Wait…are you saying there’s a way to trigger mutes/unmutes with the recording action WITHOUT using follow actions? I don’t see the that option anywhere.

    I guess one way would be to assign mute toggles to the same midi buttons, but the mute states could easily get incorrectly flipped (and not record anything) when I hold to clear the recording. I guess I could map clear to different button.

    I was having a bit of cognitive dissonance with these two paragraphs. I was thinking that if you could imagine assigning other actions to the same button, and also add multiple follow actions to a clip, then surely the option to mute and unmute without using a follow action would clearly be available to you, right?

    But then I realised that the UI to add follow actions has a “+” button right next to each condition, which advertises the ability to have multiple actions for a clip’s different event conditions:


    image

    Whereas I can only assume that you were creating one-action MIDI commands, each tied to a different event from the one button (press, hold). But you can add a sequence of actions to a single MIDI binding, just like follow actions, except the affordances aren’t quite as obvious:


    image

    As you can see, yes, it has big honking “Add Action” button, but it’s also also miles away from the items in question. Is this the option that you didn’t see?

    Also, if you move your time-critical follow actions to the same MIDI binding and you’re still having timing issues, I’ll return to my question about whether you’ve selected “With Last” or “After Last” for the actions’ timing, because while you said you’d set them to be “immediate”, the latter simply means without a specified delay, rather than “as soon as humanly possible”. A significant part of the timing stems from the type of sequencing you choose, rather than the unit of delay specified.


    image

    Quoting the manual:

    • After Last – perform the action after the previous one has completed. This includes waiting for any count-in for playback/record actions, for instance.

    • With Last – perform the action at the same time as the previous one (do not wait).

    • Next Trigger – perform the action the next time the trigger occurs (e.g. the next button press).

    I’m not sure how long it would take to execute each action (and I know you’re not using count-ins), but my assumption would be that performing those actions concurrently instead of sequentially would shave a couple of milliseconds off. I know you’ve ditched the input muting action because it was redundant, but this info might still be of some use to you.

    Thanks. I had the actions set as 'after last' instead of 'with last'. The helped a bit but the bleed is still there slightly. The workaround I've found is to start the recordings a little early after the initial loop as Loopy auto-adjusts the timing and doesn't record the bleed (for the most part).

    And did you move the actions from clip follow actions into your MIDI binding? I'm sure that'd save some milliseconds, too — I just don't know how many.

  • @coolout said:

    @espiegel123 said:
    @coolout : the more that I think of it , the more I think we need a detailed rundown. I can imagine from what you wrote that pressing a button on your SP-404 is both triggering sound locally and initiating actions in loopy pro…if that is the case, audio has already just started when unmuting (which has a microfade) and recording are triggered. That could play into why you are getting the results you are.

    The 404 is acting as both the audio interface and midi controller for loopy pro, with the loops playing back through the 404's hardware FX. Whatever audio is routed through the 404 (internal samples or external audio inputs) is recorded into loopy. In order to not create a feedback loop, this requires muting and un-muting different channels depending if loopy is recording or not. My initial issue of the sound being cutoff at the beginning has been solved. The issue I'm having now is kinda the opposite, there's slight bleed over from one color group to the other if I start the recording on "the one". The workaround I've found is after the initial loop, slightly start the record before 'the one' on the second loop (color group). Loopy auto-adjusts the timing so the second loop stays in sync.

    Can you explain precisely the events, acribs and follow actions involved in the situation where you have bleed. Posting screenshots such as jebni has done and the precise order of events and triggers…plus how you have the audio routed is relevant.

    If you are using record end follow actions, understand that they execute AFTER another clip’s play or begin recording action.

    You mentioned that you aren’t using count-ins or count-outs. Is this because you are recording loops that don’t need precise length or timing and the loops aren’t intended to be synchronized?

  • @espiegel123 said:

    @coolout said:
    For some reason LP continuously softens the transient on the first note on a loop…

    By default, loopy microcrossfades the beginning and end to avoid clicks in addition to the microfade jebni mentioned. In global clip settings or individual settings you can reduce or eliminate that crossfade. The setting is loop boundary crossfade.

    I had the same problem as the OP, but this simple fix was all I needed. Thanks so much!!

Sign In or Register to comment.