Is this how spillover is intended to work?

md1234

md1234

Experienced
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?
 
Honestly, there is always an audio gap when switching presets so turning on preset spillover is less than ideal. If you want spillover keep it in the same preset with various scenes.
 
Like i said, I just want to know if it is intended that a block keeps the remaining spillover forever in memory (or so), waiting patiently until you arrive at any preset with that block, to release it.

When gigging, it is at least two or more songs (and minutes) later, that right before a song starts, i choose the song-preset, and there is a risk of getting/hearing the remaining spillover.

So... is this behavior intended? Because in my opinion the spillover should get released in the same amount of time as it would when you stayed in the preset. Whether that is hearable depends on the block presence and state of the next preset(s).
 
md1234 said:
Like i said, I just want to know if it is intended that a block keeps the remaining spillover forever in memory (or so), waiting patiently until you arrive at any preset with that block, to release it.

When gigging, it is at least two or more songs (and minutes) later, that right before a song starts, i choose the song-preset, and there is a risk of getting/hearing the remaining spillover.

So... is this behavior intended? Because in my opinion the spillover should get released in the same amount of time as it would when you stayed in the preset. Whether that is hearable depends on the block presence and state of the next preset(s).
Click to expand...

I don’t believe it should be an issue. Unless… you have navigated to Setup > Global Settings > Effect Mixing and enabled Spillover. This is preset spillover. If you just want spillover across Scenes in a given Preset (as I suggested above) set the value of this setting to “OFF”.
 
IMO it should not retain the spillover like that. I am surprised that it is even still in memory after a second preset change. Looks like a bug.
 
md1234 said:
When gigging, it is at least two or more songs (and minutes) later, that right before a song starts, i choose the song-preset, and there is a risk of getting/hearing the remaining spillover.

So... is this behavior intended? Because in my opinion the spillover should get released in the same amount of time as it would when you stayed in the preset. Whether that is hearable depends on the block presence and state of the next preset(s).
Click to expand...

Sadly this is the way Fractal has programmed the decay for the Plex block... although it also exists on the delay and possibly reverb. Presets, Scenes, Channel changes can all be triggers. Ideally the decay should process as per settings and then stop vs being retained in buffer.

https://forum.fractalaudio.com/thre...ver-buffer-best-practice.183689/#post-2371135

I agree it's not a practical option for live environments. It's really the only major detractor on the Fractal (at least for me).

I will regularly kneel over, turn down the output in order to switch scenes/presets with ambient settings, and then turn the output back up to avoid the decay wash. There's a wish for this to be fixed which you can add your voice to.

https://forum.fractalaudio.com/threads/forget-trails-when-channel-switching.192096/
 
Last edited:
Don't think this can be dismissed as "by design". This is very, very, broken and can make spillover unusable for live performance. Changing it is no wish or feature request. It is a bug that needs to be fixed.
 
playmusic said:
Don't think this can be dismissed as "by design". This is very, very, broken and can make spillover unusable for live performance. Changing it is no wish or feature request. It is a bug that needs to be fixed.
Click to expand...
You seem to be making an assumption that Cliff is not aware of this. It has been this way for a long, long time.

But if you really think it's a bug, submit a bug report.
 
unix-guy said:
You seem to be making an assumption that Cliff is not aware of this. It has been this way for a long, long time.

But if you really think it's a bug, submit a bug report.
Click to expand...

Not making any assumption nor assertion that Cliff is unaware of this. Weird that this has been around for a long time. This seems like something that would have been fixed. What is the rationale for it or benefit? Just appears to clearly qualify as a bug when a loud sound come bursting in out of nowhere from a buffer after two preset switches as demonstrated in the video. Don't mean to come off as confrontational, just unequivocal.
 
playmusic said:
Not making any assumption nor assertion that Cliff is unaware of this. Weird that this has been around for a long time. This seems like something that would have been fixed. What is the rationale for it or benefit? Just appears to clearly qualify as a bug when a loud sound come bursting in out of nowhere from a buffer after two preset switches as demonstrated in the video. Don't mean to come off as confrontational, just unequivocal.
Click to expand...
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 ;)
 
It is probably fair to assume that a fix would require a extensive overhaul of how these blocks are coded and may have other trade-offs...

Is it by design? Perhaps... That obviously doesn't make it a feature (assuming features are positives). In my live use correcting this issue would outweigh an extra 5 amps and 3 drive pedals however 😂
 
unix-guy said:
But if you really think it's a bug, submit a bug report.
Click to expand...
playmusic said:
Only been on the forum a couple of weeks....
Click to expand...
playmusic said:
that a "feature" that has been around for years is actually a bug
Click to expand...
Well, i'm here a bit longer (almost a year), i respect the makers of this beautiful product and am very happy with what it does.

It also feels like a bug to me, be it a more functional then technical bug. Since i already started this thread i'll add the 'Bug?' prefix and see what happens.
 
Same goes for the Reverb Block - if you are changing the echo density and the quality (by keeping the same algorithm), the tail will be preserved. I thought this to be an odd choice, since from a technical perspective it makes sense (channel not active, so no additional processing power used to simulate the decay of an inactive channel noone hears). From the principle of least surprise, it is odd.
There are workarounds, but they are...workarounds.

Maybe it would make sense to add a control element which lets the user deceide the behaviour on channel switch?
 
You must log in or register to reply here.
Back
Top Bottom