DunedinDragon

Congratulations. I just got my Helix in last week. Like you I was a HD500X user. It should be a very easy transition for you. But I will tell you that you'll have your work cut out for you if you want to evaluate all aspects of the Helix within 30 days. There's a lot of stuff there. The good news is you'll immediately feel pretty comfortable with most of the stuff having come from the HD500 environment. One thing I discovered that you might want to use. In the Helix you can choose to use either an Amp+Cab block, or separate amp and cab blocks. I'd highly recommend using separate amp and cab blocks as that will give you the opportunity to so a split between the amp and cab so you can use a second cab block (or IR block) in your mix. You can get some truly remarkable sounds this way. Lots of cool variations on this with the flexibility in routing it affords you. Have fun...

One more quick idea for you. I noticed you particularly called out the low to low mids. You didn't say what kind of setup you're running, but I have noticed on my FRFR rig that in some cases the low end of my guitar sounds a bit flabby and not well articulated. Usually I can tighten up that low end by dialing up the low cut on the cabinet to around 500 Hz.

I'm sure it would be nice FOR YOU...but for me and most people I know using modelers, 60 seconds is more than enough and most people I know with modelers. I have many other options for practicing with a long track...like using the aux in froman MP3 player or using the Helix as a sound board from the computer. If I need to practice a lead, 60 seconds is more than enough to cover the phrase I need to play over, but generally I'll just record it to my DAW and play it back through the USB. So even the looper they've got isn't anything I use. And it's not just the price of memory. An HDXC slot would have to be designed into the case. And since this isn't just a general purpose operating system but a highly specialized real-time operating environment the HDXC unit has to be electronically designed into the circuitry and code has to be written for it, tested and integrated with the rest of the features..insuring that it doesn't interfere other key capabilities. This isn't some off-the-shelf PC with guys hacking away at the code in mom's basement. All of that comes with a with price. Or, you can easily add in a much better looper to fit your specific use right off the shelf from most music stores and have exactly what you want. There's no need for me to pay for it.

Personally I didn't buy the Helix to be a jack-of-all-trades. If I want a sophisticated looper I'll buy one and hook it in. But since I have no need for one I'm glad I didn't have to pay for one that was built in to the unit that I would never use.

Just to make sure you understand... The HD500X is an amp modeler, not just an effects unit. In your configuration if you try and use the amp models you're putting a pre-amp (plus a bunch of other stuff) in front of your amp's pre-amp which is what's causing the problem. What BillBee is referring to is that many amps have an effects loop out and effects loop in. Plugging into the effects loop in effectively bypasses your amp's pre-amp and just goes into the power amp and speaker portion of your amplifier. But you don't really have a facility like that on your amp. What you can do is use the HD500X just as an effects unit without the amp models the way you're hooked up. As long as you don't have any amp models engaged you shouldn't overdrive your pre-amp. But you should still make sure you have studio direct set as your output mode.

Although I generally agree with what you're saying about FRFR speakers, the graphs you included don't really show the response characteristics of an FRFR speaker because we're talking about both a standard speaker plus a compression driver that addresses the higher range of frequencies, which will be the same as most FOH systems have nowdays. It still won't be exactly "flat" but it will have a much broader response than a typical guitar cabinet with no compression driver. And although your sound may be in someone else's hands when it comes to the PA, my concern is being able to ensure as much as possible that the sound I'm hearing on stage is the sound that should be going out of the FOH speakers. It's far more likely I'll achieve that with a FRFR rig that has a compression driver similar to what's being used in the FOH speakers than with a guitar cabinet which could very easily deceive you about how your patch actually sounds in the FOH via your XLR feed. In my experience not all cabinet models do an adequate job of managing those upper end frequencies resulting in a tone that sounds far more brittle than what you're hearing on stage. Yes, there's more work involved in dealing with the FRFR speaker to dial in the tone, but I would rather know for sure what things sound like out front. In your case you may have solved it with your setup, but for many people that use very different models and cabinets in different patches there's just no other way to really be sure.

Has this crash only happened when editing? Has anyone had it crash during a performance? I can deal with crashes if it occurs during editing but I'm really concerned if this thing crashes during a performance. You're talking a couple of minutes of downtime for it to reboot.

I don't know anyone that hasn't struggled a bit to get their sound right going through powered speakers. But in my mind it's worth the time to find the recipe that gets them sounding right. The fact is, you can use headsets and it makes things pretty easy, but the sound you get coming out of that powered speaker is the sound the audience will hear if you play live through a PA. So in reality there are other solutions that would give you an easier time getting a good stage sound, but if you go direct to a PA it won't really matter that your on stage solution sounds good because the audience will be hearing something completely different. If you can master getting your sound right through the powered speakers the sound tech running a PA board simply has to set your EQ flat and the audience hears what you hear. What I do is set my speakers with a flat EQ and use the Global EQ to constrain the frequency response to something generally close to what a normal amp and speaker cabinet produces. I set the low cut around 125 Hz and the high cut around 7500 Hz. That helps a lot with the boominess at the low end and the brittleness at the top end. Beyond that it tends to be minor tweeks that tame various frequencies depending on the amp and cabinet being used in a patch. The good news here is the Helix offers a multitude of ways to do that and to tailor your sound so that it works well in the context of a live band so that you;re not competing with vocals or other instruments and can be heard without having to depend on volume.

That's referred to as 'sustain' and you can add sustain a couple of different ways depending on what you want to do. Generally speaking any of the distortion pedals will add sustain. How much sustain depends typically on the Drive parameter of the pedal. But that may also add too much distortion. The Tube Screamer is a pretty good pedal for adding sustain and controlling the distortion. Another way is to use a compressor pedal if you don't want to change the tone of the guitar that much.

I'm confused. What purpose does q base (whatever that is) serve? You should be able to play directly through the Helix with either the speakers or the headset.

Yes, I'm a retired programmer/project manager. I started off in COBOL, FORTRAN passed through the Pascal, FORTH, 68000 Assembly phase and ended up in the C, C++, VB, HTML era. So, yeah, I'm not put off by changes in technology. However, I think things like the Helix or modeling in general appeals to people who tend to embrace change and are enamored by technology. Their careers may have nothing to do with it. But I will say that people that are technophobes are typically the ones that struggle the most with this type of change in paradigms. But my "real" job of being retired doesn't exactly play into your theory of being able to afford something like a Helix. It's just that I'm really careless with the way I spend money. :D

I totally get where you're coming from. What people tend to forget is things like VST's were architected from the very beginning as a plug-inable interface specification that took many years to gain the stability it enjoys now. It's a double-edged sword in that the potential for gaining massive market share is there, but the support and education requirements to ensure developers use interfaces appropriately without tanking the system is daunting. And the biggest issue is that armchair sound designers/developers aren't very well known for their testing discipline. I've got quite a library of early VST's that prove that point!!!

If it helps to understand this, the only thing actually required to have a functioning Helix is the firmware, and you're correct in saying the firmware is Helix's own operating system and has nothing at all to do with any external computers. The application software known as the Helix editor is an optional piece of software simply used to manage the Helix from a computer interface and save/backup/restore presets to and from the computer and the Helix. The other piece of application software that's necessary in order to update the firmware is the Line 6 Updater. It's sole purpose in life is to update the Firmware on the Helix unit. There is one other piece of software that is the device driver which is used by both the Helix Editor and the Line6 Updater to communicate between an external computer and the Helix. The Helix device driver is also used to allow the Helix to operate as an audio interface to a computer.

I just went through L6 customer service to figure this out. The Helix application v1.09 is just the early release of the librarian portion of the Helix Editor. If you successfully downloaded and installed the 1.12 firmware and the Helix Editor you have everything you need at this point.

What you say appears to be more true in corporate development than in commercial release operations. I would agree that in the case of critical operational bugs with no workaround you may be forced to issue an intermittent release, and increasingly in commercial systems this is becoming much more commonplace because it can be fairly transparent such as in the case of Windows update or even Android updates. Unfortunately that same kind of more or less constant internet infrastructure and background processes to support it aren't available on something like a dedicated hardware box like a Helix, and aren't likely to be due to the real-time response nature of the hardware. So you're more or less stuck with a more invasive updating process that requires some human involvement, which makes it much more of a problem. Not to say you shouldn't ever do it. Sometimes the nature of the bug, such as a system lockup given a high frequency of occurrence simply requires it. I can't say whether these bugs are invasive enough to require it because I haven't had my system long enough to encounter them. I might feel differently if I begin to encounter it more often. There are certainly tools like test harnesses that can be useful at the bench, unit, and sometimes stress level testing, but those aren't typically the areas that take the most time. System tests and integration test by their nature pretty much demand human interaction not only for configuration and input but for analysis of adequate completion. Testing is just a heavy process in the commercial environment. In our case for every 1 developer we averaged 3 testers. It's just the nature of the business. I'm sure they will eventually get to a point of general stability that will allow them to lock down the code base and begin working on enhancements, but we're talking about a system that's still in it's first year of release. I'm not going to personally get too excited about thinking we'll see much in the way of enhancements until things get a lot more stable.

I don't see what the big deal is here. Even were you to do this you'd still need an idea of what level you want your patches to be normalized at. To me it's just easier to set my master volume where I want it going through my normal FRFR speaker as I'm building or tweaking my presets and check them with a sound meter. For my purposes I target 80db at half master volume for normal output and around 83db for lead output. This level works in most cases with my band but if, during sound check, I find I need more or less I just turn the master volume level up or down and it affects all of my presets equally. I've been doing this on various modelers for years and it hasn't failed me yet.

Having spent most of my career as a developer and project manager for a commercial software company I can say with some authority that the speed of development is FAR more complex than just a function of quality and quantity of manpower. Those are two factors, but at some point quantity of manpower begins to produce diminishing returns as you can only reasonably partition out responsibilities so far before they begin to interfere with each other due to critical path dependencies and/or team coordination issues. Especially in this case where you have multiple known bugs. What you want to do is minimize the number of releases so you don't aggravate customers by piecemealing out bug fixes. The process of bug releases is no different than an initial product release. It has to be rock solid and NOT introduce new bugs into the system. Therefore it has to be bench tested, unit tested, and system tested as each bug is fixed. In fact, the testing cycle alone in a case like this needs to be far more robust than the development cycle because the worst possible scenario would be to have to recall a release because it introduced a worse bug than what you were trying to fix. With all the functionality in the Helix you can well imagine how extensive and time consuming that test plan has to be. I only bring this up because I hope people will cut L6 some slack on this. I would rather wait a bit for a rock solid update release than get it sooner and be frustrated by either them not fixing a bug I'm depending on, or introducing a less than stable release.

The Helix is designed as a dedicated real-time processor. That's very different from a traditional computer or smart phone that most people are familiar with, but it's necessary to maintain the real-time responsiveness needed for live audio processing. The more "pretty" stuff you add, the greater the computational cycles you'll need to manage that aspect of the operations, thereby increasing the likelihood of latency in processing audio. Not a good trade-off in my opinion.

Tonight's forecast: Dark. Continued mostly dark. Changing to widely scattered light by morning........... :blink:

I examined both products very carefully reading through their operator's manuals and lots of reviews. I suspect both will have their own following, but for different reasons. One of the key issues I suspect that will drive the differences will be the amount of time the customer has spend in the modeling world. Those that are relatively new to modeling will likely be drawn to the massive counts of amps and so forth. I doubt that will be all that important to anyone who's been dealing with modeling as a consistent part of their rig for 5 or 6 years. In that time you've come to appreciate the fact that regardless of how many amps you might have in your modeling lineup, in all likelihood you'll settle on just a handful that you're comfortable with and know how to get the sounds you want out of. I know for myself the number of amps hasn't been important to me in quite some time. I look for key amps in the lineup that I know and have used in other modelers. What is INCREDIBLY important to me because I've used modeling as long as I have is the versatility provided in constructing the signal chain. That far and away makes a much bigger difference in the control you'll have over your sound than minor differences between amplifiers. I think that is what Line 6 learned from it's user base and is the reason for the type of key features you see in the Helix. Let's face it, no one on this planet has had the experience that Line 6 has had in this area. And with experience comes a customer base that can give you ideas on how to improve the product. I'm sure at this point Fractal is beginning to hear from their customers about improvements they would like to see in signal chain construction. But they've got a lot of ground to cover to catch up with Helix features. And Helix will continue to march forward backed by the deep pockets of Yamaha.

I got all of you beat...I latched onto George Carlin in the mid 1960's when he was doing his "hippie dippy weatherman" routine on the John Davidson TV show wearing a coat and tie with a nice respectable haircut.....

It might be possible it was related to the Alto being off. I know this happens occasionally with the XLR out from our bass player's rig if the amp isn't turned on. It clears up as soon as we turn on his amp.

I would think a loop early in the signal chain should do it. It's certainly easy enough to test. As to whether you would suffer any signal loss, that's really a matter of how efficiently the Digitech handles the signal. We could speculate on all of these things for a month or so, or you could set up a test and figure it out in about an hour.

I'm not sure you're actually going to get what the FOH is getting if you're in PA mode and the speaker is positioned on the floor as a monitor. What you will get is a bassier version of what the FOH is getting due to bass buildup the occurs when it's in this position. In monitor more this is compensated for.

Pretty much any PA system is going to have a much fuller range of response than a guitar amp because guitar speaker cabinets have a limited response range by design. This is the reason many people have opted to use powered monitors rather than amps to ensure that what they are hearing is what's being sent out through the PA.