HeHasTheJazzHands
Well-Known Member
Well damn, good thing you ended up doing this video and being right in the end lol. Also props to Fender for realizing the error and trying to fix it
Well damn, good thing you ended up doing this video and being right in the end lol. Also props to Fender for realizing the error and trying to fix it
This site may earn a commission from merchant links like Ebay, Amazon, and others.
It actually makes sense from a business POV.Fender flubbed the most used amp model, and it's their own amp. Way to go.
Alternatively, I'd rather see "two minute drills" for this stuff. @Guitarjon gets the amp tone, then gets a short period of time with each modeler to get them close. To me this is a better indicator or real-world use and the usability of a device. You can turn a real amp into a different thing all-together if you have the time to change parts values, swap tubes, etc. But most people are going to plug in, turn a few knobs, and decide if it sounds like what they want or not and either get it or move on. One of the big complaints I see for HX modeling (never a problem I've had personally) is that you have do a lot of tweaking to get good sounds. Part of the appeal of the GUI is speed of function. If you gotta go figure out what the impedance curve is and add a parametric EQ just to get close, seems like it might be the modeling.
You might think a bug is "an error caused by improper programming", but according to my experience as a dev it is "anything the customer or an executive doesn't like, even if intentional and you have a JIRA ticket to back that up". This seems to be a case of the latter to me.I wonder what constitutes a bug in one of their models...
Wow, good thing I looked at the data and knew the impedance was fucked.Well damn, good thing you ended up doing this video and being right in the end lol. Also props to Fender for realizing the error and trying to fix it
This has been my main question regarding digital stuff for a long time. For me, I don't give two shits what gear someone else uses, how accurate a model is, if it even has a real world counterpart, how the controls behave compared to hardware, etc. I just want it to sound good and get out of my way creatively. I feel the same way about ITB mixing. I don't care how close something sounds to a hardware compressor or transformer saturation or what controls are there. Does it sound good? Does it improve my workflow? Sweet, it's a good tool. I see a lot of engineers crapping on stuff like Soothe or Smooth Operator because "the plugin does all the work". Who cares? Implementation of a tool is more important than how long it took someone to use it.The real question is if we're in a digital world, and people don't want to dive into many of these settings, then why do we still present an interface that features controls and signal chains that are representative of what we do with real hardware, when we no longer need to?
Mission accomplished!I used to say to my parents: when I grow up I want to be wrong!
Mission accomplished!
It makes sense. From my experience, the more time I spend on a sound the less productive it becomes. Furthermore, I start to perceive the sound differently. Whereas if I go and dial something in quickly while my ears are fresh I can more reliably create something I'll enjoy later.Fwiw, usually when I do these comparisons I try to not spend too much time on the platforms. In this case I only spent a bit more time on the TMP because of the factory reset that I did but turning some knobs doesn't have to take much time. With the Fractal I didn't to into any of the deep parameters etc aside from the resonance control. I like to keep things simple, it also helps to keep me sane!
I thought the same thing. I owned a 5150 III for a short period and never got it to sound anywhere as good as Jon did in his video. The IR and knowing how to set the amp makes all the difference.Moral of the story for me is I should go play with the 5150 III models in my Axe III, because those sounded great. Need to go grab a few of the updated Ownhammer IRs, too. I haven't bought any in a while, what with the Dynacabs and all
You are right. But leave it to the internet to point out how you're wrong even when you're not.I was right though
You are right. But leave it to the internet to point out how you're wrong even when you're not.
You might think a bug is "an error caused by improper programming", but according to my experience as a dev it is "anything the customer or an executive doesn't like, even if intentional and you have a JIRA ticket to back that up". This seems to be a case of the latter to me.
You're missing the point. It's not actually a bug and they did test the model out. Then when a customer demonstrates that it sucks, some manager somewhere goes "that's a bug, fix it software man" despite having already signed off on it as good.The thing is though, bug or not you'd assume they would try the models out to see if they sound good after the programming?
You're missing the point. It's not actually a bug and they did test the model out. Then when a customer demonstrates that it sucks, some manager somewhere goes "that's a bug, fix it software man" despite having already signed off on it as good.
It's better PR to blame a "bug" than to say they fucked up