Implemented Avoid amp block muting if channel is not changed on a scene change

AlbertA

AlbertA

Fractal Fanatic
I have a preset: http://axechange.fractalaudio.com/detail.php?preset=6244

where in all scenes, the amp is set to Channel A. But as I switch scenes, I get a small silence gap on the amp output.

Would it be possible in instances where the channel is not changed at all to avoid the gap altogether as scenes are switched?

Edit:
Attached is a much simpler patch that shows the issue.
It's IN 1->AMP->OUT1
And an CMP block attached to nothing.

In Scene 1, AMP is in channel A, CMP is in channel A.
In Scene 2, AMP is in channel A, CMP is in channel B.

Even though the amp block is always in channel A for all scenes, going from scene 1 to scene 2 you have a gap of silence.
 

Attachments

  • Simple Gap.syx
    48.2 KB · Views: 0
Last edited:
the gap is being caused by the Synth blocks changing channels. i deleted both Synth blocks and the Amp and guitar sound has no gap when changing Scenes.

perhaps wishing for no gap on Synth channel changes is a better way to phrase this.

i'm not sure if Amp channel not switching during Scene change can always be silent, due to how some other blocks work.
 
chris said:
yes.
Click to expand...

I see what you mean now.
It seems that If ANY block in the grid switches channels, the amp block automatically gets the silence gap even if the amp block doesn't switch channels itself.

I think the thread title is still applicable though as that's the wish.
 
Last edited:
Hmm... I'll have to test this later.

I have the Drive block(s) changing channels in several scenes, although I haven't really tried doing any of this in while listening to the changes yet.
 
Definitely confirmed for me. I checked with both Compressor and Wah blocks.

Using scenes to change channels (with identical settings on both) incurs an audio gap.

Changing channels directly when not changing scenes does not exhibit this behavior.
 
FractalAudio said:
That would double the CPU usage as both channels would need to run simultaneously. The vast majority of people wouldn't want that.
Click to expand...
I think you're mistaken. (Or perhaps don't know precisely what my proposal was.)

It would double the CPU usage, specifically, only for whichever blocks were crossfading.

IF...
you have a Preset containing 20 blocks,
and out of those 20 blocks, 2 are going to change channels during the Scene changes,
and the remainder stay as they are (or use Scene Controllers to change parameter values),

THEN...
the resulting Preset does not need to double its Total CPU usage in order to crossfade those 2 blocks;
no,
the resulting Preset will only use twice as much CPU for those 2 blocks,
whereas the CPU for the other blocks will remain as it was before,
which means the total CPU for the whole preset will increase somewhat,
but not by 100%. It won't double.

MEANWHILE...
there will be a smooth transition from one Scene to the next,
with no gaps,
and a smooth crossfade for the blocks that are changing,
which is a more-musical way to change tones.

I think that lots of people would enjoy the experience of that.

(Which is why the proposal generally gets strong support
from those who carefully read through the original post.)
 
Last edited:
Dr. Dipwad said:
I think you're mistaken. (Or perhaps don't know precisely what my proposal was.)

It would double the CPU usage, specifically, only for whichever blocks were crossfading.

IF...
you have a Preset containing 20 blocks,
and out of those 20 blocks, 2 are going to change channels during the Scene changes,
and the remainder stay as they are (or use Scene Controllers to change parameter values),

THEN...
the resulting Preset does not need to double its Total CPU usage in order to crossfade those 2 blocks;
no,
the resulting Preset will only use twice as much CPU for those 2 blocks,
whereas the CPU for the other blocks will remain as it was before,
which means the total CPU for the whole preset will increase somewhat,
but not by 100%. It won't double.

MEANWHILE...
there will be a smooth transition from one Scene to the next,
with no gaps,
and a smooth crossfade for the blocks that are changing,
which is a more-musical way to change tones.

I think that lots of people would enjoy the experience of that.

(Which is why the proposal generally gets strong support
from those who take the time to read the original post
carefully and understand it what it's requesting.)
Click to expand...
It's a good idea but would be extremely difficult, if not impossible, to implement.
 
FractalAudio said:
It’s not the amp block muting. The output mutes during a scene change if any blocks change channels. This is necessary to prevent pops and clicks.
Click to expand...

Oh. I was under the impression that it was the block output. Because if you take a look at the attached patch, which has a synth block with a simple sine wave, there's no output gap overall, just the amp block it seems.

In this patch the synth in scene 1 is in channel A and and scene2 synth is in channel B. Both channels have identical settings.

In this case, there's no gap in the output itself. I hear the sine wave continuously, but the amp block does have that small gap.

You can see that below; the highlighted section is where I switched scenes - the amp block has gone silent in that gap, so you just see the sine wave from the synth block there.


reaper_screenshot.png
 

Attachments

  • Simple Gap 2.syx
    48.2 KB · Views: 1
Last edited:
FractalAudio said:
It’s not the amp block muting. The output mutes during a scene change if any blocks change channels. This is necessary to prevent pops and clicks.
Click to expand...
This feels like a bit of a step backwards from the Axe Fx II...

It could sound very odd to have my delay tails interrupted just because I change channels via a scene change.

For many other cases, I'm sure natural breaks in the music would cover this.
 
unix-guy said:
This feels like a bit of a step backwards from the Axe Fx II...

It could sound very odd to have my delay tails interrupted just because I change channels via a scene change.

For many other cases, I'm sure natural breaks in the music would cover this.
Click to expand...

I'm not sure which outputs are muted. Because switching channels in an Amp block, whether on its own or when changing scenes, does not affect reverb / delay trails in any way.
 
yek said:
I'm not sure which outputs are muted. Because switching channels in an Amp block, whether on its own or when changing scenes, does not affect reverb / delay trails in any way.
Click to expand...
Hmm... I think we need clarification.

Cliff said the Amp block is not muting.

The testing I did was specifically NOT changing channels on the amp, but on other blocks. I was only listening for the gap, not whether the trails were affected... But if it's the Output blocks being muted, then I assumed they would.
 
Dr. Dipwad said:
I think you're mistaken. (Or perhaps don't know precisely what my proposal was.)

It would double the CPU usage, specifically, only for whichever blocks were crossfading.

IF...
you have a Preset containing 20 blocks,
and out of those 20 blocks, 2 are going to change channels during the Scene changes,
and the remainder stay as they are (or use Scene Controllers to change parameter values),

THEN...
the resulting Preset does not need to double its Total CPU usage in order to crossfade those 2 blocks;
no,
the resulting Preset will only use twice as much CPU for those 2 blocks,
whereas the CPU for the other blocks will remain as it was before,
which means the total CPU for the whole preset will increase somewhat,
but not by 100%. It won't double.

MEANWHILE...
there will be a smooth transition from one Scene to the next,
with no gaps,
and a smooth crossfade for the blocks that are changing,
which is a more-musical way to change tones.

I think that lots of people would enjoy the experience of that.

(Which is why the proposal generally gets strong support
from those who carefully read through the original post.)
Click to expand...
Carefully reading a post does not make it easier or more possible to implement. There is an assumption and critical issue in the idea as far as actual implementation, and repeating it or stretching it out with more words doesn’t make it go away. Again, great idea and no one is saying people don’t want crossfades or seamless anything. As described, it’s a huge, huge ask.
 
You must log in or register to reply here.
Back
Top Bottom