Is there a way to have spillover when toggling individual loops off?

I am currently setting up an MC8 + ML10x which I’m really enjoying so far.

I’m using a combination of patches and adding specific loops on top of the existing patches. This is to mirror a similar setup coming from using a Gigrig G2. Where I had core patches with things I add on top as needed.

Here’s an example: I have a “base” patch which is a preset in the ML10x. This is a simple preset with everything in the order I want it, but with only a couple of pedals engaged (In my case it’s a preamp plus a reverb). Then when I want to add a delay for example, I’m using the MC8 to toggle on just that loop. I have it set so that going back to the “base” patch clears everything toggled on and restores the “base” patch. So if I select the “base” patch, toggle on fuzz, and toggle on a delay, when going back to the base patch, it disengages those extra 2 loops.

The issue I’m having is that there doesn’t seem to be a way to have spillover work when disengaging an individual loop e.g: a delay. I can get this working going from preset to preset, but not for disengaging indivudual loops. This only works preset to preset by selecting a single specific loop for spillover. Last connected doesn’t seem to work, but I’m not sure what that is supposed to do, and I haven’t yet found anything describing it in the docs. Found the docs here: User Manual

The manual says:

The Spillover feature allow you to merge signals into your output signal when you bypass a selected spillover loop or change Presets where the selected spillover loop isn’t used in the signal chain.

I have been able to get something working as I want in advanced mode (see diagram below) as per this entry in the docs, however the immediate downside of this is that I can’t toggle on loops in advanced mode (which makes sense due to the inherent ambiguity).

As a feature request and assuming there’s no existing way to do this, I think what I’d like is a way to say: “disengage this loop and spillover”, but on a per loop basis.

This would mean that as long as that loop isn’t engaged on the next preset or set of programmed loops, the input would be disconnected but the output of the pedal would still be connected to the main output (I’m thinking this would probably need to provide a choice of which output you want it to go to (tip/ring/both?)). This option would only be available if spillover was enabled in global settings.

In other words the diagram above would represent what would happen if I programmatically bypassed the binson + ardx20 + timeline all in one go to get back to my base sound on the basis I’d configured my toggle off for each of those loops to explicitly “disengage with spillover” if that was possible.

Let me know if clarifications are needed, and let me know if I’ve missed something in the docs.

In simple mode, yes if a loop is bypassed, and if that loop is set to “enable spillover” in the controller settings, then it should be connected to the output. BUT not in parallel like what you require.

The spillover algo in Simple mode works according to your signal chain order.

Here’s an example. Assuming all your loops are enabled for spillover and you have “Last connected” set as the Output spillover:

If your connection sequence in Simple mode looks like this:


Showing the advanced view for clarity:

If you bypass, say, the ARDX20 and Ventris, the connection will look like this:

This replicates your original delayed sounds exactly as though they are all engaged. Hope that makes sense?

I’m not sure if plausible yet but maybe we can add additional CC functions to route the bypassed loop directly to the Output spillover port. Something like “Bypass loop and connect directly to output spillover”.

@james Thanks for the clarifications. I’ll need to retest the “last connected” feature so I can confirm if it’s working for me. As mentioned, I found I was unable to get any spillover using it (in the way it was described here), whereas explicitly listing a loop in “Select Output Spillover” worked as expected.

I also found that the editor seems to “forget” the saved “Select Output Spillover” setting for a preset (which may or may not be related), the saved setting comes back if you switch away from that preset and back to it. I’ll re-check and file a separate topic with the steps to reproduce in the editor bugs area. I wasn’t able reproduce this any more.

I’m not sure if plausible yet but maybe we can add additional CC functions to route the bypassed loop directly to the Output spillover port. Something like “Bypass loop and connect directly to output spillover”.

If that’s viable, that sounds like that would support the use-case I have to get spillover when bypassing loops I’ve added independently on top of presets. I appreciate you considering it.

I’ve filed a separate issue for “Select Output Spillover” not working for me when set to “last connected” here.

I couldn’t reproduce the editor state issue any more.

Following these clarifications around “last connected”, I can clearly see the use-case for retaining the order of effects so that the trails from bypassed loops are still processed by what comes after.

I think this suggests that if it was feasible to have a new CC message that could “Bypass loop and connect directly to output spillover" (as discussed above), whilst that might work in some cases, it wouldn’t work for this case of trying to preserve effect order. However, one way to think about that would essentially be a more granular per-loop version of the explicit spillover for presets that already exists.

Thinking aloud I’m wondering if it would it also be possible to also consider having a new CC message that bypasses “in place” whilst sending spillover trails to the next effect’s input?

To demonstrate (using advanced mode just to draw it) here’s a simple preset:

If you can also have a new CC message that could be applied to the delay loop which can “disengage current loop sending trails in-place” you’d be able to achieve something like this, which preserves the chain.

There’d be some additional things to think through in terms of what the expectations would be for disengaging multiple loops though. For example here’s one ambiguity:

With this next example there’s now two delays:

If you could disengage both delays with a “disengage current loop sending trails in-place” as described above, you’d probably want to be able to do this:

Rather than this:

Of course I understand that all of this depends on whether any of this is practically possible alongside considering all the resulting other implications of such an approach.