SaschaFranck

You might want to record some bits and have a look at the sound in an analyzer. With acoustic IRs it's not unlikely that they will have tried to capture certain resonances and these might just be too much when used through monitors. Once you've found out about the offending frequency (or frequencies...), you may want to add a parametric EQ block, dial the frequency in and cut it out using a band with a narrow (high) Q value. Perhaps the 10 band graphic EQ will already be sufficient but for exact cuts a parametric EQ usually would be the better choice. Also: What kinda acoustic guitar are you using? In case it's a full bodied one, I highly recommend using one of those rubber feedback blockers that you put into the soundhole. Makes a huge difference when it comes to feedback issues.

Where and how do I do that? I only know you can rename the footswitch scribble strips in case you've assigned something to them.

Just fooled around a bit more with tap tempo. It sort of seems to measure the last 4 taps - but with somewhat "glitchy" results. Sometimes the tempo is just *way* off and sometimes it works. It's at least a lot more reliable in case I only tap twice - whereas more taps and an average measuring should give you better results, which doesn't necessarily seem to be the case.

Hm. I guess I wasn't aware of that and only ever tapped twice because of my POD/M13 experiences. Pretty strange I didn't notice this, though. Will instantly check.

First off: It's perfectly normal for players to compensate for latency, especially when you listen to the processed signal at volume (not even very loud, just decent) instead of "listening to your pick". So what you describe is a rather common thing. Still, latency and its implications is a rather complexed field. The amount of "human latency compensation" varies a lot, depending on tempo, style, sound, mood, listening volume, etc. So it's nothing to really rely on. Which is why you want the lowest possible latencies you can get when going the software monitoring route. Quite unfortunately, the Focusrites aren't really at the top of the latency race. In fact, by comparison, they're rather mediocre. Don't get me wrong, they're decent interfaces but for players aware of such issues, they're far from being ideal and possibly not made for software monitoring when "in the pocket" time is important (ideally it should be for every musician but let's not get into that just yet...). In case you're interested in numbers and possible alternatives for lower latencies, this Gearslutz thread should be the largest kinda database on the subject you will find on the web: https://www.gearslutz.com/board/music-computers/618474-audio-interface-low-latency-performance-data-base.html I know, it's horribly long but there's some updated lists and such. Alternatively, when it comes to the Helix, you may consider an HX Stomp. That would allow you to monitor through very low latency hardware while recording the dry guitar track, which you may then send into Helix Native. The most amazing thing being that you can use the very same patch you were playing on the hardware. For me, the combination of a hardware Helix (Floor in my case) and Helix Native is the most relieving thing I have encountered during the last decade (or so) of guitar recording. No latency issues, yet full access to each and every sound detail once I'm done recording. It really doesn't get much better. And I'm defenitely not a guy to just praise things without good reasons.

Seriously, post a small snipplet demonstrating your issue, post the DI guitar take as well and post the used preset. Fwiw, by default, the Helix' "master" out is recorded through USB 1-2, the dry DI guitar through USB 7-8 - and you obviously only need to use mono tracks with one half of these pairs as an input (unless you need to use stereo FX for this demonstration). With these things available, people will be able to analyze what might be going wrong in your patch and because there's a dry DI track, they may as well come up with possible "fixes".

Fwiw, I wish the high/low cut section for both cabs and IRs would be *way* more versatile. The slopes seem to be on the extremely soft side (something like 6dB/octave or so?) so when you turn them up/down as much as to really hear a change, they will already cut some "meat" off your sound. Personally, I really like the high cut of the Amplifirebox which comes with an additional resonance paramter. You can really "shape" your sound with that rather than doing kind of homeopathic adjustments. Pretty much the reason why I rather rely on my own IRs - with those, I can at least pre-shape their frequency content to my likings.

I haven't even played a single note of any factory preset so far, so I wouldn't know how they sound. And to avoid any possible dissapointment, I might just never load any of them. However, as far as presets sounding crap, I think that's a rather common thing. I mean, they're created with different guitars, different picking strength and what not. Which, btw, is also why I'd like to create my own default settings for amps and drives.

The only objective truth would be that Fractal has more amps on offer. You may or may not need them. Personally, I don't, but I wouldn't mind the CPU power of the Axe FX III.

Fwiw, at least on paper, a FRFR system should be able to sound pretty much identical to a typical guitar cab. But apart from the same dimensions and speaker directivity which such a system would have to deliver, the bigger problem would possibly be to get an IR (or another speaker simulation thing) without the microphone portion and the mic placement influence. I tried to manipulate a bunch of IRs while A/B listening through the real deal and some FRFR monitors. I got close enough to be fine (in fact, I even prefer it over a real cab) but it's definitely not the same.

Why wouldn't they? Have you ever listened to any recordings thinking "Wow, that guitar sound is great!"? I bet you did. Chances are that you've listened to the recording through what is at least supposed to be a FRFR speaker system of some sorts. Monitoring a modeler through such a system is no different from that.

See, @Nightsky1376, why don't you just post a snipplet of a tone you find offending, along with the Helix patch you were using? That would give us an idea of what you're talking about. I can only speak for myself, but so far I don't have the slightest clue. Ideally you'd post a DI guitar track along as well (it's extremely easy to record one simultaneously with the full Helix shebang) so people could try to find a solution. But without any audio examples, any complaints about audio quality (or lack thereof) are pretty much meaningless.

Nah, not really. Seriously, I have a bunch of baseline IRs and can make them work for pretty much everything by making "planned decisions", which is a whole lot different to selecting tons of IRs, which, instead of telling you "yeah, I do deliver more bitey high mids" are saying "Killerspeaker391-KillerMic725-CapEdge-2in.wav" - which, essentially, is telling you pretty much nothing (unless you're using it for the umpteenth time).

I don't know how familiar you are with sequencers (I assume at least somewhat as you own that Focusrite), but once you have a bunch of "baseline" IRs ready, IMO it's making a lot more sense to bake your own by mixing them (and finally exporting them to a single one). I do that all the time and the results IMO are great. In case you're interested, I'll describe the procedure.

Well, I was actually only mentioning the Zoom, not exactly recommending it (even if I own the smaller model). Thing is, if you really never exactly need software audio monitoring (or just occasionally), other interfaces might be a better choice. The Zooms are pretty good but support seems to be non-existant, so in case something goes wrong (for whatever reasons, but let's assume there's a computer OS update and the old drivers won't work anymore) you'll likely be out of luck. Also, there's defenitely better mic preamps on certain interfaces in that league (such as on the Audients, which are really sounding excellent), so if you need these, that might be something to look for as well. Personally, my next interface (in case I really need one) will likely be a used RME Babyface (first generation) as RME is known to support their stuff for a loooong time after they stopped making them.

Yeah well - I might even accept that. I mean, it's fine to complain about these things and there's certain Mr./Ms. Golden Ears around in the world. It's also that a top modeler should possibly suit their demands as well. Yet, even in case you need an audio microscope, the first thing required to start any kind of analysis would be something that you could actually put under that microscope. But there's nothing. All throughout this thread there's been no audio file posted. When I discovered something was really going wrong with the fuzz and certain amp models on the Atomic Amplifirebox, the first thing I did was to post my patch settings and an audiofile over at Atomics forum. And at least their main support guy admitted that there's something wrong (has never been fixed, but that's a different story) so I knew I wasn't hallucinating.

Here's a video of a guy usually prefering the Axe:

Why is it that the people complaining never post a patch and a corresponding audio example? Yes, there's certain sound related areas I'm a bit "wondering" about, partially some "sizzling" that I wouldn't describe as a common thing with real amps (perhaps the infamous squirrels), but it's absolutely rare that I notice it (only seems to happen on a handful of drive/amp combinations). In general, the sound quality seems to be just nice or great, sometimes even fantastic. I would ask everybody complaining to post an audio example along with a Helix patch. It's the only way to do explore what might be wrong and possibly find a cure.

I wasn't talking about massive corrections, but minor ones. And usually there's some of these corrections, mainly regarding the low end. Even if I trim that away myself already, FOH dudes sometimes like a bit more low cut - which I think is just normal and to be expected. If there had to be massive corrections all the time, I'd think about my patches.

I don't know whether it makes sense to start a new Ideascale submission as there's already plenty of similar requests, but the Helix (or well, HX Edit) IMO urgently needs a better way to deal with IRs. And while I may wish for more IRs slots (as many people seem to do) as well, I think a better IR management would already solve quite some issues. So here's a few suggestions (I may combine them into an Ideascale submission later on but perhaps someone would like to add to this little list and we could combine this into a single submission): - Patches should not load IRs based on the IR slot but based on the IR itself. That way, one could always re-organize the IR list, which would be a *huge* improvement already. I would usually place all used IRs on the top so I can mass-drag new ones in at the bottom and go through them via pedal edit while playing (which, fwiw, is a most excellent option to check out IRs and a very good reason to wish for more IR slots already). - HX Edit should be smart enough to find out which IRs are in use so you could throw unused ones out. - In addition to the previous point, HX Edit should be clever enough to show you all of the patches using a certain IR (select the IR on the left and get a list of all patches using it somewhere on the right). In case they're all bogus patches, you may want to kick them out and hence make place for more IRs as well. - There should be an option to "tie" IRs to a patch. When you do that and export such a patch, the IRs should be exported as well - and obviously they should be imported along with the patch, too. On import, the IRs used should be placed in the first free IR slots. In case there's not enough IR slots, a warning box should pop up. "Not enough free IR slots - import without IRs, yes/no?". One should of course always be able to "untie" IRs. All this could be done within the "Save" dialog (sort of similar to software samplers allowing you to save just the patch or the patch and the samples in one container). This entire thing (or any other sufficient method to solve the issue) might actually be the most relevant improvement for me because resorting patches and their IRs when dealing with a bunch of exported files is a nightmare. So far I only did that with very small patch amounts and it has been horrible already. You actually *need* to set up a text document for each and every patch, describing which IRs are in use in which IR block because the patch itself will only give the slot number away. In case a software sampler would deal with samples that bad, not a single person on earth would use it. . There could be a "favourite" or "tagging" system for IRs. Colors plus stars might be sufficient (green: great for cleans, red: heavy stuff, yellow: acoustic IRs, whatever you make out of it, the more colored stars, the better the IR). - There should be a search for doubles. Obviously, this should check for file names and checksums (or so). In case they're identical, there should be an option to compare the IRs in question. With such a limited number of IR slots, you don't want to waste any slots for doubles. - More IR slots. But in case the other issues would be solved, this wouldn't have a high priority for myself. In the end, I may never need more than, say, 20-30 IRs loaded simultaneously at any single moment in time, but with the Helix you need to keep them "just in case". That should be my most relevant concerns for now.

There's one thing I could imagine one could be missing, which would be the automatic selection of devices and activation of their respective knobs, which is only partially possible with the Helix (by setting "Stomp Select" to "Touch+Press") because it doesn't automatically alternate between devices. But I honestly think it's a minor deal.

What exactly would you like to achieve with that?

In all honesty: I would *love* such a thing. But my vote would go against it unless there'd be an option to *always* and instantly switch to a completely plugin-free setting that can't even be "seen" by plugins. Everything else IMO is asking for trouble at one point in time, especially in case you plan to use standardized plugin formats such as VST or AU - as you can't use them without at least partially integrating the OS they're using as well. In addition, if you really wanted a Helix/Plugin hybrid setup, that's pretty much possible already as you could simply use Helix Native, a powerful laptop (or something like a Mac Mini) and a decent low latency interface. However, what I could pretty much imagine is a better audio interface being integrated in the next Helix incarnation. The current interface is offering roundtrip latency values of around 7ms at 32 samples buffersize at 48kHz (and that's just a driver-reported value, haven't measured it physically, may do that later on), which isn't exactly shiny. Once the latency would be down to what actual great USB3/TB interfaces can deliver (which could be around as low as 3ms, possibly even lower at higher samplerates), it'd become a lot easier to integrate pretty much any computer into your setup. That way nobody would have to worry about whatever weird operating system related trouble as you could always just plug out and use the stock Helix things.

I don't think "truly flat" does matter at all. There's so many factors *way* more affecting our perception of sound than a speaker being a little off from true flatness.

You're missing the point here. I don't want to alter my presets to adjust for a different kind of FRFR situation. That's what a monitoring EQ is made for. As easy as that.