Wish Crossfading Channel Changes in a Block

[Dr. Dipwad]

A Polite Note:
Please read this request carefully before responding,
as this request features some complex details which are already well-thought-out...

The Status Quo
In the Axe III, we already have the ability to put a Block into the Grid and associate different Channels in that block with different Scenes.

So, when you change Scenes, you hear that block automatically (and abruptly) change from one Channel to another.

That's good, but it's the 21st century now. We can do better.

The Requested Improvement
What I want is a setting which allows the Block to change Channels, but NOT abruptly. Instead, when this setting is turned on, the block could cross-fade from the old channel's sound to the new channel's sound, over some period of time (0-1000ms). As the sound of Channel A fades away, the sound of Channel B swells in.

That way the overall timbre of your instrument doesn't change abruptly, but musically morphs from one sound to another, when you change channels (including via Scene-change).

The Workflow
To use this feature, you would...
(a.) put the block (one that has channels) on to the grid;
(b.) in the block's settings, toggle it into "Crossfading Channels" mode;
(c.) set the "crossfade time" (which would be a linkable param).

Limitations (required for simultaneous processing)
Since crossfading requires the computing power of 2 blocks of the same type executing simultaneously (at least during the crossfade), as soon as you set one block to "Crossfading Channels" mode, another block of that same type would cease to be available in your inventory.

For example, there are only 2 Amp blocks in inventory in the Axe III. So if you put Amp Block 1 on the grid and switched it to "Crossfading Channels" mode, the other (Amp Block 2) would no longer be available to be placed on the grid. (Its processing-power would have been "harnessed into" Amp Block 1 when you set Amp Block 1 to "Crossfading Channels" mode.)

That means that you can only have one Amp Block per preset if that Amp Block is set to crossfade. But, for a block-type like Drive, which has FOUR in inventory, you could get 2 crossfaders in the same preset (or, 1 crossfading drive plus two standard drives).

An Anticipated Objection
When I ask for this, the first response is usually, "But you can already set up a preset to have crossfading in it; how is this new?"

Well, as discussed elsewhere, it is theoretically possible, with a lot of MIDI trickery, to put 2 Amp blocks on your grid and then set up a footswitch and a MIDI processor which, when you hit a Scene Change on your footcontroller, would...

• switch Amp Block 2 to the same channel (with the same settings) as Amp Block 1
• switch you instantly from Amp Block 1 to Amp Block 2 (which sounds identical, so you hear no change)
• switch Amp Block 1 to the new desired channel (e.g. from A to B)
• crossfade you back from Amp Block 2 to Amp Block 1 (over 500ms, perhaps) so that you hear the sound crossfade smoothly

...but while this is theoretically possible, it's a nightmare trying to program even one preset to do this, and requires an outboard MIDI processor smart enough to "hear" your Scene Change CC command and convert it into a stream of commands performing the channel-switching and the crossfading. No fun!

But if Fractal adds this capability (as described above) into the firmware, then "turning on" crossfading channel-changes in a block becomes so much easier. Fractal will have removed the (currently very high) workflow obstacles that prevent most users from trying this out.

Yes, People Will Like It And Use It
When it becomes that simple to try it out, I expect many users to try it and love it.
(And every other company will wish that their processor had enough CPU-power to do it.)

After all, smooth crossfades are a more-musical sounding way to change the timbre of your instrument than an abrupt change.

(If they weren't, DJs wouldn't crossfade between tracks, would they?)

 

[yek]

The wiki provides examples of how to crossfade.

Channels can’t because by design they simply do not and can not run simultaneously.

 

[Dr. Dipwad]

Yek,

The wiki provides examples of how to crossfade.

Channels can’t because by design they simply do not and can not run simultaneously.

Thanks for all you do here, man; I'm a fan!

On this particular occasion, however, I think you've missed the point of my "WISH."

What I'm asking for is the ability to sacrifice an extra block-instance from the inventory in order to obtain the ability to channel-switch by crossfading.

I fully expect to have to sacrifice Amp Block 2 in order to obtain the ability to crossfade-channel-switch in Amp Block 1.

I expect that, because of course what's really happening is that Amp Block 2 is being "slaved" to Amp Block 1 in order to give the ability to run two channels simultaneously.

(Re-read my original post, and you'll see that I stated this. Likewise, if you wanted crossfading channels on Drive 1, the total number of Drive Blocks in your inventory would drop from 4 to 3, because the "missing" one was being used to make crossfading possible in Drive 1.)

BTW, when I say "I think you've missed the point...," I'm definitely not trying to be rude.
(Like I said, I totally appreciate all you do in this forum!)

But, when you reply that, "Channels can’t because by design they simply do not and can not run simultaneously...," you're overlooking the fact that I already anticipated that objection, and a workaround for that problem is built in to my original request.

Likewise, when you reply that, "The wiki provides examples of how to crossfade...," trust me, I do already know that! I've been doing lots of crossfading for years, you see. My current rig consists of 2 Axe FX II's plugged in to one anothers' FX loops, purely in order to be able to crossfade-channel-change 4 Amp/Cab combinations in every preset.

But boy, oh boy! is that a lot of work. It requires 2 units. In order to back up my presets I have to plug in one unit, then the other, and back them up separately. And it's hard to think clearly about a signal path that goes into Axe #1, then splits, then one side goes out of Axe #1 and into Axe #2 while the other side goes into 2 different Amp/Cab combinations inside Axe#1, and the side that went into Axe #2 also splits into 2 different Amp/Cab combinations, and then recombines, and goes out the Axe #2 loop-send into the loop-return of Axe #1, et cetera, et cetera, ad nauseam.

But the end result is wonderfully smooth and musical sounding. That makes it worth it...but I'm always wishing there were an easier way.

The "WISH" I am proposing in this thread would be that "easier way."

 

[yek]

My bad, I didn’t read it thoroughly enough.

 

[Dr. Dipwad]

My bad, I didn’t read it thoroughly enough.

No problem!

I realize that it takes a lot of reading to process exactly what I'm asking for.

And, like the meme says, "Ain't nobody got time for that!"

Thanks for taking a second look.

(I've also gone back and edited the original post to try to make it more-organized and easier to read.)

 

[chris]

I like the idea, but consider that it’s not “removing Amp2 from inventory” that would give the needed CPU. It would be something more like “make the CPU limit only 50%.”

Hypothetically speaking, I could make a 90% CPU preset with only Block 1 of everything. Then if I want the cross fading as you described, I probably couldn’t do it since there is only 10% cpu left that’s reserved to run the unit itself.

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. That’s why bypassed blocks don’t release CPU, as you know.

Again, I love the idea. Crossfading is great for sure. But I think the proposed method may not work. This is a great springboard for the idea though.

 

[54321pj]

I like the idea, I have thought about this also, and have requested it in the wish list for the II.
I currently have a similar issue when running presets which have both an acoustic line and distortion line running in the same preset (using same guitar and same pickup) which are switched with scenes... You get that huge "Whack" spike of noise as the lines are switched in and out of the signal chain. I thought along the lines of being at least able to set a time limit into the input of a given block which gradually releases the signal. At least you can get away with this when playing live because you can anticipate what is going to happen when switching that particular scene. Or have a dedicated block like the mixer, but one which allows you to set an Auto fade in/out time limit.

 

[chris]

I like the idea, I have thought about this also, and have requested it in the wish list for the II.
I currently have a similar issue when running presets which have both an acoustic line and distortion line running in the same preset (using same guitar and same pickup) which are switched with scenes... You get that huge "Whack" spike of noise as the lines are switched in and out of the signal chain. I thought along the lines of being at least able to set a time limit into the input of a given block which gradually releases the signal. At least you can get away with this when playing live because you can anticipate what is going to happen when switching that particular scene. Or have a dedicated block like the mixer, but one which allows you to set an Auto fade in/out time limit.

you might benefit from others looking at your preset. i also do acoustic and electric in a preset, but i don't get a whack of noise when changing scenes. that's usually from something specific and can usually be remedied.

 

[Dr. Dipwad]

Hi, Chris!

I like the idea, but consider that it’s not “removing Amp2 from inventory” that would give the needed CPU. It would be something more like “make the CPU limit only 50%.”

Hypothetically speaking, I could make a 90% CPU preset with only Block 1 of everything. Then if I want the cross fading as you described, I probably couldn’t do it since there is only 10% cpu left that’s reserved to run the unit itself.

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. That’s why bypassed blocks don’t release CPU, as you know.

Again, I love the idea. Crossfading is great for sure. But I think the proposed method may not work. This is a great springboard for the idea though.

Hmm. I see where you're going with this, and I grant that you're highlighting something I mostly neglected in my original description.

But it also seems to me that you're overstating the case a little bit, when you suggest that doubling the usage of one amp block would result in available CPU dropping down to only 50%.

Here's what I mean (and if I'm wrong, I trust you'll help me understand in what way):

IF...
a single Amp Block, with nothing else on the grid, used 25% of the Axe III's CPU power (with 75% free)...,

THEN...
making an Amp Block process 2 signals at once by putting it into "Crossfading Channels" mode would, of course, double the amount of CPU the block was using (from 25% to 50%), causing available CPU to drop from 75% free to 50% free.

That would match your scenario...but are those numbers even remotely realistic? Does one Amp Block use up 25% of the processor?

"Wait, wait," I hear you saying, "You forgot about system overhead."

OK, that's true. So let's correct that: I'm not sure how much CPU is eaten up by everything other than what's on the grid, but I'm going to guess it's around 10% with peaks of up to 15%. Conservatively, we'll call it 15%.

So let's start again:

IF...
a single Amp Block, with nothing else on the grid, used 17.5% of the Axe III's CPU power (plus an additional 15% for non-block-usage), so that the system and the single Amp Block uses 32.5%, leaving us with a total of 67.5% free...,

THEN...
making an Amp Block process 2 signals at once by putting it into "Crossfading Channels" mode would, of course, double the amount of CPU the block was using (from 17.5% to 35%), causing available CPU to drop from 67.5% free to 50% free.

That's the scenario you were painting, isn't it? That doubling the CPU usage of an Amp Block would reduce available CPU down to 50%?

Well, then, I ask you: Is it true that a single (non-crossfading-channels) Amp Block in the Axe III uses 17.5% of the Axe III's total CPU power?

I don't have an Axe III yet (I didn't get on the list until Feb 6th or thereabouts ) so I can't test this premise.

But 17.5% sounds a bit high, to me.

And...you do have an Axe III, right? You could test it, couldn't you?

D'ya mind letting me know how much a single Amp Block uses? (I expect it varies from model-to-model but you can estimate) ...and then we can double that to estimate the peak usage of a crossfading-version of the same block.

 

[chris]

Hi, Chris!



Hmm. I see where you're going with this, and I grant that you're highlighting something I mostly neglected in my original description.

But it also seems to me that you're overstating the case a little bit, when you suggest that doubling the usage of one amp block would result in available CPU dropping down to only 50%.

Here's what I mean (and if I'm wrong, I trust you'll help me understand in what way):

IF...
a single Amp Block, with nothing else on the grid, used 25% of the Axe III's CPU power (with 75% free)...,

THEN...
making an Amp Block process 2 signals at once by putting it into "Crossfading Channels" mode would, of course, double the amount of CPU the block was using (from 25% to 50%), causing available CPU to drop from 75% free to 50% free.

That would match your scenario...but are those numbers even remotely realistic? Does one Amp Block use up 25% of the processor?

"Wait, wait," I hear you saying, "You forgot about system overhead."

OK, that's true. So let's correct that: I'm not sure how much CPU is eaten up by everything other than what's on the grid, but I'm going to guess it's around 10% with peaks of up to 15%. Conservatively, we'll call it 15%.

So let's start again:

IF...
a single Amp Block, with nothing else on the grid, used 17.5% of the Axe III's CPU power (plus an additional 15% for non-block-usage), so that the system and the single Amp Block uses 32.5%, leaving us with a total of 67.5% free...,

THEN...
making an Amp Block process 2 signals at once by putting it into "Crossfading Channels" mode would, of course, double the amount of CPU the block was using (from 17.5% to 35%), causing available CPU to drop from 67.5% free to 50% free.

That's the scenario you were painting, isn't it? That doubling the CPU usage of an Amp Block would reduce available CPU down to 50%?

Well, then, I ask you: Is it true that a single (non-crossfading-channels) Amp Block in the Axe III uses 17.5% of the Axe III's total CPU power?

I don't have an Axe III yet (I didn't get on the list until Feb 6th or thereabouts ) so I can't test this premise.

But 17.5% sounds a bit high, to me.

And...you do have an Axe III, right? You could test it, couldn't you?

D'ya mind letting me know how much a single Amp Block uses? (I expect it varies from model-to-model but you can estimate) ...and then we can double that to estimate the peak usage of a crossfading-version of the same block.

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.

the main point is that simply "removing Amp2/Delay3/Drive4" etc. isn't what would give more CPU. you'd need to somehow reserve the CPU for crossfading EITHER by limiting the CPU to 50% usage as you add blocks, OR making each block use double their CPU (from doubling the block instances which allow the crossfade).

somehow it has to be reserved so you don't make that 90% preset with only Instance 1 of all blocks, and then when you try to crossfade, you get a CPU error. removing Amp 2 from the inventory and potential blocks to be added is not what reserves CPU.

 

[Dr. Dipwad]

Chris:

...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.

somehow it has to be reserved so you don't make that 90% preset with only Instance 1 of all blocks, and then when you try to crossfade, you get a CPU error. removing Amp 2 from the inventory and potential blocks to be added is not what reserves CPU.

Okay, I think I get what you're saying.

If you look at the original post, you'll see I described the workflow this way:

(a.) put the block (one that has channels) on to the grid;
(b.) in the block's settings, toggle it into "Crossfading Channels" mode;
(c.) set the "crossfade time" (which would be a linkable param).

I'll now expand on that a bit, by spelling out 3 scenarios.

(Note: In the following 3 scenarios, I will use 11% as a convenient number to represent how much CPU a Drive Block uses. I have no idea whether that's realistic or not, but that's beside the point: It's just a hypothetical number which helps clarify the description of each scenario.)

. . .

SCENARIO #1: Adding a Drive Block to a Preset when CPU is sufficient for it to run in crossfading-channels mode:

(a.) Starting Point:
- There are no Drive Blocks currently in the grid.
- There are 4 Drive Blocks remaining in inventory.
- The % free CPU is 30%, which is enough for 2 Drive Blocks (at 11% each) to be added to the grid, with 8% left over.

(b.) The user puts a Drive Block on to the grid. (The Inventory of Drive Blocks drops to 3, and the % free CPU drops to 19%.)

(c.) The user hits "Edit" to enter the Block's settings, and toggles it into "Crossfading Channels" mode. As soon as he does this, the number of available Drive Blocks in inventory drops to 2 (because one is invisibly placed on the grid and linked to the first one, making crossfading possible for the first one). Also, because there are now 2 Drive Blocks active in the grid (one "master" and one "slave"), the CPU drops by an additional 11%, from 19% down to 8%.

(d.) The user sets the "crossfade time" (which would be a linkable param).


SCENARIO #2: Adding a Drive Block to a Preset when CPU is NOT sufficient for it to run in crossfading-channels mode:

(a.) Starting Point:
- There are no Drive Blocks currently in the grid.
- There are 4 Drive Blocks remaining in inventory.
- The % free CPU is 20%, which is enough for 1 Drive Block (at 11% each) to be added to the grid, but not 2.

(b.) The user puts a Drive Block on to the grid. (The Inventory of Drive Blocks drops to 3, and the % free CPU drops to 9%.)

(c.) The user hits "Edit" to enter the Block's settings, and tries to toggle it into "Crossfading Channels" mode, but this fails because of insufficient CPU. The user sees the same "Insufficient CPU" message that he would have seen if he'd tried to add a separate Drive Block onto the grid. (Because, in a sense, that is what he just tried to do.)


SCENARIO #3: Adding a Drive Block to a Preset when CPU is sufficient for it to run in crossfading-channels mode, but the Drive Blocks inventory is NOT sufficient:

(a.) Starting Point:
- There are 3 Drive Blocks currently on the grid.
- There is 1 Drive Block remaining in inventory.
- The % free CPU is 30%, which is enough for 2 Drive Blocks (at 11% each) to be added to the grid, with 8% left over, but, again, there aren't actually that many available in inventory.

(b.) The user puts a Drive Block on to the grid. (The Inventory of Drive Blocks drops to 0, and the % free CPU drops to 19%.)

(c.) The user hits "Edit" to enter the Block's settings, and tries to toggle it into "Crossfading Channels" mode, but this fails because the option to toggle it into "Crossfading Channels" mode is greyed out (disabled). This is because turning on "Crossfading Channels" mode for a block requires both that another identical block's worth of CPU is available, and that another identical block is still in Inventory. In this case the CPU is available but the Inventory isn't. If the user tries to put the cursor on the "Crossfading Channels" option, a message appears saying, "Insufficient Inventory for Crossfading Channels Option."

. . .

Chris, it seems to me that those 3 use-cases adequately cover the need to have CPU and Inventory reserved.

I don't think that there's any reason that the whole preset has to start at 50% to reserve enough CPU just in case the user decides to turn on crossfading in one of his blocks. It isn't necessary for the same reason that we don't currently need to start at 50% to reserve enough CPU just in case the user adds 2 blocks to the grid instead of 1.

Indeed, in cases where there isn't enough CPU available to handle crossfading, the Axe III could show the user the same error message that a user sees when he tried to add more blocks to the grid than his free CPU % can handle.

 

[Dr. Dipwad]

UPDATE:
The discussion about how it would work thus far has helped me to grasp the request a little better.

Here's how I see it, currently:

The act of turning on "crossfading channel-changes" in a block is really just a UI shortcut for...
1. Put another block invisibly on the grid (which we'll call Block 2) which is identical to the original (called Block 1).
2. Populate Block 2 with the same channel-settings as Block 1 and keep their respective settings always in synch. (I guess you'd do this by only storing the settings in memory in one place. Each block's "settings" would be memory pointers/references to the location in memory where the channel-settings for both are stored).
3. Set Block 2 to have the same input signal sources as Block 1, and to send its output signal to the same destinations as Block 1; and,
4. Add the channel-switch-crossfading logic to the output levels of both blocks.

The channel-switch-crossfading logic works as follows:
(a.) Initially, Block 1 is active and Block 2 is disabled (muted not bypassed);
(b.) When user sends a command to change from channel A to channel B, then Block 2 immediately enables and changes to channel B.
(c.) The output level of Block 1 ramps down as the output level of Block 2 ramps up.
(d.) When the ramping completes, Block 1 is at 0% and Block 2 is at 100%.
(e.) Once the crossfade is complete, Block 1 automatically disables.
(f.) The next time a channel-change command comes through (e.g. from B to C), the same pattern is followed, but this time it is Block 1 that immediately re-enables and switches to the desired channel (C), and Block 2's output begins ramping down towards 0% while Block 1's output ramps up to 100%. When the ramping is complete, Block 2 disables.

NOTE re: CPU concerns:
I don't think the system described above would require any more CPU drain than merely putting another block-instance of the same block onto the grid would.

One might counter-argue that "Adding the crossfading behavior makes one block w/crossfading channels require more CPU than two blocks."

That's true, but how much more? Not much at all. No more than would be required to, say, hook the two blocks' outputs simultaneously a Continuous Controller value, with 1000ms of damping, and the first block's values running 0-to-127, but the other block's values running 127-to-0. Because that's basically what you're doing.

Notice, also, that CPU burden is reduced in other ways (compared against two instances of the same block on the same grid):

• For 2 drive blocks, you have to keep 8 channels' worth of settings in memory. But for one drive block with Crossfading Channel-Changes turned on, you only have to keep 4 channels' worth of settings in memory, since the second block's channel settings are supposed to always be identical with the first.
• Most of the time, one of the two blocks is disabled; both are only active during the crossfade time.

So, it doesn't seem that request imposes an unreasonable CPU burden.

 

[Moke]

First of all, let me commend you on a well thought out and thorough wish. But the fact that all of this is already possible with currently available blocks and controllers makes me doubt that it will be implemented?

Just a thought.... Cliff had mentioned that it would be possible to be able to use more than 2 amp blocks at a time at a reduced sampling rate, but would likely cause some aliasing. Maybe it would be possible to briefly lower the sampling rate and allow 2 channels of the current amp block to run at the same time only during the cross fade? Maybe any aliasing going on during the cross fade would not be noticeable?

 

[Dr. Dipwad]

Moke:

First of all, let me commend you on a well thought out and thorough wish. But the fact that all of this is already possible with currently available blocks and controllers makes me doubt that it will be implemented?

Thanks for your kind commendation.

But, one point I was trying to make is: it isn't fully possible with currently available blocks and controllers. Only a rough approximation is possible, currently: Something that's significantly inferior to what I'm asking for.

If the Crossfading-Channel-Changes feature I've asked for were implemented, then a person could have his Amp sound crossfade from channel to channel in response to Scene Changes, and could use all four channels that way: A, B, C, and D.

Without that feature, what's the closest you could get?

Well, you'd put 2 amp blocks in the preset. And...and then what?

Presumably you'd use Scene controllers and set the Output level of Amp Block 1 to be 100% in Scene 1 and 0% in Scene 2. Then you'd set the Output level of Amp Block 2 to be 0% in Scene 1 and 100% in Scene 2.

Okay, that's kind of close. But remember: We were trying to make use of the new Axe-FX III feature of CHANNELS: We want a Channel A, a Channel B, a Channel C, and a Channel D.

How can crossfading between two Amp blocks give you that?

It can't. What it basically gives you is crossfading between 2 channels: One provided by Amp Block 1, and the other by Amp Block 2. That's it. You must keep them permanently on Channel A. If you try to incorporate B, C, or D, you will get abrupt changes again.

So I don't think that's really the same thing.

Just a thought.... Cliff had mentioned that it would be possible to be able to use more than 2 amp blocks at a time at a reduced sampling rate, but would likely cause some aliasing. Maybe it would be possible to briefly lower the sampling rate and allow 2 channels of the current amp block to run at the same time only during the cross fade? Maybe any aliasing going on during the cross fade would not be noticeable?

Now THAT is a good thought!

I'm not sure how well it would work, or whether the quality difference would be noticeable.

If a person could audibly hear the difference between the high-quality tone and the lower-quality tone, it wouldn't work.

But there might be a compromise: When changing from Channel A to Channel B, one could perhaps keep Channel A on "high-quality mode" while it was ramping down from 100% to 50%, but then switch it to "low-quality mode" for the trip from 49% to 0%.

Meanwhile, you could put Channel B on "low-quality mode" as it was ramping upward, from 0% to 49%, and then switch it to high-quality mode once it reached 50%.

That way whichever of the two tones was loudest would always be in high-quality mode. That would probably be sufficient to mask the quality-drop.

 

[Moke]

Moke:



Thanks for your kind commendation.

But, one point I was trying to make is: it isn't fully possible with currently available blocks and controllers. Only a rough approximation is possible, currently: Something that's significantly inferior to what I'm asking for.

If the Crossfading-Channel-Changes feature I've asked for were implemented, then a person could have his Amp sound crossfade from channel to channel in response to Scene Changes, and could use all four channels that way: A, B, C, and D.

Without that feature, what's the closest you could get?

Well, you'd put 2 amp blocks in the preset. And...and then what?

Presumably you'd use Scene controllers and set the Output level of Amp Block 1 to be 100% in Scene 1 and 0% in Scene 2. Then you'd set the Output level of Amp Block 2 to be 0% in Scene 1 and 100% in Scene 2.

Okay, that's kind of close. But remember: We were trying to make use of the new Axe-FX III feature of CHANNELS: We want a Channel A, a Channel B, a Channel C, and a Channel D.

How can crossfading between two Amp blocks give you that?

It can't. What it basically gives you is crossfading between 2 channels: One provided by Amp Block 1, and the other by Amp Block 2. That's it. You must keep them permanently on Channel A. If you try to incorporate B, C, or D, you will get abrupt changes again.

So I don't think that's really the same thing.



Now THAT is a good thought!

I'm not sure how well it would work, or whether the quality difference would be noticeable.

If a person could audibly hear the difference between the high-quality tone and the lower-quality tone, it wouldn't work.

But there might be a compromise: When changing from Channel A to Channel B, one could perhaps keep Channel A on "high-quality mode" while it was ramping down from 100% to 50%, but then switch it to "low-quality mode" for the trip from 49% to 0%.

Meanwhile, you could put Channel B on "low-quality mode" as it was ramping upward, from 0% to 49%, and then switch it to high-quality mode once it reached 50%.

That way whichever of the two tones was loudest would always be in high-quality mode. That would probably be sufficient to mask the quality-drop.

Don't get me wrong, I like the idea and would love to see that happen as an option. One amp block with 4 completely seamless, cross fading/morphing amp models without any extra set up sounds good to me.

 

[DLC86]

You must keep them permanently on Channel A. If you try to incorporate B, C, or D, you will get abrupt changes again.

I don't think that's completely true. If you change channel in the amp that is currently muted you'll probably won't hear any abrupt change.

Let me explain better.
Let's say you are in scene 1 where both amps are on channel A and the volume is 100% for amp1 and 0% for amp2.
Then you switch to scene 2 where amp2 switches to channel B (this switch takes 25ms if I remember correctly) and you had set a crossfading time of 1000ms. The B channel of amp2 will be up and running when its level reaches 2,5% and amp1 level will be at 97,5%.
Do you think you'll be able to hear any abrupt change in this scenario?

 

[Dr. Dipwad]

DLC86:

I don't think that's completely true. If you change channel in the amp that is currently muted you'll probably won't hear any abrupt change.

Let me explain better.
Let's say you are in scene 1 where both amps are on channel A and the volume is 100% for amp1 and 0% for amp2.
Then you switch to scene 2 where amp2 switches to channel B (this switch takes 25ms if I remember correctly) and you had set a crossfading time of 1000ms. The B channel of amp2 will be up and running when its level reaches 2,5% and amp1 level will be at 97,5%.
Do you think you'll be able to hear any abrupt change in this scenario?

Thanks for replying! I get what you're saying.

In fact, I tried that idea out, back when I first started playing around with crossfading in the Axe FX II. (The Axe FX II didn't have "channels," but it had X and Y states, which were similar.)

I tried it. But I'm afraid it doesn't fully solve the problem.

It works great, for one channel-change.

The problem arises after that, however. The system you describe will not be able to handle ALL the channel-changes in a song without abrupt, audible changes resulting.


A REAL WORLD EXAMPLE
Here's an example to illustrate the problem:

Let's say your four channels are:
Channel A - Clean
Channel B - A Little Grit
Channel C - Crunch Rhythm
Channel D - Lead

And, let's say your song form is:
Intro - Verse 1 - Pre-Chorus1 - Chorus1 - Verse 2 - Pre-Chorus2 - Chorus2 - Instrumental - Chorus3 - Outro

And you need to apply your channels to those song sections as follows:
Intro (C) - V1 (A) - PreCh1 (B) - Ch (C) - V2 (A) - PreCh1 (B) - Ch2 (C) - Inst (D) - Ch3 (C and D) - Outro (C)

^^^ Note that all of this is very plausible, a commonplace pattern. It's the standard pop-song roadmap, practically a cliché. The "C and D" channels in the final chorus indicate that you're playing your chorus in Crunch Rhythm sound, like before, but putting in little bursts of lead licks between the vocal lines. Again: A very normal thing to do. Any "working" solution needs to be able to handle all these changes easily.

Now, your proposal is to put some channels (A and C, perhaps) on one Amp Block, and the others (B and D) on the other Amp Block, and set your Scene Controller to turn up Amp Block 1 to 100% when you want to be on A and C, and down to 0% for B and D; and to have Amp Block 2 at 100% when you're on B and D, and down at 0% when you're on A and C.

That way, when you change from A to B, and simultaneously start crossfading from Amp Block 1 to Amp Block 2, it'll sound smooth. Right? That's your proposal, correct?

Well, it'll work for a transition from A to B. It'll work fine for that.

But our first transition is C to A. Oops.

I think you see where I'm going with this.


WHERE IT ALL BREAKS DOWN
If both A and C are on the same Amp Block (Amp Block 1 in this case), then you'll get an abrupt change going from the Intro to the Verse. (But you'll do fine when you go from the Verse to the Pre-Chorus, because A and B are on different Amp Blocks.)

On the other hand, if you put A and B on the same Amp Block, and C and D on the other, then your transition from Intro to Verse will be smooth. (But the transition from Verse to Pre-Chorus will be abrupt.)

So, there's no way you can arrange your channels across the Amp Blocks that'll guarantee they always crossfade smoothly. The only way that this set-up would reliably produce smooth transitions is if your songs are written in such a way that they always go from Channel A to only B or D, never C; and from Channel B to only A or C, never D; and from Channel C to only B or D, never A; and from Channel D to only A or C, never B.

Sadly, there's no way to guarantee that.

But...!

It is true that, using your proposed setup, you managed to get the first channel-change to be a smooth crossfade. So that's a partial success.

The question, then, is: Can we adjust this, or learn from it, to come up with a system that fully achieves crossfading across all channel-changes?

We can.

Here's what we need...


A MORE-COMPLETE SOLUTION
(That keeps working after the first channel-change)
We need 2 amp blocks, of course.
Amp Block 1 - this is what you're hearing most of the time
Amp Block 2 - this is what you're hearing during crossfades

...and both of them have exactly the same settings for Channels A, B, C, and D.

You start off playing Channel A of Amp Block 1, which is at Output Level 100%. Meanwhile, Amp Block 2 (which is ALSO set to Channel A) is currently at 0% Output Level.

Then, when you're ready to change channels (in this example, we'll say you're changing to "B" but it doesn't matter which), you need to do the following steps:

1. Send a channel-change command to Amp Block 2, telling it to INSTANTLY switch to B.
2. Make the Output Level of Amp Block 1 start dropping towards 0% while the Output Level of Amp Block 2 starts rising towards 100%. (You are now hearing the crossfade from Channel A to Channel B.)
3. AFTER Amp Block 1 reaches 0%, immediately change it to Channel B.
4. After Amp Block 1 is on the same channel as Amp Block 2, return its level to 100% while dropping Amp Block 2's level back to 0%.

If you follow those steps every time you make a channel change, then it will always work:

• You always start with both Amp Blocks set to the same channel, with Amp Block 1 at 100% and Amp Block 2 at 0%.
• You always end with both Amp Blocks set to the same channel, with Amp Block 1 at 100% and Amp Block 2 at 0%.
• The only time you hear Amp Block 2 is during the crossfade.

The fact that you start in the same condition that you end is critical: It means you're set up and ready for the next channel-change.

BUT, there's a problem, and it has to do with the word "AFTER" in Step 3, above. That word "AFTER" implies that the system knows that it needs to wait until Step 2 is complete before it starts Step 3.

Just how, exactly, are you going to delay that channel-change command? How do you make it wait?

( . . . crickets . . . )


WHY A FIRMWARE FEATURE IS NEEDED
It's critical that you wait until the crossfading-time is completed before you do the last 2 steps. If your crossfade time is 500ms, you need Step 3 to happen at 501ms and Step 4 sometime around 550ms (so that you don't start hearing Amp Block 1 while it's still channel-switching).

How can you orchestrate the timing of that? And how can you easily change it if you want a 200ms crossfade for one of your presets, a 500ms crossfade for the next, and a 1000ms crossfade for the third?

Sadly, none of that's possible unless you purchase some complex, programmable MIDI Processor which can be programmed to "hear" the Channel Change command come across the MIDI wire, and "responds" by waiting for the correct number of milliseconds and then sending a second command.

So, it can't be done.

Or rather: It can be done, but nobody will, because it's way too much hassle. (Requires extra hardware, probably takes a half-hour of painstaking setup of the relevant Scene Controllers and External Control links, and so on.)

That's why it really requires a new option be added to the firmware.

 

[Bakerman]

This would probably work with a capable enough MIDI controller:

Start with Amp 1 active and have four channel switches configured. Press any one of those and it sends value 0, 1, 2 or 3 for Amp 2 Channel CC#, plus value 127 for an Ext Ctrl that makes a mixer block fade from Amp 1 to Amp 2. The mixer modifiers would use damping and small dead zones at each edge so the fade doesn't begin until amp 2 is ready.

The next press of any switch in the group should send value 0, 1, 2 or 3 for Amp 1 Channel CC# instead, and 0 for the Ext Ctrl.

Many controllers could do this with 8 switches as two groups of 4 if you alternate between groups with each press. Reducing that to one group of four would require some way to toggle between CC#s and Ext Ctrl values with any press of a switch in the group.

I think an MC6 could at least do this:

Bank 1: Each switch sends Amp 2 Channel value n, Ext Ctrl value 127, bank up on release

Bank 2: Each switch sends Amp 1 Channel value n, Ext Ctrl value 0, bank down on release

 

[DLC86]

EDIT: Deleted because what I wrote was wrong as @Bakerman made me realize

 

[Bakerman]

The problem with switching scenes is that every block will immediately switch to a particular channel, assuming this works like XY on the II.

For example you can't just pick scene 7 and keep amp 1 on whatever channel it was on in scene 1, 2, 3 or 4. If it's on channel A in scene 7, you could only fade seamlessly from scene 1.

For MIDI-based switching without changing scenes, the method I described in #18 is probably the easiest solution. You could add commands for additional effect switching without changing scenes.

If channel selection could have a modifier (preventing scene changes from affecting channel) you could use MIDI channel selection along with actual scene changes.