Digital_Igloo

Yes, the editor is next. In fact, we've had to defer a bunch of stuff we wanted to get in by now because it'd push the editor back even farther.

We can make the boot time faster but chances are you guys would prefer other things first.

If you have a block assigned to, say, FS2 (second switch on the top row), sending CC50 (any value) should toggle that block on and off, regardless of the current footswitch mode. "Stomp mode only" refers to that CC controlling whatever's assigned in stomp mode; that is, it doesn't trigger what appears on FS2 in Preset mode (a preset), Looper mode (Undo), or Pedal Edit (Knob 2's parameter).

Footswitch modes only apply to Helix and Helix Control, but you can still assign blocks to footswitches manually from the Footswitch Assign screen: Press MENU (three lines icon). Press Knob 1 (Footswitch Assign). Use the joystick to select the block and turn Knob 1 (Footswitch) to select the footswitch. Repeat step 3 for other blocks and press HOME when you're done.

What's more, DSP/sound design and MCU/feature development don't overlap all that much, as we have engineers working in both camps. Everyone should feel free to request away.

Since Helix can have more than one amp model, it's easiest to set preset level from the Output block's Level parameter.

Updated thread to 1.06.5 (released 16. February 2016).

Single commands (MIDI CC, Bank/Prog, MMC, Ext Amp, CV Out), when assigned as Instant (lightning bolt) 1-6, will be recalled upon preset selection Single commands (MIDI CC, Bank/Prog, Note On, MMC, CV Out), when assigned to a footswitch, will not be transmitted upon preset selection Dual-state commands (CC Toggle, Ext Amp, CV Toggle), when assigned to a footswitch, will be transmitted upon preset selection; its value depends on the switch's current state (dim or lit) By default, selecting a preset will also transmit a PC message on the Base MIDI channel; this behavior can be disabled at Global Settings > MIDI/Tempo > MIDI PC Send/Receive.

Embedded DSP firmware is not like UNIX/Windows software.

Doesn't matter; if any portion of any model is to be engaged (or "switched") seamlessly with no gap or delay, it needs to be loaded into, and therefore eat up DSP. This means any amp model elements beyond what's required for a single channel will require more DSP than that channel alone. While it's true that two separate amp models—one for each channel of the same amp—may take up more DSP than a single "multichannel" model containing shared elements for both channels, we'd likely be looking at some weird new "Multichannel Amp" subcategory, containing combinations of channels so everyone can optimize their DSP usage: Channels 1 and 2, Channels 2 and 3, Channels 1 and 3, and Channels 1, 2, and 3. And then of course the people who want a Marshall and a Fender to be considered separate channels (a more common use case than channels of the same amp) within the same "Multichannel Amp" model are out of luck. In my opinion, if a feature takes longer than a paragraph to explain to your average guitarist, it's a bad user experience.

Roland writes custom Mac drivers to bypass Apple shenanigans. We're doing the same.

I'm not an engineer, but I was in all the meetings years ago where people way smarter than I discussed and debated this ad nauseum for weeks. Tons of "why don't we do this?" followed by "because when the user does x, y, or z, this breaks." "Oh crap, yeah." First of all, embedded dual-DSP architectures are very different from multicore processing in UNIX/Windows. A single model cannot span multiple DSPs; every time you add or move a block where it might require a jump from one DSP to the other, all sorts of insanity ensues—latency could double, random short audio dropouts might happen, you might not be able to add a reverb before a delay, but you could after a delay—WHA?! There are always things we can do to improve things, and perhaps the next generation of SHARCs will have more robust management, but suffice to say, everything we did was for one or more of the four reasons outlined in my post above. At one time, Helix had two home screens—one with a pedalboard, and one with a rack—and you'd press HOME to toggle between the two of 'em. It was an artificial restriction imposed on the user to make the separate DSPs appear even more separated, so any behavior would look like a design decision and not a technical one. We later decided that the workflow of putting both pedalboards on one page was vastly superior, and if/when people started getting geeky, we'd just deal with it.

When it comes to Helix's dual-DSP architecture, there are generally four reasons why we didn't do X, Y, or Z: It's impossible It'd result in notably increased latency It's really difficult and/or time-consuming and we have bigger fish to fry (every feature you guys request pushes back another request, which is why we have IdeaScale to help prioritize things) The current implementation is required for future plans we can't talk about right now Yes, being able to add whatever you want, wherever you want, on any path means that with some presets, you might have to do a bit of planning. The alternatives are all much worse—super-restrictive model allocation (one Amp+Cab, one delay, one reverb, that sort of thing), 30-50% fewer simultaneous effects, tons of wasted DSP, the inability to freely copy/paste blocks, etc.

Nah, he has a right to be miffed. Sometimes I take for granted that many of you already know the whole snarky exchange this place (and TGP) has. I can imagine it's a bit odd at first discussing the hows and whys directly with the people who design the gear you use. I would've provided more context had I not been typing from my phone at my fiancée's über-religious grandfather's 90th birthday. So apologies, totgate. The thing with L6 LINK is that it's an open-ended one-directional audio and bi-directional MIDI platform with zero inherent features. Depending on the product—or rather, groups of products specifically designed to work together, like StageScape and StageSource, or POD HD500X and DT50—it can be extremely powerful... or do nothing. In the case of Firehawk 1500, adding L6 LINK would literally do nothing but replace a single analog cable with a single digital cable. There'd be no consolidation of cabling, there'd be no extra features, and you'd pay more than $999, because L6 LINK ain't cheap. StageSource maintains L6 LINK because it was designed to be networked with and remotely controlled by a StageSource M20d mixer. If there was no M20d, L2 and L3 probably wouldn't have L6 LINK either, because again, replacing one analog cable with one digital cable isn't worth the effort or MAP pricing increase. So if there's a specific feature or set of features one would want L6 LINK to accomplish, they'd have to let us know what they are. That's all. If one's used to a particular tube amp, they should absolutely, positively use their tube amp; in fact, we designed Helix to work great with tube amps, both with 2CM and 4CM. FRFR is a completely different kind of experience, and if you're accustomed to the feel of a tube amp flapping the back of your pants, yeah, it's not the same. It was never meant to be the same. Luckily, I'm a studio rat, so when I experience tube amps, it's from the control room while amps are mic'ed up in another room. Modeling sounds 100% natural to me.

Your point of view is that L6 LINK is a "nice interface?" What does that even mean? Unless you know what you actually want to accomplish with L6 LINK—that is, actual features or specification thresholds, you might as well bemoan the fact that Firehawk 1500 also doesn't have ADAT lightpipe, HDMI, a garden hose, or a free puppy.

Shoot ourselves in the foot? Huge mistake? What do you think L6 LINK is? What specifically would you expect it to accomplish?

We make one—Firehawk 1500. And there are also excellent powered cabinets from Mission, Matrix, Atomic, and Friedman. If you're talking about cheap flat-ish amps or PA speakers that some people suggest are worthy of the "FRFR" moniker, there are probably a hundred to choose from. The FRFR market isn't nearly big enough for us to lose money on a box that would only serve to end up the weak link in a full-range Helix rig.

Did you not read my explanation two posts above yours? More importantly, what would you expect L6 LINK in Firehawk 1500 to do? What could it possibly accomplish where not having it is a "deal breaker?" Literally the only thing one could ever possibly argue is that analog cables add a D/A/D conversion, but AFAIK, no current guitar amp or FRFR speaker has AES or S/PDIF digital inputs anyway, so... what's the alternative?

It's not about the switches as much as whether the UI MCU can interpret double-taps. The answer is yes.

Why would you have to patch in an outboard EQ? If you went analog, you could absolutely use Helix's Global EQ. In fact, the only advantage of L6 LINK over analog today—if it's one or two StageSource speakers and not a network of multiple speakers—is skipping a D/A/D conversion, which is more about avoiding the wringing of hands than any perceivable loss in sound quality. But to be perfectly honest, the main reason we don't waste DSP on sending Global EQ via L6 LINK to L2/L3 is because those speakers already have 31-band Graphic EQs built into their DSP. StageScape M20d can remotely control this EQ right now, and Helix could conceivably do the same (I think, maybe?). I have the whole thing specced and designed—we just need you guys to prioritize it.

I could possibly imagine a scenario where the user would be forced to manually load multiple channels and whatever "amp circuit spillover" could intelligently kick in. But to make multiple channels load by default (even if it's only 5% more DSP) when the majority of people only use one channel is still a waste. Any DSP waste is always frowned upon in dynamic, embedded DSP circles. That said, fixed and semi-fixed DSP solutions are always wasting DSP in the interest of simplicity, ease-of-use, and ease-of-development, but in those cases, the products would almost certainly be artificially restricted to one amp channel (and likely one gate, comp, distortion, mod, delay, and reverb), so the point is moot.

When memory is cheap and DSP is more powerful, we'll still be having this conversation because any headroom will forever be eaten up by more granular and even better-sounding modeling. Having extra amp channels just sitting there waiting to be enabled, eating up DSP for no reason, should never happen in embedded systems. If for whatever reason it does, that just means you're wasting horsepower that could be used for more effects or better-sounding models. Computers have no problem with background usage because they sacrifice throughput latency for cycles. Crank your buffers way up and you can run an ungodly amount of amp sim channels at once. But try to play through those plugins in real time, and the latency'll kill ya. On a peripherally related note, Helix will never have a global looper, because when more than half of your customers never touch the looper, it's asinine to force everyone to waste 4-7% of a DSP on it when that 7% could go toward an extra delay—or choosing a better-sounding delay model that wouldn't otherwise have enough DSP to load.

I've always heard it "Not Available, Maybe May."

It's absolutely a DSP thing. If one amp channel takes up, say, 40% of a path/DSP, two amp channels might take up 60-70%, and three might push you to 80-90%. For the vast majority of people who only use one amp channel per preset, two channels they'll never use just wasted half their horsepower. And for what reason? Fewer items to scroll through in the model list? Turning the model joystick is just as easy as turning some imaginary "Channel" parameter knob.

Whoa, I stand corrected. One person! All my work wasn't for naught! You made my day, my friend. :D Not at all. We're still developing new products with L6 LINK; the protocol would just be wasted on Firehawk 1500, because it's not a product anyone would network—except for ColonelForbin, apparently. ;)