kronda

I'm not asking how to do something, just why some feature in Native is limited the way it is while it would make perfect sense (to me) to implement it differently. Doesn't matter, perhaps Line 6 will extend this functionality in a future version.

Thanks for your reply but that's not what I'm asking about. Of course that a single automation lane in any DAW will usually control only a single parameter. But in case of Helix Native this parameter to control is an abstract Switch or Knob. And if you look automating, say, Switch 1 as automatically pressing Footswitch 1 on Helix Floor that you can imagine that multiple actual block toggles could be assigned to Switch 1 similarly as multiple actual block toggles could be assigned to Switch 1 in Native. My question is why did Line 6 resort to this indirect parameter automation while not allowing to assign multiple actual parameters to individual Switch X and Knob X abstract controllers? Rather then exposing all the actual parameters directly (like Amp [Slot A1-3 Drive, Reverb [Slot A2-6] Mix etc)? I guess it's kind of easier to like this, otherwise finding the right parameters could be a nightmare. I would just love if they made that one more step and allow multiple actual parameters assigned to individual abstract controllers... I guess IdeaScale is the only way to get this noticed by Line6.

Hi Guys, so I noticed I cannot assign multiple blocks to one automation Switch to toggle multiple blocks at once by a single automation lane (in Cubase in my case). It's even mentioned in the manual so I get that it's intentional. Could anybody explain why? It would directly correspond to how Helix Floor footswitches work so I'm a bit puzzled. I would often use this feature because whenever I start automating I feel I'd like to make that change more pronounced (say switch on drive and mod and delay at the same time for a solo). Currently I end up with multiple automation lanes having exactly the same shape just to control 2 or more block toggles (or min-max parameter value changes) at exactly the same time. I guess I should use snapshots but I always start with a simple one block switch and then just want to add 1 or 2 more blocks to the same switch so it's not convenient to change the lane in Cubase... Just wondering, I can live with it, just this seems like an inconsistency in otherwise perfect system. Thanks for any opinions.

The only hint I've seen is the survey sent out couple months back by Line 6 to current Variax users (asking about which features we dont/use and what new we would like to see in new Variax models). I still take it they may or may not decide whether it's worth making a new gen. I'd love to see it. Only have Variax Bass and Acoustic (so gen 1) now and except for Shuriken the gen 2 models (JTV and Standard) are aesthetically too repelling for me and Shuriken is just reusing the 4(?) years old gen 2 tech which simply cannot justify the money spent. But not to steal this wonderfull topic: Let's get back to moaning about not getting the new Helix firmware today...

Cool, so it's already been turned down by Line 6. Thanks for the link. If I understand it correctly DI still offered the IdeaScale way of pushing it forward but doesn't seem likely to happen even if it made it to Top 10 requested...

Yes, that's a possible simpler way of enhancing our options. But would have to be switchable - e.g. the current behavior stays as Impedance setting AutoFirst and they could add a new option AutoFirstActive or something. Otherwise current presets using Auto would change sound completely.... Here you go: https://line6.ideascale.com/a/idea-v2/907926 It's really in evetyone's HO what's more confusing - true/false bypass for each effect or a specific impedance for each effect (if I understand you correctly). Yes, everybody knows the code inside out here :) For me it doesn't seem like a big deal (I'm a programmer, of course) but could be wrong. So let's conclude with "maybe it can be done, maybe it can't, only Line 6 know and they wont tell"? I just don't get it why people make these negative conclusions without knowing the code ("Yes, that's too DSP intensive, forget it"). We're just creating inspiration for Line 6 here, how about letting them be the ones turning it down if it doesn't make sense...? Creates unproductive discussions ("Hey, but my phone's app can do it! It can't be that DSP intensive...") about something (Helix code) that nobody here knows. IMHO, of course. And full respect for everybody's opinion.

It would actually be very cool if Line 6 added a "True Bypass" parameter to every pedal. That way we'd have perfect control over the impedance propagation thru the pedal chain... If a fuzz would be first in the chain with True Bypass set to true and the preset would have Impedance set to Auto, then switching the fuzz off would mean the impedance would be dictated by the next pedal in the chain.

I don't disagree with this but it's interesting to check out the Facebook page "Shuriken Guitars". Recently there were some posts asking about preferred other finishes and also which bridge to use for a regular scale Shuriken (should it ever be made...). May not happen at all but it at least shows people are thinking about it. And that there are more than 6000 people following that page...

If you check "Shuriken Guitars" on Facebook there is a bit of info there - basically something about the CITES procedure (rosewood imports) and that delivery in Europe is expected by mid-September. But someone with Shuriken on order from Thomann also said there that he got an update from Thomann recently - delivery Oct 31 :( Hard to understand these delays when there are Shurikens available in stock in US (Sweetwater). But I also understand that the European eshops decided to pull the product from there webpage since the distributor is evidently unable to provide a reliable delivery date.

Hm, if the new models are indeed complete for some time then (if I was the dev lead and the whole architecture was in a good shape) I'd merge them in and release 2.30 firmwares before starting Native beta testing and then iron out all bugs in that version and release Native with Core 2.30. I understand if they chose not to merge but then it just shows that the current architecture of Helix Core needs to be fixed first to allow smooth merging of new models while working on platform enhancements. But I understand that multiplatform development is always messy so not saying I'd be able to do it better. So again, no problem here, just the delay explanation describes "fixing" as exciting news...

Wasn't there also a similar explanation why the current Helix Editor took so long? I'm not sure, just feels to me it's been 3 times so far. Anyway, in almost 2 years of Helix history there have probably never been a fast and simple "routine" update just adding new models (amps, fx...). For example when 2.20 firmware was being delayed, Digital_Igloo said that Ben already started working on 2.30 models. That was in February I think. So why haven't these models been published yet? If because of Native then the development stream is essentially single-threaded, which isn't something to write home about since different people are working on very different things. Anyway, in principle I'm not mad about it and not trying to say Line6 is doing a bad job. I'm just a bit immune to excitement some users here experience when reading "explanations" of why delays are happening.

Well, as a software developer I know I went this rabbit hole many times - spending awful amounts of time refactoring things so that possibe future improvements are so easy... But these improvements never happened and the time was wasted. As a Helix user I'm not sure if (or better "how much") this is the case with Helix but so far I've seen much more news about "delays happening due to faster future development" than, well, faster developments. But in any case, Helix is making me happy and I'm starting to need Helix Native about now (album recording starting) so it should all work out.

So Helix and Helix LT are really the same in this regard? I thought you'd sort it out for LT release...

No, you misunderstand... :) Alright, we can do this all day. I think that it's totally pointless to think in terms of "primary functions" when it comes to a piece of gear such as Helix which was I believe designed mainly to be "flexible".

I mean, who said so? (rhetorical question...) There's no point arguing here, I just wanted to express disagreement with your previous statement which sounded like "this is more than Helix can handle/was designed for..." and backed that with my argument about independent processing paths and extensive I/O options. Because I don't see a single reason (other than "my feeling is..." which is not a reason) to limit myself from using Helix to its full potential. And based on my (great) experience with Helix I'd like to encourage others to do so as well.