Maybe someday...

[hideout]

I still have my Fender Mustang Floor and I keep it as a backup but also because I actually like the way it sounds - for what it is. No, it can't hold a candle to the Helix but I still like it. Now, to the point.

I like the graphical representation of the amp in the Fender Fuse computer editor software. Yeah, it's always a Fender amp that you see, no matter which model you're currently using but there's something oddly comforting about seeing an amp's knobs on the screen. I do wish Line6 had gone this route on both the pedal and the editing software. Those sliders just feel alien to me. Yeah, some people have issues turning knobs with their mice but if Line6 made it so that hovering the cursor over a control knob and rolling the scroll wheel turns the knob, it wouldn't be an issue. My DAW of choice (MOTU Digital Performer) does this now.

It sure would be nice to see a virtual amp faceplate instead to those nondescript sliders.

 

Maybe someday...

[Digital_Igloo]

There are many reasons why we chose to go with a flat design and sliders instead of skeuomorphic panels with knobs:

• Sliders allow for much easier parameter control on touchscreen-based PCs (and eventually, touchscreen-based Macs)
• Sliders have much higher granularity (both visual and control-wise) than knobs
• Slider length can easily scale when resizing windows; knobs could conceivably shuffle their order when resizing, but then it's harder to find the right one
• Sliders allow for better and cleaner application of sub-indicators, such as min and max values, snapshot values, or meters
• There are instances where parameters may disappear or be renamed, depending on the settings of other parameters; sliders make this behavior much more transparent
• Helix models often have different parameters (and number of parameters) between the mono and stereo versions; sliders make this disparity much more transparent
• The studio-to-stage-and-back promise of Helix hardware and Helix Native plug-in is immensely important to the platform; there's an intrinsic advantage in maintaining visual consistency between the two
• Perceived preset switching delay in Helix hardware is partly due to redrawing components on the screen; redrawing huge custom panels would exacerbate this
• The knob position of some amps are much harder to ascertain quickly compared to a slider—especially Fender knobs
• Accurate panels that reflect the real amp and pedals often require radically disparate panel dimensions, meaning the plug-in size would blow up
• Accurate panels require the user effectively re-learn the UI and layout of every amp and cab, along with their quirks (UA plugins drive me completely bat$#!% insane because of this—Yes, I know that's how some API EQs are laid out, but why do the plug-in's knobs have to be upside down?!)
• Some people mistakenly equate quality of panel graphics with quality of modeling ("Oooh, did you see the fingerprints on the metal there? It's gotta sound the best!"); chasing that dragon is a lesson in futility and we'd rather spend our resources on system architecture and sound design
• Accurate panels imply to the user a specific rev of a particular piece of hardware, even if the plug-in supports switching between multiple revs or may represent an idealized amalgam
• Accurate panels require dozens of knob positions (and if you do it right, multiple versions at different viewing angles) which take a lot of time and redraw resources. Not an issue if you have five amps; definitely an issue when you're adding more all the time
• Accurate panel aesthetics often subconsciously sway users toward (or away from) specific models instead of trusting their ears ("Oh, I won't use this model because it looks like a metal amp")
• Accurate panel aesthetics require legal involvement to determine if any trade dress might be violated
• Individual panels often take up the majority of a plug-in's overall download/install size
• Accurate panels with knobs often require dedicated graphic designers or outsourcing to design firms, if only because our designers have a lot of other stuff to do (fun fact: one particular GUI design firm in Germany creates the panels for dozens of MI companies, which is why so many look alike)
• We'll often tweak and re-tweak models right up until release; it's also not uncommon to swap in a different model or add/delete/replace/rename parameters at the last second. Since accurate panel iteration takes a lot of time to get right, it could literally delay firmware updates (or hardware releases!) by weeks
• Everyone else does hyper-accurate panels—even super cheap iOS amp sims—and skeuomorphism doesn't hold nearly as much weight as it once did
• Several other reasons we can't talk about because they deal with future features

Conversely, there are only two reasons to go with skeuomorphic design with knobs:

• Subconsciously, people think the plug-in might sound better because it looks like a real amp or pedal; for example, a few mistakenly believe Logic's compressor sounds better now, simply because of new skins
• "Ooooh... pretty."

I won't claim any of our decisions are objectively correct—this is design, after all—but this might provide some context as to why we landed where we did.

[markdenman123]

Certainly seems well thought out!!

[hideout]

@Digital_Igloo

 

Oh... alright... I guess. 😂😂

 

As I once heard said on Sesame Street, "It was just an idea, I never said it was a good one."

Well, ok I did say it was a good one but you're right, of course. Thanks for the clarity.

[Rocco_Crocco]

skeuomorphic 

[brue58ski]

There are many reasons why we chose to go with a flat design and sliders instead of skeuomorphic panels with knobs:

• Sliders allow for much easier parameter control on touchscreen-based PCs (and eventually, touchscreen-based Macs)
• Sliders have much higher granularity (both visual and control-wise) than knobs
• Slider length can easily scale when resizing windows; knobs could conceivably shuffle their order when resizing, but then it's harder to find the right one
• Sliders allow for better and cleaner application of sub-indicators, such as min and max values, snapshot values, or meters
• There are instances where parameters may disappear or be renamed, depending on the settings of other parameters; sliders make this behavior much more transparent
• Helix models often have different parameters (and number of parameters) between the mono and stereo versions; sliders make this disparity much more transparent
• The studio-to-stage-and-back promise of Helix hardware and Helix Native plug-in is immensely important to the platform; there's an intrinsic advantage in maintaining visual consistency between the two
• Perceived preset switching delay in Helix hardware is partly due to redrawing components on the screen; redrawing huge custom panels would exacerbate this
• The knob position of some amps are much harder to ascertain quickly compared to a slider—especially Fender knobs
• Accurate panels that reflect the real amp and pedals often require radically disparate panel dimensions, meaning the plug-in size would blow up
• Accurate panels require the user effectively re-learn the UI and layout of every amp and cab, along with their quirks (UA plugins drive me completely bat$#!% insane because of this—Yes, I know that's how some API EQs are laid out, but why do the plug-in's knobs have to be upside down?!)
• Some people mistakenly equate quality of panel graphics with quality of modeling ("Oooh, did you see the fingerprints on the metal there? It's gotta sound the best!"); chasing that dragon is a lesson in futility and we'd rather spend our resources on system architecture and sound design
• Accurate panels imply to the user a specific rev of a particular piece of hardware, even if the plug-in supports switching between multiple revs or may represent an idealized amalgam
• Accurate panels require dozens of knob positions (and if you do it right, multiple versions at different viewing angles) which take a lot of time and redraw resources. Not an issue if you have five amps; definitely an issue when you're adding more all the time
• Accurate panel aesthetics often subconsciously sway users toward (or away from) specific models instead of trusting their ears ("Oh, I won't use this model because it looks like a metal amp")
• Accurate panel aesthetics require legal involvement to determine if any trade dress might be violated
• Individual panels often take up the majority of a plug-in's overall download/install size
• Accurate panels with knobs often require dedicated graphic designers or outsourcing to design firms, if only because our designers have a lot of other stuff to do (fun fact: one particular GUI design firm in Germany creates the panels for dozens of MI companies, which is why so many look alike)
• We'll often tweak and re-tweak models right up until release; it's also not uncommon to swap in a different model or add/delete/replace/rename parameters at the last second. Since accurate panel iteration takes a lot of time to get right, it could literally delay firmware updates (or hardware releases!) by weeks
• Everyone else does hyper-accurate panels—even super cheap iOS amp sims—and skeuomorphism doesn't hold nearly as much weight as it once did
• Several other reasons we can't talk about because they deal with future features

Conversely, there are only two reasons to go with skeuomorphic design with knobs:

• Subconsciously, people think the plug-in might sound better because it looks like a real amp or pedal; for example, a few mistakenly believe Logic's compressor sounds better now, simply because of new skins
• "Ooooh... pretty."

I won't claim any of our decisions are objectively correct—this is design, after all—but this might provide some context as to why we landed where we did.

Mic drop.ðŸ˜

[HonestOpinion]

Great detailed write-up regarding some of the design decisions for the Editor and now I guess Native as well . Thanks DI! It still seems that drop-down menus would be preferable for many parameters that are alpha rather than numeric. If you need to select between multiple "unpredictable" text options, rather than for example, a predictable numeric  parameter that goes from 1-100, a dropdown menu allows you to see all of those options at once and is easier and faster to use. This is particularly true when there are a large number of text options. A slider forces you to scroll horizontally through each parameter option one at a time. Drop-down menus seem to also share many of the GUI advantages that DI detailed when explaining the choice of sliders, including their relative ease of implementation and positioning in an evolving and mutable GUI and the fact that they are also fairly touchscreen friendly.