SaschaFranck

Every bit this! I'm just having a sort of hot discussion on Gearslutz about options for bedroom guitar recordings. People are all over it how much better a small, isolated tube amp would sound, compared to any modelers. Right... The funny thing being that nobody of those purists has posted any sound examples (I did, see attachement, just some random stuff, forgive the random levels...) of any decent bedroom level recordings they have done. "No, I won't post my music here!" (right, a few riffs would actually be a goldmine for copyright thieves...). Followed by the good old "But real amps sound so 3D!" I'm sure you're all familiar with these kinda happenings... SF_Bedroom.mp3

I'm not exactly worrying about them. One is in pretty good hands, the remaining two are collecting dust, waiting to find someone else to make use of them (or not, I actually don't care). I think tube circuits have been analysed and copied exhaustingly enough so the world will be fine without whatever remaining role models. Regardless of whether there will be some left over tube enthusiasts in plenty of years to come, eventually tube amps will go the way of vinyl records.

But that's entirely different from what the Helix offerings do. Can't exactly tell for ripple, but hum is just static noise. And it's even absolutely getting in the way of some patch layouts as, different from other noise introducing factors, it will still be present when there's no input signal. As a result, in an A/B amp switching scenario, you will also have to program an amp bypass or a merge block "bypass", which otherwise isn't required.

*The* single most important aspect, regardless of how you place your cabs, monitors and what not, being: Once you meet a drummer playing responsible, become best friends with him/her and treat him/her as nice as it gets. These are an ultra rare breed and they need all the care there is. They also need to get all the groupies (in case that was still a thing...) in order to spread their genes all over the world for future generations of musicians to become happier people. I know a bunch of excellent drummers. But once they're "in the zone" it's still all over. Playing = great, usability = like <insert worst possible insult here>. I absolutely dig drummers like Taylor Hawkins. But in a small club there's no space for that kind of drumming, as sad as a fact that might be. It instantly destroys any approach to get a well balanced sound. Even a cranked 100W Marshall isn't as loud as a heavily smashed snare rimshot and no speaker beam hurts as much as the final 8th note crash cymbal mayhem in the final chorus of that epic rock tune you're attempting to play. There you have it. (I think there's good chances of not having too much drummers reading along 'round these parts...)

The downloaded ones. Otherwise HX Edit wouldn't even work. Fwiw, too bad, because 2.7/2.8 broke class compliance under OSX, so I can't use the Helix with my old MacBook.

From all I know, both hum and ripple are just mixing static sound in, without any impact on the core tone. Might be authentic for whatever amp models but I wish there was a global option to turn them to zero all throughout. If my real amps would've done that thing, they would've seen an amp doctor. Having said that, turning both off is the very first thing I do each time I select a new amp.

Answered to your post before you added this... And yes, I would totally agree. Most of the things could be adressed by software updates. It could even pretty much render my wish for more knobs and switches obsolete (of course it wouldn't place the switches further apart from each other - unless there's some real "physical modeling", or rather "modeled physics"...). Even more CPU demanding blocks wouldn't get in the way in case things such as my personal favourite - namely "global blocks" - would be adressed, one could just switch between patches more often and use less CPU juice per patch.

Well, you asked what would keep one away from buying a Helix... and as I already bought one, that question didn't exactly apply in my case. But anyway, here we go: - More switches and knobs. Wouldn't mind a Helix XL. Would like one extra row for each and wouldn't mind if the switches were a little further apart from each other, either. - More CPU power to accommodate whatever new algorithms that might come along. Would perhaps even allow for gapless switching in case you're not maxing out the unit (not too relevant for me, though). - Better hardware. That's something I'd gladly pay extra money for, especially for better joysticks (ideally, there would be no joysticks at all, unless they're really "military grade"). - Wireless connectivity for editors (which would then exist for iOS/Android as well - but that's not a hardware thing) and controllers (TouchOSC and the likes). - Perhaps a touchscreen, but in case there were mobile editors, that'd make pretty little sense.

Fwiw, it'd be absolutely great if that was possible. A version of HX Edit working without any installation that is, like a self-contained program. As is, when you don't own a laptop (or just don't want to carry it with you), you won't be able to, say, load your patches on a rental Helix you might have to use on whatever gigs. And it's not even all that much of an esoteric thing to happen. Some years ago, I was playing 2 weeks of shows in Tokio and the rental service delivered a GT-10 (which is what I was using back then). Now, I did have my laptop and all patches dumped onto it with me, but these days I'd likely prefer to just go there with a tablet. Anyway, I think it'd be quite sufficient if Line 6 offered a feature reduced editor for iOS and Android. Something like a librarian, allowing you to load and manage patches and IRs would likely be sufficient, maybe along with an "easy edit" kinda thing, giving you access to block parameters but maybe not the entire layout. I mean, pretty much everybody has a smartphone, for Android there's USB on-the-go cables to connect to the Helix, for iOS there's the camera connection kit (the next version of iOS devices will likely even allow you to connect things without that).

They might not exactly be "moving on" but they might come up with new hardware, a Helix V2. The software foundation being "unified" should however result in the current units to stay up to date for quite a while to come. They might not be able to run whatever super-duper polyphonic pitch blocks in complexed patches anymore, once there's new, more powerful hardware released, but well, that still doesn't mean the current HX family would be completely excluded from updates.

And to bring this to an end, here's an MP3. A duplicated (not doubletracked) guitar track. Original recording and a re-amped version playing simultaneously. 2 bars aligned and 2 bars with 2ms offset for the reamped version (which is the offset you'd get when reamping through a physical amp with the Helix under macOS). Tight vs. phasey mud. In case that doesn't bother you and you still fail to see the reason why recordings should be lined up properly (even if 2ms aren't noticeable in the timing realm for most humans, which I never even argued with), well, more power to you. Or maybe you're just saying the Helix shouldn't be used for reamping purposes. I must have misunderstood some of the Line 6 marketing then. 2ms.mp3

1) It is a bug. As easy as that. No way around it. Whether it affects you or anyone else is completely irrelevant. The audio interface part of the Helix isn't working accurately under macOS. That's a bug. Period. 2) There's zero room for "close enough to rock'n'roll". Apparently you don't seem to fully understand the concept of digital audio. If you were a math teacher and someone would resolve 1+1 to 2.0000000001, would you say "yeah, cool, close enough for rock'n'roll"? And when would you say it's not close enough for rock'n'roll anymore? At 3ms? Or at 5? Or at 10? In other words, you would base the decision on whether something is a bug or not on subjective perception? 3) I have posted examples how this bug could become an issue. Again, whether it's an issue for you is completely irrelevant. 4) I did not make a fuss. I reported a bug, plain and simple. It was you alone who started all the fuss about it.

Hi, I would like to be able to switch to path 2B "patchwide" (and merge it back in later), without Snapshots getting in the way. For all "normal" blocks (and hence switches controlling them) this is possible by deactivating "Snapshot Bypass". Now, I'm using Split A/B to route the signal to path 2B and control it with a footswitch by assigning it to the "route to" parameter. Works all fine so far. But: I haven't found a way to exclude this switch (or the "route to" function) from Snapshot Bypass. When I rightclick on the splitter block, I can exclude it from Snapshot Bypass (just as any block), but unfortunately, that doesn't affect the "route to" paramter. Is there any trickery to work around this (I only know of some ideas involving additional gain blocks - something I absolutely don't want as there's no sufficient space for them anymore)? Thanks in advance.

Jo.

Fwiw, it'd be even better if you had isolated tracks of tones you're after.

Could you record some bits of DI guitar, upload them somewhere and point me to some YT videos using a tone that you're after? I'm not a metal player myself but would like to take the challenge. I'd need a proper DI of a suitable guitar, though.

Try the global EQ. Yes, it's the best idea to tweak your patches at gig volumes and it's an even better idea to tweak them on a system as close as the PA/monitoring system you'll be using. But we all know that quite often that just isn't possible. That's the very moment to become good friends with the global EQ. Personally, I usually only use it for my own monitor and leave it to the FOH folks to adjust the sound properly for their needs, but in case that's not a viable solution, it's time to take matters into your own hands. The easiest way IMO would be to only use a broad (low Q factor) mid band and raise it. Mine sits there waiting to be used at something between 300 (or 305 as the Helix doesn't allow dialing in 300) and 700, usually I go for a rather low center frequency. In case that's not enough, add a high cut to taste, it's very easy to adjust. That's precisely what global EQs are for, so don't shy away from giving it a try.

Currently resorting my IRs, also, most of the preamp ones are still in Logics Space Designer format (converting them isn't much hassle but needs to be done...), but here's 3 kinda random captures of a Soldano SP77 preamp that I found to be useful. Even so much that I used them with my AMT Pangea to feed the return of a Laney LC50 combo on some gigs - yes, I prefered those undynamic IRs with some EQ and compression added over the Laneys preamp. So, just try them out - and if you think it's worth it, I'll happily post the rest of the bunch. I would recommend to use at least some EQ and a tad of compression along with them SP77_IRs.zip

Well, everywhere else in the recording world, record offsets are considered a pretty bad thing, especially as they usually come along with drivers that aren't taken care of too well.

I could think of several things.

Thanks - and yes, that's looking quite perfect. So it's a macOS/CoreAudio only issue as it seems. Nothing too surprising, I already had it the other way around as well. As said before, the entire issue hasn't got anything to do with latency (even if there's some overlapping elements that also relate to latency). Fwiw, we could happily discuss the various implementations of latency, the somewhat astounding aspects, side effects and possible workarounds for it one day. It's a topic I am very interested in since almost 2 decades already, I also performed certain quite interesting tests, the results sometimes being different from what I've expected. Might not be the appropriate place for such discussions, though.

Just to make this clear again: I didn't mean to make a big fuzz about the offset issue. It's just something that should be adressed at some point in time - and from all I know, these things can be adressed more or less easily, perhaps even without affecting anything else in the firmware (fwiw, the Axe FX IIIs interface part suffered from much more noticeable recording offsets when it was released - and I think it's fixed by now). It's as well something that some people would like to be aware of. And yes, it's very unlikely to turn into something that would get in the way of using the Helix as an interface too much, especially as there's ways to compensate for it once you're aware.

We could argue whether things are multiplied or not. It's nothing I would worry about personally (hence I didn't mention it...), but in case you'd route something out of the Helix and rerecord it along with other things, there's a certain chance of running into issues. Example: You route a dry signal into a hardware device to do some nice doubling effect (say, an Eventide H series device). When you then re-record the signal (to have it available straight inside your computer), the doubling will be 2ms off compared to the signal you were listening to when creating the effect. In case of a doubling effect, 2ms can pretty much make it or break it in terms of phase relationships. I'm not saying this is a very common thing one could do, but you'll get the idea. Regarding "This is not a bug" - yes, it is. Recording offsets defenitely qualify as bugs (well ok, you may call it lack of QA - but that's not all too different). And in some areas of the recording world, they would even qualify as major bugs and you wouldn't sell a single unit. Edit: Another example. You record a basic track 1. You record another track 2 along with it, using track 1 as a timing reference. You've totally nailed it, in the pocket and all. That track 2 will be off by 2ms compared to track 1 on the recording. You record another track 3 along with it, this time using track 2 as a timing reference. Totally naiing it, etc. Recorded track 3 will be off by 2ms compared to track 2 - and it will be off by 4ms compared to track 1. You get the idea. Does that happen every day? No way. Most often we may use a metronome or the tracks recorded first as our timing reference. But then, I'm just illustrating certain possible scenarios.

Hm, not sure if I understand what you're doing. Version 1) You're sending out a signal via USB Outs XYZ (shouldn't matter which) through one of the Helix' sends, then you reconnect it to the Helix' input (guitar input should be sufficient) and record it. In that case, the Helix should act every bit the same as it would when using one of the main outs. Without anything loaded, everything should function as on any typical multi I/O interface. Version 2) Or are you entirely bypassing the Helix' hardware and rerouting the USB "stream" internally? You know, the "hardware Send in Reaper" part is a little confusing - I'm not familiar with Reaper, is that a Reaper terminology to integrate additional I/Os or are you refering to the Helix' sends? Anyhow, in case you were bypassing the Helix' hardware, yet sort of emulating a hardware environment within Reaper by utilizing the additional USB routing options as kinda virtual audio cables, then your assumption might be correct. I am for now assuming that (2) is what you meant. However, whether the 90 samples in your example (which would match the value I've seen in opposite order) are "proving" that this is a defined value the Helix will have to report to the host regardless of platform is beyond me. It might as well just be coincidental. In case it's not a coincidence, it could of course tell us that the ASIO driver for Windows is in fact reporting the correct values to the host (which would be what you concluded already) so recordings are lined up properly whereas the Core Audio version comes with an offset. Could you do the same test I did, just re-recording something from the Helix' main out into the guitar in and compare things again? In case these recordings would line up properly, we should've nailed down the culprit, namely the Core Audio driver (which may or may not be of informational value for Line 6).

No. Sorry, I don't want to be a smart a** or anything, but please do yourself a favour and look it up. It's not DAW specific. It sometimes *is* platform specific (as there's different drivers for different platforms), but it's never DAW specific. Edit: And fwiw, yes, I have done cross-DAW-tests regarding that very issue in the past. Recording offsets are the same throughout.