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

chris said:
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.
Click to expand...
Chris,

Respectfully, that's not a fair reading of what I said.

I fully understand the complexity of the ask. (The fact that I understand it, in all its detail, is demonstrated by how fully I described it.)

And that's not the only reason for my providing all that detail. Its other purpose is to differentiate it from other things I am not asking for.

History shows that I keep needing to do that.

For example, let's see what happened here, in this thread, earlier today:

When Cliff initially replied, he responded in a way that demonstrated he didn't understand the request.

(If you doubt this, please re-read what he said: He anticipated my request would cause a 100% increase in CPU usage. I had to point him back to the original request and prove that, no, that's not what I am asking for.)

The same issue arose with you, on one prior occasion. [Update/Error-Correction: Chris understood the request; but he and I disagreed about a related issue.] And, a misunderstanding arose with Yek, on a different occasion.

And I respect the heck out of all 3 of you guys! I'm incredibly grateful for all you've done. So it really pains me to say, "Hey, that wasn't what I was asking for; please give it a more careful reading."

But, I have to do that. If I don't, it'd be like me going to Burger King and saying, "Hey, can you add extra bacon to my Whopper with Cheese?" and getting the reply, "Sorry, we don't serve Salmon Mousse here," and just assuming that meant I couldn't get extra bacon.

So, yes, I understand that it's a big ask.

But at least this time, when Cliff replies and says, "Okay, I see what you're asking for now; it's a big ask and won't come soon, if ever...," at least this time I know he's responding to what I actually asked for.

I wouldn't have had that assurance, had I not asked him -- respectfully -- to take a second look at the details.

Make sense?
 
Last edited:
Dr. Dipwad said:
The same issue arose with you, on one prior occasion.
Click to expand...
Can you link to this occasion? In the main thread that you started this suggestion, I only see where you didn’t quite understand my reasoning that the initial suggestion wouldn’t work. I definitely understand your suggestion.
 
chris said:
Can you link to this occasion? In the main thread that you started this suggestion, I only see where you didn’t quite understand my reasoning that the initial suggestion wouldn’t work. I definitely understand your suggestion.
Click to expand...
Sure. I'll have to look around; it may have been during the Axe II period.
 
Chris:

I definitely understand your suggestion.
Click to expand...
I realize that you understand what I'm asking for, now.

But at the time of our earlier conversation -- over a month ago -- I thought you had misunderstood because it seemed that you believed enabling crossfading would cut the available CPU by 50% for the whole preset. (That would only be true if I were asking crossfading to be turned on for all blocks, all the time...which is not what I'm asking for...which is why I thought you misunderstood the request, at the time.)

chris said:
Can you link to this occasion?
Click to expand...
I found the occasion I was talking about...

...and, well, crap. :(

I sincerely apologize, Chris. I mis-remembered how that conversation went. :oops:

It's wasn't, really, that you misunderstood what I had asked for, on that occasion.

It was, rather, that you believed that in order to have what I was asking for, one had to reserve a huge bulk of CPU %. And I disagreed (and still disagree) with that.

These were the bits I was remembering:
https://forum.fractalaudio.com/threads/crossfading-channel-changes-in-a-block.136473/#post-1616768
...make the CPU limit only 50%.... Either a lower CPU limit, or each block would take up double the CPU it currently does. The CPU needs to be reserved ahead of time.
Click to expand...

and, later,
https://forum.fractalaudio.com/threads/crossfading-channel-changes-in-a-block.136473/#post-1616918
the 50% was a separate example, just pulled a random number. i didn't imply that using 2 amp blocks uses 50% cpu. i was saying is that if multiple blocks are going to crossfade, you'd need to reserve CPU, and maybe 50% is a good hypothetical.
Click to expand...

Now, I still dispute that statement. (The statement that, "you'd need to reserve CPU, and maybe 50% is a good hypothetical.")

I still dispute it because (as you and I both know) "enabling crossfading channels on a block" basically just is "adding another block of the same type into the signal flow."

And just as you don't have to "reserve 50% of CPU" because someone might add Amp Block 2 onto a grid that already has Amp Block 1 on it, so, likewise, you don't have to "reserve" 50% of CPU because someone might "activate crossfading" on Amp Block 1. (Because, other than the ramp-up/ramp-down logic, they're basically the same thing.)

They either have the CPU available; or they don't, in both cases. And in both cases, if they have the CPU available, it works. If they don't, they get the usual "CPU Limit Exceeded" error, and the attempt fails.

BUT,
a dispute between you and me about what my request requires,
is not the same as you misunderstanding the request.

I apologize for mis-remembering that conversation.

Mea culpa, mea maxima culpa.
 
Last edited:
Well this thread got derailed... Mods, would you be able to split Dr. Dipwad (and associated repies) into their own thread?
 
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...

The unit doesn't seem to be doing that though... see my post above.

It seems the amp block is the one that mutes on a scene change.
 
@FractalAudio - since you seem to be slaying wishes like a mofo the last few days, how about this one?

Is it possible to limit this muting to happen only during channel changes on the amp block?

This never happened with X/Y changes on the Axe Fx II (aside from the Amp block)... Why does it need to happen with Channels?

Pretty please? :innocent::innocent:
 
FractalAudio said:
Implemented for next release.
Click to expand...
giphy.gif
 
@FractalAudio

Based on the following, would it be correct to say that what was implemented is the outputs will no longer mute during a scene change when blocks change channels? I ask because I have another issue related to the same thing.

"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."
 
Ummm so with 1.09 beta, it seems the output blocks always mute now during a scene change if any block changes channel :(

In 1.08, I could have synth drones and choose different channels without any gap in the synth blocks as I switched scenes, the only gap was in the amp block - now with 1.09 any channel change in any block mutes the output blocks.

My intention with the wish request, was to have a preset with synth drones, change the Chords for the synth drones per scene, but keep the amp in the same channel and not get any silence gap as I switched scenes.

Oh well.

You know what would be cool? If there was a per block setting for "channel change mute" option, that you could toggle on/off. That way if a user has settings that don't produce any intolerable artifacts for them, they can leave it off. The synth block for example didn't produce any artifacts in 1.08 as you switched channels, so they didn't need a silence gap.
 
Last edited:
Perhaps just certain blocks can have an exception? Without the gap, there is noise from sudden changes in parameters, so the current implementation is better majority of the time. I’d rather have a mute than a loud pop any day.

Maybe the Synth block could somehow be exempt from the channel change mute rule? I’m not sure if any others could. But since the synth is a tone generator, maybe it won’t make noise when suddenly changing settings per channel?
 
I had started to write this thread before 1.09 came out but held off when I saw this Wish and wanted to see if it may be resolved first. Using the delay block in my example, the same issue occurred for me on 1.08.

I agree I don't want popping/clicking either. Not sure what the happy medium is. I also though too about if maybe for specific signal chains or more likely, the output used in a specific chain could have an option to say, ignore muting and let the end user deal with it. If pops/clicks exist, then that is on them.

Or finally, it seems you could change multiple channels on different blocks via MIDI and not have the muting occur as it just seems to do it when channels change via scenes. So maybe that is another option. But might be more programming on the controller side of things. Ie, instead of a scene change, a button sends several midi commands to enable/disable blocks and switch channels around and what not.
 
Chad Beattie said:
Or finally, it seems you could change multiple channels on different blocks via MIDI and not have the muting occur as it just seems to do it when channels change via scenes. So maybe that is another option. But might be more programming on the controller side of things. Ie, instead of a scene change, a button sends several midi commands to enable/disable blocks and switch channels around and what not.
Click to expand...

Oh interesting, that's indeed the case. If I change channels manually on the synth blocks they are seamless.

Chad Beattie said:
I also though too about if maybe for specific signal chains or more likely, the output used in a specific chain could have an option to say, ignore muting and let the end user deal with it. If pops/clicks exist, then that is on them.
Click to expand...

Yes! I had the same idea
 
You must log in or register to reply here.
Back
Top Bottom