Implemented Lock for the amp speaker impedance curve

Appreciate the patient back-and-forth on this topic. Not sure Cliff will, but I do! :tearsofjoy:

I definitely see some challenges in here. The fact that its a software environment and not a physical one gives me some hope that something even better than the current solution we have might be possible.
 
+1. Having a “Lock” button next to the impedance curve selector would be awesome.

Maybe a “Lock Channel” option so you can audition amps in one channel with a set curve without affecting amps in other channels. For instance, having a set 4x12 curve in channel A that doesn’t impact amps with 2x12 curves on channels B-D.

“Lock Preset” - Locks impedance curve for all amp channels within the preset. For instance, setting the impedance curve on channel A automatically switches the curve for amps on channels B-D.
This is a great idea and along the lines of what I was thinking/hoping for. It would be similar to that of an Ampete amp switcher going to the same cabinet for auditioning which would be a great quick way to hear other amps with the same cab and impedance curve. I think a global impedance curve would kind of be an unideal tradeoff. Then again, I don't program so I have no idea how that stuff works :tearsofjoy:
 
+1
My idea of this, a global speaker page with the impedance curve select, and the six user adjustable parameters LF freq, res Q, res and HF freq, res and slope. Impedance graph is not needed on such page.
But, nothing to complain, appreciate the progress and continued support of the AF
 
Last edited:
An "impedance curve lock" in the amp block per the OP is relatively easy, but a change to the design where the AMP reads the impedance data from another block somewhere in the grid (e.g. CAB) is hard because:
  1. It breaks the Axe grid signal processing design philosophy: Each block is self-contained, and signal processing flows left to right likely for "decoupled design" and CPU performance reasons (e.g. independent time invariant effects can be done in parallel or any order).

    For the AMP block to detect & read one or more impedance curves from the CAB block breaks this paradigm. It could require a large redesign of the overall behavior to allow such cross-block configuration while also detecting real-time which CAB blocks/channels are active, including if the CAB is anywhere downstream (or upstream?). Also what happens if there is no CAB block? Etc.
I can't comment on whether it's hard or not, but no, it does not break the signal processing philosophy. The signal would still flow as it does now, but the impedance information that is applied to that signal would be retrieved from a downstream cab block when the cab block is loaded into the grid, and only when editing/loading the cab block into the grid. After that, when processing the signal, the impedance curve data would be in the amp block where it is used.

I fully and completely understand the reason it works the way it does now. It's expedient to store the impedance data in the amp block. But the fact remains: it is conceptually a property of the cab block, not the the amp block. That suggests it should be stored/retrieved with the rest of the cab block data.

There are edge cases to consider, like an amp block feeding multiple cab blocks, but none of that changes the fact the impedance curve is a property of a speaker, not an amp. Consequently, ideally, it should follow your cab selection, not your amp selection.
 
I can't comment on whether it's hard or not, but no, it does not break the signal flow philosophy. The signal would still flow as it does now, but the impedance information that is applied to that signal would be retrieved from a downstream cab block when the cab block is loaded into the grid, and only when editing/loading the cab block into the grid. After that, when processing the signal, the impedance curve data would be in the amp block where it is used.

I fully and completely understand the reason it works the way it does now. It's expedient to store the impedance data in the amp block. But the fact remains: it is conceptually a property of the cab block, not the the amp block. That suggests it should be stored/retrieved with the rest of the cab block data.

There are edge cases to consider, like an amp block feeding multiple cab blocks, but none of that changes the fact the impedance curve is a property of a speaker, not an amp. Consequently, ideally, it should follow your cab selection, not your amp selection.
^^^ This.
 
This is a great idea and along the lines of what I was thinking/hoping for. It would be similar to that of an Ampete amp switcher going to the same cabinet for auditioning which would be a great quick way to hear other amps with the same cab and impedance curve. I think a global impedance curve would kind of be an unideal tradeoff. Then again, I don't program so I have no idea how that stuff works :tearsofjoy:
Ideally, it would be great if the impedance curve selection carried over when switching models kinda like how the Input Drive stays in the same spot when switching models. A user could click “Reset Block” if they wanted the default curve. Or maybe adding an “Impedance Curve Lock” switch in the Speaker tab so it locks it in place or changes to default curves if it’s “Unlocked.”
 
The signal would still flow as it does now, but the impedance information that is applied to that signal would be retrieved from a downstream cab block when the cab block is loaded into the grid, and only when editing/loading the cab block into the grid. After that, when processing the signal, the impedance curve data would be in the amp block where it is used.
Exactly what I was going to say. The time to apply the curve is during the creation of the layout.

But, this then causes a problem if someone is using additional channels in the cab block and switches them, perhaps mid-song. Would that cause an additional gap as the impedance curves were fetched and combined, or as the amp recomputes the sound? Or would the amp have all possible combinations precomputed?

We might have opened Pandora’s box now. And I think Cliff and the team are going to be covering the white boards with diagrams with this one.
 
Back
Top Bottom