Is this how spillover is intended to work?

unix-guy said:
As mentioned, if you think it's a bug then submit a bug report.

There have been wishes and multiple threads on the topic.

I would be very surprised if Fractal is unaware of this, and they don't let bugs linger for years...

So my own assumption would be that this is "as designed". For whatever that's worth ;)
Click to expand...
Wasn't it that spillover used to work only between scenes and not between presets? And then they fixed it to allow spillover between presets only if the preset you changed to had the same block in it? I feel like I remember it happening that way, but I could easily be misremembering.

If that is the way it happened then this is probably one of those unintended consequences of trying to find a relatively simple solution to a feature request (spillover between presets).

I'm guessing they'd need to reallocate a certain amount of memory to spillover effects and have that memory persist while the rest of the "preset memory" gets cleared to load the new preset. I'm also guessing that's a pretty monumental programming task. I say all that knowing full well that I have no idea what I'm talking about so it could be complete nonsense. 😂
 
Deadpool_25 said:
Wasn't it that spillover used to work only between scenes and not between presets? And then they fixed it to allow spillover between presets only if the preset you changed to had the same block in it? I feel like I remember it happening that way, but I could easily be misremembering.

If that is the way it happened then this is probably one of those unintended consequences of trying to find a relatively simple solution to a feature request (spillover between presets).

I'm guessing they'd need to reallocate a certain amount of memory to spillover effects and have that memory persist while the rest of the "preset memory" gets cleared to load the new preset. I'm also guessing that's a pretty monumental programming task. I say all that knowing full well that I have no idea what I'm talking about so it could be complete nonsense. 😂
Click to expand...

Like you I have no idea as to what it takes to program spillover on a modeler. I know it gets really involved when you have to reload DSP which is why it appears to be easier to deliver spillover/trails between scenes. Essentially though it requires the trails from delays and reverb to persist into the next preset, or the next scene or channel change.

As has already been stated on this thread though, there is an assumption that one of spillover's defining features is that it is tempo and duration based. Not a discrete sequence to be pasted in regardless of your position in a song, or even worse, when you are switching to a preset/scene/channel long after the duration of the trails has been exceeded. Spillover should automatically be flushed or muted if the next preset/channel does not include the identical blocks required to enable it. Not left lurking for the next time those blocks show up.

Even in this much less than ideal example, if there was a gap between switching presets/channels, spillover would need to be running in the background or in some manner, accounting for the gap. If you have repeats set so there are 10, and switching the preset eats up five of those, you should only hear five spillover repeats on the new preset, not ten. Probably a wildly erroneous example, just trying to illustrate the primacy of tempo and duration, over switching, for spillover.

Btw, is the OP saying that this "bug" can also pop up intra-preset when channel switching, or only when switching presets? I could see where if this problem is happening between presets, it might also be showing up with channel switching, as channel switching might involve some reloading of the DSP or whatever mechanics are involved in not being able to do gapless switching. Similar to preset switching operation rather than scenes.
 
Last edited:
playmusic said:
Spillover should automatically be flushed or muted if the next preset/channel does not include the identical blocks required to enable it. Not left lurking for the next time those blocks show up.
Click to expand...
A flush is needed (because muting implies it could still get unmuted).

playmusic said:
Btw, is the OP saying that this "bug" can also pop up intra-preset when channel switching, or only when switching presets?
Click to expand...
I don't know about that; in a single preset you always have that block in the grid, it might have different requirements, i haven't thought that through...
 
Curious question for @md1234: do you actually want spillover to occur on preset changes?

If not just turn it off in the global settings and you won't have the problem.
 
md1234 said:
A flush is needed (because muting implies it could still get unmuted).
Click to expand...

When I presented the choices to flush or mute, it was in the context of either approach resulting in nothing audible remaining in the queue past the first preset switch if it did not meet the spillover criteria (identical delay/reverb blocks). I did not intend to imply muting would leave the spillover resident until the correct blocks showed up. That is exactly what we need to avoid.

If a tree falls in the forest, and you can't see/hear it, did it really happen? You know, that old chestnut. Don't know if muting or flushing is easier to program when it comes to keeping undesired spillover from popping up. Maybe it is easier to mute it than flushing it or a combination of the two depending on the circumstances. Fractal's developers can determine that. Either way the overarching interest is not to hear it when it shouldn't be included.
 
unix-guy said:
...

Also, as far as I know, "spillover" only applies to preset changes. It isn't spillover when changing scenes.
Click to expand...

If this bug doesn't affect scene changes, I am making the assumption that it also doesn't happen between channels as scenes often include a channel switch. Excellent!

Enabling spillover between presets is a rare to never thing for me coming from other platforms. Although it would be my selected default behavior if there weren't usually a cost attached to it. Not even an option on some devices.
 
Last edited:
unix-guy said:
Curious question for @md1234: do you actually want spillover to occur on preset changes?
Click to expand...
Good and also a fair question! Yes i want it.

This occurs to me on regular basis: imagine playing a set, and after song 1 (preset with plex block) there is sooner than expected a count in for song 2 (preset without plex block)... so right at the end of the count-in (spillover wasn't finished) you hit the next-preset switch and play. Full band intro, so nobody in the audience notices the cut off spillover. From that moment the remaining spillover is lurking (thank you @playmusic ;)) until you switch to a preset (say song 3) with the plex block, which is always the surprise in a silent moment between songs ;)

For a long time i didn't understand where it came from, but now i know how this happens I decided to report it here. Of course there are workarounds possible, or other approaches, but i cannot think of any scenario where one would want the remaining spillover after such a long time. There could be technical reasons however, but if you never ask then you never know.
 
playmusic said:
What is the correct terminology in the Fractalverse for spillover/trails between scenes?
Click to expand...
If you change scenes, there's nothing to spill over. You get the results from that block in that scene. Scenes are not independent signal chains like presets.

I don't know the best way to write it... But there should be no interruption in the sound from a Delay or Reverb when changing scenes - unless you change channels on the block to something with different settings. And then you'll get the results of those settings.

playmusic said:
If this bug doesn't affect scene changes, I am making the assumption that it also doesn't happen between channels as scenes often include a channel switch. Excellent!
Click to expand...
See above.
 
Was trying to draw some comparisons in my head between the Helix and FM9 as I am more familiar with the Helix (apologies for mentioning another company). On the Helix, for example, enabling spillover between presets, requires changing a global setting which halves the DSP available in a preset, but allows preset spillover. Enabling spillover between scenes, which they call "trails", requires enabling a preset-level parameter - 'Trails'. The 'Trails' setting is located in the delay and reverb blocks. So, on the Helix, there is a substantial penalty for spillover between presets, but none for scenes. Additionally, scenes allow trails or no-trails for reverbs and delays between scene switches.

On the FM9, there is, like the Helix, a global setting for spillover between presets. Where things were new to me was how to enable/disable spillover between scenes. To do this on the FM9 you use the various mute options available for bypass. Slightly different mute options for serial or parallel paths, but they can still work to enable or disable spillover between scenes on the FM9. For example, selecting 'Mute FX Out' or 'Thru' in a delay or reverb block in a serial path will disable the spillover between scenes. In this respect, analogous to the 'Trails' parameter on the Helix.
 
Last edited:
md1234 said:
I have read several things about spillover here and in the wiki, but it's unclear to me if this behavior is expected.


Situation:
  • Preset 1 has plex block.
  • Preset 2 has no plex block.
  • Preset 3 has plex block.

From 0:02 - 0:08 you hear preset 1 with the plex block, this is normal.
From 0:10 i play again but switch fast to preset 2 and stay there for a while (could be the length of a song for instance).
From 0:33 i switch to preset 3 and i hear the remaining 'spillover' from preset 1, in this case after 23 seconds (but would also happen after two minutes or after two hours...).

My question is this: is the behavior correct that after seconds, minutes, hours, days, the plex block in preset 3 still processes the remaining spillover from preset 1?
Click to expand...


This issue comes up frequently on the forum, although it's usually reported in the context of scenes/channels. Strictly speaking, it doesn't have anything to do with spillover, it's just an undesirable artifact due to the way that different delay types maintain independent buffers which never get cleared, so when you switch back to a delay type after switching away from it for a while (as you've done here at step 3), the delay buffer unexpectedly resumes.

One suggestion that has been frequently made to fix this problem is: the delay buffer should be cleared whenever the delay type changes. In your case that would be when switching to preset 2.

Considering how often this problem gets reported, it's probably safe to say FAS is aware of it. You could contact tech support to check on the status of a fix.
 
playmusic said:
To do this on the FM9 you use the various mute options available for bypass. Slightly different mute options for serial or parallel paths, but they can still work to enable or disable spillover between scenes on the FM9. For example, selecting 'Mute FX Out' or 'Thru' in a delay or reverb block in a serial path will disable the spillover between scenes.
Click to expand...
Bypass modes of different mute types are only relevant when you bypass the block.

It has nothing to do with scenes except in the case that you're bypassing the block on scene change.

The behavior happens any time the block is bypassed.
 
unix-guy said:
Bypass modes of different mute types are only relevant when you bypass the block.

It has nothing to do with scenes except in the case that you're bypassing the block on scene change.

The behavior happens any time the block is bypassed.
Click to expand...

Good points!
 
md1234 said:
Good and also a fair question! Yes i want it.

This occurs to me on regular basis: imagine playing a set, and after song 1 (preset with plex block) there is sooner than expected a count in for song 2 (preset without plex block)... so right at the end of the count-in (spillover wasn't finished) you hit the next-preset switch and play. Full band intro, so nobody in the audience notices the cut off spillover. From that moment the remaining spillover is lurking (thank you @playmusic ;)) until you switch to a preset (say song 3) with the plex block, which is always the surprise in a silent moment between songs ;)

For a long time i didn't understand where it came from, but now i know how this happens I decided to report it here. Of course there are workarounds possible, or other approaches, but i cannot think of any scenario where one would want the remaining spillover after such a long time. There could be technical reasons however, but if you never ask then you never know.
Click to expand...
I will +1 this being a bug.

Spillover should, IMHO, be between two presets that match whatever criteria. Not between N (where N is between 1-inf) preset changes.

I hope The Maker agrees, or can enlighten us.

Edit: I suppose the desired case is more like N consecutive preset changes that match the same criteria on each change. I.E., you may have 4 presets that share the spil't block and want spillover for all changes through/between them.
 
Dug up this bug?-thread because of what's mentioned in the 'Axe FXIII 28.00 public beta 4' thread about improved behavior of spillover. I'm surprised that i cannot reproduce anymore what i started this thread with on the FM9. So something seems to be changed/improved along the way in the FM9 firmware, intentionally or not.

I'm curious about other people's experience with this, especially those that participated in this thread.

FWIW I do hear some soft crackling as 'remaining spillover'...
 
md1234 said:
Dug up this bug?-thread because of what's mentioned in the 'Axe FXIII 28.00 public beta 4' thread about improved behavior of spillover. I'm surprised that i cannot reproduce anymore what i started this thread with on the FM9. So something seems to be changed/improved along the way in the FM9 firmware, intentionally or not.

I'm curious about other people's experience with this, especially those that participated in this thread.

FWIW I do hear some soft crackling as 'remaining spillover'...
Click to expand...

I tried it a few weeks ago on the Axe-FX and it was fixed (although I might have been testing delay or reverb blocks which had the same problem). I don't recall seeing any mention of that in release notes so I can't tell you when it was fixed, but it does appear the solution I described above has been implemented.
 
GlennO said:
I don't recall seeing any mention of that in release notes so I can't tell you when it was fixed, but it does appear the solution I described above has been implemented.
Click to expand...
I removed the Bug? prefix from the thread. Thanks for your input.
 
You must log in or register to reply here.
Back
Top Bottom