SaschaFranck

Fwiw, after all, I think if I was into looping a bit more seriously (which actually might still happen one day...), I would just buy a laptop or a 2-in-1 convertible. In case you're only using them for looper stuff, even rather inexpensive ones should do a decent job and you'd likely just need one of the light versions of Ableton Live, which can be had for peanuts. The additional advance being that you could as well use plugin-based reverbs and delays, so you'd even free up some Helix resources.

Well, we may agree or not, but I just find it super-important to be completely aware of the mess that is the current Helix IR implementation. And it's even more important to be aware straight from the start, because the later it happens, the more mess you'll have to deal with.

But honestly, it doesn't help the OP as apparently all he wants is to slap a preset (or maybe a bunch of them) onto a friends Helix - I'd say it's very likely that this doesn't include transfering a complete backup. Labeling your IRs with numbers doesn't help with this procedure, either, because the corresponding IR slot might be occupied already. Seriously, no matter which kinda workarounds there might be, the only way to really make sure a single preset (or basically anything apart from a full backup, which, fwiw, will also mess with the target machines global settings and what not) is 1:1 reproduceable once it's exported and reimported is to manually take notes of the IR(s) used. This is all I'm saying and in case you want to do such a thing, it's the single most relevant bit of information one should be aware of.

Sorry, but that is no fix but a workaround - and not a great one. I prefer to keep the original names of the IRs, so I can track where they were coming from. The Helix should be able to deal with long filenames (the last time long filenames were an issue in computer land was with Win 95) and it should reference IRs by name, not by slot number. That would be the fix. Besides, your proposed workaround doesn't exactly work anyway. Just export a few patches and IRs more than once. Ho to tell which IR starting with 071 a patch like "Great Lead" needs? Is it "071_combocab.wav" or "071_fullstack.wav"? So, you still need to manually write down all these informations, there's absolutely no way around it.

And it doesn't help at all with individual patches because it's a full backup. Something I most often don't want to do.

It's one of *the* worst limitations/implementations of the Helix. Because of that, once you move *any* preset or IR out of the Helix (be it for backups, sharing or whatever purposes), you *need* to manually take note which IR was used for each and every patch. And no, it really doesn't get any worse. Fortunately, firmware version 2.9 seems to be somewhat around the corner (which could as well mean it'd take another half a year, though) and the recent information says that the IR situation is at least somewhat aderessed as in patches now remembering the IR by name - we can only hope this will not break more things than it fixes. But so far, manual houskeeping is your only option.

Fwiw, not that I'd ever buy another one, but in defense of my EB volume pedal, I gotta say that this is pretty much built to survive Armageddon. I'm now owning it since almost 30 years already and the only thing I had to do was to change the pot once like 3-4 years ago. I don't think that's too bad for a pedal that has been the only one to make it onto each and every pedal board I ever used. The string mechanism, while seemingly strange when you first become aware of it, is actually excellent and is likely responsible for a lot of the pedals longevity. In addition, there's a reason for it to work that way, namely that the pedal can make use of the full 270" the pot provides, something most other pedals don't. Now, all this is completely irrelevant with an expression pedal that can usually be calibrated inside whatever software, but for a pedal with audio flowing through it, built quality of all parts is quite important.

Yeah, sorry for any potential confusion, that's what I meant. I'm doing it pretty much the same, IMO most Helix wahs are quite too harsh in toe position. Thing is, at first I started pushing Low Fc up as well, so I would get a similar overall range as with my Dunlops, but after a while I discovered that I actually never go "all heel" with the Helix pedal when doing wah things but rather use the same pedal travel range as with the Dunlop. So I just keep Fc Low pretty much down and can now enjoy a bit more wah range in the lower register whenever I feel like without compromixing "normal" operation. Yeah, I never got the horrible prices for volume/exp pedals, either. I still love my EB volume pedal, though, IMO there's nothing that feels better while using it. However, I had to replace the pot once - and boy, what a nightmare to get all that string thing re-adjusted properly. Well, not a nightmare but still as far away from userfriendly as it gets. And it was more expensive than a new one of these M-Audios. Guess I may just order one. I will only use it for certain additional tasks anyway (such as delay manipulation) and keep using the onboard one for wah/volume. I don't exactly need any "cocked wah" sounds, so permanent wah access isn't relevant. The only thing I wish was that the Helix would remember the wah/exp switch throughout snapshots, which it unfortunately doesn't ("snaphot bypass" can't be set for the EXP 1/2 switch).

What about the pedal range on these? Personally, I find the pedal range of the internal pedal to be absolutely perfect for my needs (even with wahs, which required a bit of getting used to and some wah block adjustments but astonished me no less, being used to the Dunlop range since decades - now I actually enjoy the additional range that I'm getting towards heel position), so I'd really like to have at least a similar range for an external pedal. From the picture, the range looks pretty small, but I really can't tell. Also, does it have enough friction? I have an old-ish Boss pedal that simply moves way too easily for my taste. I really like a little more "solid" feel under my feet. The best solution might be modding my EB volume pedal, IMO the best pedal for all things swelling and what not - but that one is just horribly heavy, modifying isn't all that easy, either, and I'd also just like to keep it for other purposes.

From all I know, the headphone volume knob has a plastic shaft, so there's pretty good chances it could break off (and I've just seen pics of that to happen like a week ago).

No, I'm not. I was just using 5ms as a comparison value that most people seem to get along fine with. In a nutshell: While I do understand that people aren't fine with 10ms for software audio monitoring (I'm in that camp myself), I don't exactly understand why 5ms would be a too big deal when dealing with virtual instruments (which *is* what we're getting with the Helix). Now, maybe for some keyboarders with a good sense of time, it might be too much already, especially as we'd have to add possible MIDI (or MIDI-via-USB) input latency on the way in, but that's a sort of different issue (and likely the reason why Phil was asking). I could pretty well imagine how playing pad things like Machine would become a critical thing - even if you can get to 5ms audio output latency (which, fwiw, is not exactly possible to measure properly, so once it comes to those numbers and the division into input and output latency, others than with RTL, we have to believe in the reported numbers), when you add just 2-3ms MIDI input latency, things may start to feel somewhat distracted, especially under headphones. Fwiw, for me, when using headphones, something between 5ms and 7ms seem to be the values when I start to feel things. When using my Zoom UAC, playing any really bone dry clean amp patch, I can usually reliably detect the difference between 32 and 64 samples, hence the difference between 4.5 and 5.9ms of latency (had a mate switching buffersizes a while ago, so it was a blind test). But I can *not* as reliably detect the difference between 5.9 and 8.8ms (the latter being the result of using 128 samples buffersize). Without headphones, the numbers vary. With a tad of room/ambience on the patch, the numbers vary again. Once overdriven sounds come into play with all their smeared attacks, it's yet again completely different. A little OT, but not really: In addition, all these are just "feel" things. In raw listening tests without any direct physical or audible references, I don't think I could reliably detect 10ms - and according to some tests I once conducted during a sequencing workshop I was holding at the local music university, very few people can. Fwiw, for these tests I used the most simple drum pattern, kicks on beats 1 and 3, snares on beats 2 and 4. both samples were cut straight at their transient peaks (rather than at zero crossings) and I then applied various amounts of positive or negative delay to the snares (all rendered into audio files so any potential sequencer playback issues could be ruled out). It's been a long time ago already and unfortunately I never grabbed the sort of documenting text files from the universities computer (hasn't been an all too scientific test anyway), all I safely remember was some drummers being quite astonished at their abilities (or lack thereof...) to spot offsets in a significantly better fashion than other instrument players. In fact, the most stunning guy was a keyboard player who would detect 10ms offsets all the time, as long as the BPM would stay the same. Oh, obviously, there's been no hihats running along, so the delayed snares were rather isolated, the only thing to reference to being the BPM "pulse" that you'd had to kind of internalize. Having said that, I rendered the beats at different tempos, and quite obviously, at very slow tempos, it was a lot tougher to detect any offsets for all of my "contestants". Also, when I was switching between BPMs quickly, such as between 70 BPM and a negative snare delay of 15ms and 130 BPM with a positive delay of 10ms, the results were reliably all over the place, even with the mentioned keyboardist. In other latency related listening scenarios, yet some other things come into play. With a band it might be optical clues, with stereo files it will be levels (there's quite some interesting reads about the Haas effect around), etc, etc. Fwiw, when recording vocalists, using *higher* buffersizes for audio monitoring sometimes is preferable as very low latency values will cause irritating phasing issues between their "skull listening" and the phones, whereas higher values may result in a kind of chorus-y doubler effect that might even be pleasant to listen to. Guess what I'm saying is that there's really lots of implications coming along with various incarnations of latency. And fwiw, all these are responsible for one of the reasons I went with the Helix, as I can always monitor at more or less fixed latencies while still having complete re-amping freedom - which, unlike with any other modeler, includes using Helix Native, allowing me to get 1:1 what I'm monitoring or just some slight variations. Impossible with any other contender unless you go for realtime re-amping.

Hm, so how would playing virtual instruments with 5ms latency be different from playing guitar through a 5ms RTL chain? I mean, that's what pretty much most folks are getting along with just fine and the Helix does deliver around that value for virtual instruments.

Ok, possibly a daft question, but: How is this much different from using a match EQ? Yes, I am aware of an EQ not doing any time based things whereas IRs also capture the "time structure" of whatever it might be - but in the case of 2048 maximum samples, shouldn't that be largely irrelevant in this case? And yes, I know it's not exactly irrelevant when dealing with cab-IRs, but in this case, it should likely be of very little relevance, especially given that the typical differences/issues in the dynamic behaviour of a piezo compared to a mic'ed signal (which are also happenin in the time domain) can't be adressed using this method anyway as, in the end, you'd still be dealing with the piezo as the source, so all that can possibly be done would be a sort of pretty "intense" EQ-ing, something a match EQ should be able to do as well.

Well, of course you're right, but I was only talking about using it strictly as an interface. Compare it to, say, an Apollo. When you switch off the plugins running on the unit, they're completely out of your way. All routings and what not should be taken care of by the inherent safety buffers, so all processing should be able to take place within these boundaries.

Ok, as you bring this up: Right now, pretty much all interfaces delivering substantially lower RTL values (and stable performance) than what we get from the Helix cost a rather significant amount of money. I own a Zoom UAC-2, from all I know, regarding latency, it's still the best in its league, it's the very reason why I bought it (fwiw, 4.5ms at 32 samples, 5.9/64). We're talking the league around 200 bucks here. But it's only stereo I/O. Now, with the Helix, we have an 8 I/O interface under the hood. There's a Zoom equivalent for that, too, the UAC-8. Comes in at around 600 bucks already (ok, it also has 8 mic preamps). Next thing to up the game in USB-interface-low-latency land would be an RME Babyface Pro already. Now we're at <700 bucks already. So, seriously, what can be realistically expected to be thrown in with the Helix, especially given that a lot of "non-core" hardware elements (and even some core ones) aren't exactly top quality already, either (sadly enough, sometimes it's even the opposite)? I would defenitely not expect anything better than Behringer and the cheaper Forcusrite, Steinberg and what not interfaces. And obviously, the driver needs to be built around the various routing options, which might not be a trivial task (all the cheaper interfaces don't offer anything even close to the Helix' routing options). In a nutshell, while I think it might be possible to somewhat improve the Helix' RTL performance, I don't think there's all too much to gain. Maybe 2ms or so. Which would still not take us into the real low latency range, so it'd still not be possible to use HX processing plus software monitoring, it'd possibly also drag you over the "latency acceptance" cliff once you'd be using any plugins coming with their own latencies (such as the PRS plugins from Waves), etc. Now, I'm not defending Line 6 for the quality of the interface of the Helix, I just think it's unrealistic to expect something noticeably better.

Fwiw, not that I'm happy about the Helix' latency values when used as an interface, but I find them to be pretty much acceptable for anything but software audio monitoring. IOW, playing virtual instruments really isn't exactly problematic (in this case, interface latency only kicks in once, on the output side of things). Furthermore, I think super low latency operation isn't exactly something one should expect from what basically is a hardware modeler and not a dedicated interface. Anyway, I just wanted to share something that I'm doing all the time (and for a long while already, too). Even if I'm not going for full stop software monitoring, I still use delays and reverbs coming from plugins all the time while tracking. To make this work all you have to do is to mute the dry signal somehow (in Logic I'm using a dedicated track and have it set to "no output") and only monitor the 100% wet returns of whatever reverb/delay busses that you're feeding your input channel into (most likely via sends). Can be done in a number of ways, the only important thing being that you completely mute any dry signal - you're monitoring that through the Helix. As far as those additional 10ms of latency go, they really don't matter too much on reverbs and delays. I usually have some predelay on most reverbs anyway (to avoid mud), so I can just pull that down a bit, should it really matter. This really works a treat and I'm using the same approach in my "normal", Helix-free recording environment for almost 2 decades by now, saved me from keeping the old rack FX for monitoring pleasure, even with less powerful computers and/or cheaper interfaces not allowing for full stop software audio monitoring. Fwiw, because this is working so well, my current plans are to purchase one of those nice 2-in-1 convertible laptops somewhen this year (doesn't even need to be a high end thing such as a MS surface, so far I'm looking at some Lenovo Yogas, but I'm not in a hurry, so I'll keep looking around for a while). I will run whatever kind of VST plugin host on it (maybe Gig Performer, maybe Bidule, maybe just Reaper, don't think I need a high end solution) and will finally be able to use things as the glorious MFM2 delay from U-He or Native Instruments Raum plugin or even some IR based reverbs live. This will as well free up a considerable amount of resources on the Helix and with the new switching options apparently coming with 2.9, controlling things from the Helix shouldn't be much of an issue (it shouldn't even be with 2.8). As a bonus, I will have access to HX Edit all the time. That'll be quite some fun.

Run some white/pink noise through the Helix (Logic has a test tone generator). Simply use one of its outs to feed the input. Use exactly no blocks. Monitor that signal on USB 1/2. Find out whether the noise is still the same or whether it's altered significantly compared to the noise as long as it stays inside Logic. This test is set up in a matter of 30 seconds and will instantly end all speculative suspections.

All these are irrelevant for plain audio interface functionality. Using, say, RMEs Totalmix software doesn't affect the latency of their devices, either.

Ok. Under OSX there's no way to set the driver lower than to 32 samples (only works in class compliant mode anyway) - so it's perhaps a rather experimental setting achieved through a Windows driver or ASIO4All. However, as Jim Roseberry pointed out, there's pretty much zero chance the unit would run even remotely properly at anything below 32 samples - and even at that value, it was already causing a lot higher CPU hit under OSX, compared to 64. And even if it was running at lower buffersize values, my tests indicated that there's been a rather high safety buffer at work (very typical for cheaper interfaces), so from one point on, lowering the buffersize in your host results in diminishing returns as that won't have any effect on the safety buffers (and converter latency, too). In a nutshell, 3-5ms simply isn't realistic, likely not even happening at all on those Behringer interfaces.

Yeah, I know. Fwiw, Jim really knows his stuff. I know him from pretty much way back in the days when mailing lists were still en vogue.

I'm allowing myself to answer your question from TGP here. The answer is: No. And those 3-5ms the one guy is claiming are an illusion, no less. Maybe some host will report such numbers, but they're wrong. How would I know? Because I had one of those Behringers over here for a testride (a mate bought it - but sent it back after some tests at his and my place). 64 samples buffersize might work glitchfree in case you don't tax your computer hard, but that still depends on your host as well (with Logic it's trivial - but Logic is still one of the best in terms of balanced low latency performance) and you will likely not enjoy it too much on an i5. Fwiw, from all I remember, I got around 8ms at 44.1kHz and 64 samples buffersize. Not all that bad for a €60 interface but defenitely not that great, either.

Yes. There's stereo DI boxes, too. Still, you may not need any of that, especially in case your cable runs aren't too long.

In that case, I'd get a DI box for those "just in case" monents. They can help you with all sorts of noise issues and at 10 bucks or so (for an easy passive one) you really can't go wrong.

Oh, you didn't mention it was the HX FX we're dealing with yet.

He would have to use the TS outs in that case as well. And fwiw, loydall, why don't you use the XLR outs? The signal should be less prone to noise interferences.