SaschaFranck

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.

And fwiw: The global recording offset compensation of some (these days most) sequencers hasn't exactly been added to compensate for offsets introduced by less than shiny interface drivers but because you might be dealing with things the driver of whatever interface can't adress, such as using an external AD converter. The latency introduced by such an external converter is something unknown to the interface, so the only way to find out about it (apart from things being documented by the converter makers) and cure it, is performing a loopback test and adjusting your global offset compensation. In case of an interface coming with a fixed set of converters, that shouldn't be required. Anyway, I didn't even mean to start a discussion about all this. Just wanted to report this driver bug.

As said, this has *zero* to do with device latency, be it from converters, internal processing or whatever. It's about a recording offset - which is an entirely different thing. One of the most crucial features of an audio interface is to record things in time. For this to work, the driver needs to communicate with the host. And in case, say, the input converter is adding 2ms of latency (arbitrary number, I know it's less on the Helix), the driver needs to tell the host "Hey, please take that into account when placing the file on the timeline". Same goes for any internal processing the Helix is doing before the signal hits the sequencer. This is what each and every even remotely professional (or semi-professional) interface will do. If you have access to one of these, you can check for yourself by perfoming the dead simple loopback test described above. They're "suffering" from the very same converter and processing latency as the Helix (sure, the exact numbers will vary as they're all designed slightly different) - and yet, recordings will be placed accurately on the timeline. The reason being that the driver is properly communicating with the host (well, on most interfaces at least). It's pretty much exactly the same what I'm now doing with Logics global recording offset compensation, just that it's happening on a driver level, which a) is likely more efficient, b) takes the burden off the user and c) doesn't need re-adjustments when changing samplerates (which is often required with interfaces suffering from that very issue). Fwiw, these very issues are something often ignored in all sorts interface reviews. You may find resumes about how great an interface performs at low latencies, how great it sounds and what not - only to find out it comes with a massive recording offset once its in your hands. Which, btw, isn't necessarily a dealbreaker, as long as the offset isn't varying (something happening as well on rather shoddy interfaces), but it's still something that shouldn't happen. It's a matter of proper QA in the driver development department and should be adressed.

Well, as the lack of proper driver communication is known by most host makers these days, quite some of them are offering a global record offset compensation. Once that is done, you're all fine. I'm using Logic and after measuring the Helix offset, I just set the global compensation to -90 samples and that was it. It's just that I have to remember it whenever I switch to another interface not suffering from recording offsets (would be great if the host would remember the settings per interface). In general, it's quite astounding, though, because even some dedicated interfaces are still suffering from that issue - let alone those slapped in as a sort of afterthought. The one in my Zoom G3 comes with a recording offset of a whooping 475 samples.

Just fool around with some EQs and see how far you can get. You might want to throw in some light compression (with shorter attack values) behind them to sort of simulate the sag of a typical tube power amp. Fwiw, I have a bunch of IRs taken from clean tube preamps and full tops. Now, as these are IRs, they won't reproduce the dynamic behaviour of the captured amps, IRs just can't do that, but they're introducing some interesting frequency responses that you won't be able to recreate with any EQ. Let me know if you'd like to try them out in the HX FX IR block and I'll post them.

Personally, I don't fear the Helix to be obsolete at any time. Good sounds and proper usability won't become worse all of a sudden. A Marshall amp is as outdated as it gets, so is an acoustic piano - and still people are using them all over the world. At least for me, there's a huge difference between earlier modelers. Their sounds would indeed become outdated because pretty much everything (at least out of the things I've tried) left something to be desired (or even plenty of that). With these days modern modelers, for me that's not the case anymore. IOW, I can get some sounds out of them which I don't need to be improved anymore. Sure, there's always the one amp or pedal that you might want to have included, there's better FX algorithms and usability improvements. And it's not unlikely that you may want these in your hands and hence buy a Helix V2 one day. But that still doesn't mean the current Helix will become obsolete - unlike, say, my Boss GT-5, GT-10 or my old POD units, which are simply outdated because of their sound. My biggest fear is that the Helix hardware will not hold up too well, it's just not as heavy duty as I wish it would be (in fact, it's even sort of fragile on some parts).

And fwiw, that SOS article is pretty dated and not exactly well written. The guy doesn't even mention the socalled "safety buffers" each and every interface will introduce. These exist to warrant proper functionality and they're usually not documented, plus, apart from a few rare exceptions (I know MotU offers low safety buffer options - which doesn't seem to help their interfaces, but that's another story...), you can't access their settings as a mere user, so they're baked into the interface. And quite often they're responsible for a large percentage of your overall RTL, especially on cheaper interfaces. Which is also why you will get vastly different RTL values from different interfaces, even if you're using the same samplerates and buffersizes. The SOS author is not mentioning this, which is a bit of a shame, as SOS usually is a pretty reliable source. In case you want some extensive but interesting reading, I recommend this thread: https://www.gearslutz.com/board/music-computers/618474-audio-interface-low-latency-performance-data-base.html Anyway, it still hasn't got much (if anything) to do with the recording offset the Helix introduces. That's all about proper host-driver-communication.

Very sorry, but you don't seem to understand what this is about. It's a recording offset. Interfaces are supposed to record the stuff coming in and have it placed on the timeline in a sequencer just at the right position. This is all about proper communication of the driver and the recording software and it's got zero to do with latency (which I am absolutely informed about) but with a proper driver implementation. Any decent interface doesn't suffer from this problem. And while most humans won't be able to detect 2ms od delay reliably, it's good enough to cause other issues, such as phasing ones. Anyway, this is very clearly a bug on the interface side of things. And as said, it's got nothing to do with latency. My other interfaces don't suffer from that issue, regardless of their RTL values or the buffersize settings. As far as testing this goes: Play any audio file in a sequencer and re-record it. Then compare the two signals on your timeline. Ideally, they would align perfectly, regardless of the samplerate and buffersettings. Which they are, using other interfaces. Which they aren't, using the Helix. Hence it's a bug. One that should defenitely be adressed in case you want to call the interface part of the Helix decent.

That's why each and every halway decent PA (these days even including cheaper ones) have dedicated delay lines for each array of speakers. The front speaker will be virtually pushed back a few feet until they're at stage distance, using these delays. Works a treat.

Helix Floor as an audio interface causes a negative recording offset of 90 samples at 44.1kHz on USB 1/2 or 7/8 (empty preset, but that shouldn't matter). So all recordings will be delayed by around 2ms. Some (maybe most by now) sequencers allow for a global compensation of such offsets, in case someone cares and wants to look it up. Should be corrected on a driver level by Line 6, though.

You can't do that. In my own layman terms: Different blocks have different DSP requirements and would likely cause a "re-calculation" of things, which would be counterproductive to the nature of snapshots, which are there to allow for instant, gapless switching.

Having to turn a unit off to avoid possible damage just to connect a mic is ridiculous. If that was like a recommendation for a mxing console, you'd sell exactly zero units. As much as I like the thing, it has to be said that the Helix suffers from absolutely serious hardware issues/flaws, there's no way around it.

You need to set the Helix as the device for system audio. Alternatively, the player you're using will have it's own setup menu in which you might be able to select an output independently from your system audio settings. Quite obviously, you want to chose the Helix there. Don't change anything on the Helix just yet - it'll usually play back things fine at its default settings. The fact that your backings are playing through your laptops speakers/headphone-outs indicates that the Helix isn't assigned properly there.

Yeah well, my comment was a bit quick-handed or so. Yet, there's such an amount of flexibility when it comes to amps delivered with the Helix that I could hardly think of much sounds that you couldn't already realize in one way or the other. Ok, admittedly, I'm as well having a sort of an issue with people asking for more and more of the same stuff over and over again (the amp requests on Ideascale are about endless). Personally, I think it'd be much more interesting to have some more wicked options available - and amps are, well, defenitely required but completely boring, so I'm not getting excited about them at all. Anyway, it's all fine if people are asking for amps. It's just super boring in my book.