Not a Bug 3.1 Tuner input mute also muting input 2

Poparad

Poparad

Power User
I've got a reverb pedal in the out2/in2 effects loop and now in FW 3.1 the tuner mutes the signal from Input 2 as well as Input 1, killing my reverb when I switch to tune. Regardless of whether input 1 or input 2 is selected as the source, they both get muted.
 
Last edited:
Poparad said:
I've got a reverb pedal in the out2/in2 effects loop and now in FW 3.1 the tuner mutes the signal from Input 2 as well as Input 1, killing my reverb when I switch to tune. Regardless of whether input 1 or input 2 is selected as the source, they both get muted.
Click to expand...
This is as designed and is not a bug.
 
That's a terrible design choice, IMO. It completely ruins the ability to run reverb and delay pedals in the effects loop because engaging the tuner kills it. Also, I was really excited to try the new "heel-down-tuner" option as it would free up one of my switches but if every time I bring my volume pedal down, it kills my reverb and makes it completely unusable.
 
BryantP said:
This is as designed and is not a bug.
Click to expand...

With all due respect, just because it’s working as designed doesn’t mean it isn’t a bug. If you have a reasonable explanation for why a user should expect it to work the way it does, that would mean it isn’t a bug.
 
Poparad said:
Also, I was really excited to try the new "heel-down-tuner" option as it would free up one of my switches but if every time I bring my volume pedal down, it kills my reverb and makes it completely unusable.
Click to expand...

If you're doing this there probably isn't a need to use a mute option in the tuner settings. I get what you're saying for switch-based tuner activation though; keeping ambient effects or something else audible through input 2 would be convenient as an option at least.
 
GlennO said:
With all due respect, just because it’s working as designed doesn’t mean it isn’t a bug. If you have a reasonable explanation for why a user should expect it to work the way it does, that would mean it isn’t a bug.
Click to expand...
Merriam Webster says:

an unexpected defect, fault, flaw, or imperfection
Click to expand...

I guess that leaves it open as to whom the "unexpected" part is relative to. ;)

IMO, if it is operating as the designer intended, regardless of what the user is expecting, it is not a bug but a wrong user expectation.

But, maybe that's just me :)
 
It's just you :). It's not the developer's intention that matters, it's the user's expectation. Usually there's a reason behind the intention, so marking the report as "not a bug" is simply a matter of sharing the explanation of the reasoning for the design decision. In other words, explaining why the user's expectation is wrong. Sometimes the explanation is convincing, sometimes not :). But if the developer is unable to provide any reasonable explanation at all, then it's a bug...regardless of the intention.

I suspect there is an explanation in this particular case, but it's bad form to simply close the report without providing the explanation. It tends to discourage people from reporting problems when their reports are dismissed without any rationale offered as to why.
 
You must log in or register to reply here.
Back
Top Bottom