SaschaFranck

Fwiw, even if what merdenoms74 describes might not be digital clipping, it's pretty tough to keep track of levels inside the Helix (which is a wellknown thing). Quite strange that there's not any kind of level indicators at least inside HX Edit - I mean, HX Native has two of them already. I don't exactly have a problem with levels but there's a slight tendency for my patches to become louder and louder the more I tweak around - which is kind of a normal thing as we seem to perceive louder as better pretty often. As a result I usually have to wade through them once I'm almost done, checking all the important levels. In case there were proper level meters, I would run into these issues less often.

Fwiw, I am not someone arguing for the sake of arguing, but I am honest. And most of the time, I'm pretty well informed regarding the subjects I'm talking about. Hence, I may appear as a tough guy to discuss with. Some people (especially those from the other side of the big pond) seem to think of that as arrogance. Might as well be a language issue (I'm german, english is just something I have more or less learnt in dubious ways). In the past, I have even been a victim of some cyber bullying (or stalking, if you will) because people couldn't deal with it. There's been one particular person who took things as far as it gets (so much that I considered legal actions, would've been a very expensive endeavour, so I just couldn't do it...), which, fwiw, ultimatively resulted in my permanent ban from TGP (you might remember me from there). I won't elaborate on this any further right here - if you're interested in whatever wicked details (and it's really a strange story...), drop me a line. I'm just mentioning all this here because I'd like to make clear that I hardly ever take something personal. I may sometimes be pretty tough to deal with in discussions, but that's largely because I've been through all that so often that it's getting tiresome here and there (just as with the entire latency thing which I have been exploring left and right around almost 20 years ago already, back when there were still mailing lists and usenet groups). I still don't take any of this personal, regardless of how much we may disagree about certain things. It takes a lot to really wind me up in a personal way. Ok, enough of that, cheers!

I don't think *anything* would have to be changed on the Helix itself (as you can't slap IRs onto it and rearrange them others than by using HX Edit), it could all be done solely in HX Edit. And given that IR management is done properly, I would very likely never ask about more IR slots, either. Right now I would only wish for more of them because you need to keep all kinds of IRs "just in case" - as some arbitrary patch may need them.

I actually have no idea what would be the best way to skin this cat, but I can safely say that I'd be fine if it'd require to keep my entire enchillada of IR folders around for the rest of my life, even if it was just for 37 Helix patches to work properly in some years to come - simply because I backup all my IRs since years already in all their glory and keep them on each and every computer anyway. But I'd feel better if I could just have the required IRs next to my patch. Whatever, it's really not so much about how IRs are backed up, it's much more about how HX Edit (or the Helix) deals with them. I'm sure I could always find the required IRs somehow on my harddrives, but it's a lot tougher to find out which IRs are required by a patch - and in case you a) didn't manually write a note and b) erased or re-ordered the internal IRs, there's absolutely no way to find that out ever again. Exporting IRs wouldn't even have to be changed. I can do that manually, it's a bit more work but no big deal. Importing and re-assigning them is where the drama starts.

These are no bad values for a sort of aging interface at all. Yet, one of the reasons I'm so happy with the Helix would be that I just don't have to worry about all of these things anymore, even if my interface allows for lower latencies. We should keep it at that.

I am not going to continue this discussion with you, @rd2rk. There's nothing worthwile to discuss. I'd rather spend my energy thinking about decent solutions regarding the IR management situation.

See, I have thought about this quite a bit (especially as it has been raised again and again, even just in this rather short thread), I even stepped back (for other reasons as well, but still...) from the idea of perhaps having IRs embedded in a patch file. I think the percentage of illegally shared Helix patches and their required IRs would perhaps raise by 0.0001% or so (ok, it might as well be 0.001%), simply because exporting IRs from the Helix is as easy as it gets already. If one wanted to do something against this, the best way would perhaps be to not allow any IR export from the Helix - and believe it or don't, I'd be perfectly fine with that. All the IRs I need are on my drives already anyway. And I can keep gazillions there and back them up for the rest of my life as well (these things are just too small to worry). Basically, all I want is HX Edit to tell me "You need "GreatIR_01.wav" for this patch to work - can't find it in the internal memory, search drives for it, yes/no?" And in case the internal memory would be full already, I would like it to continue with "Insufficient storage space for "GreatIR_01.wav", want me to look for unused IRs, yes/no?", obviously followed by a dialog allowing me to delete any number of unused IRs. And then, as the final option, in case there's no unused IRs anymore, I'd like HX Edit to show me which IRs are used by which patches, so I could probably find some that I could delete manually.

You obviously don't understand that my proposal makes *no*, *zero*, *zilch* of a difference in terms of sharing IRs. And *if* IR providers had a problem with all that stuff, they would already have the problem. What I'm suggesting doesn't change anything. It's not even remotely required to discuss that any further in this thread. You raised an issue that simply isn't an issue. For nobody.

Absolutely that! I was just using the example of sharing patches as an example as it demonstrates things (or rather their shortcomings) in the most obvious way. But the same things apply when you keep backups and what not strictly for personal purposes. I haven't even thought about any legal aspects because they're irrelevant in this case. If someone wanted to illegally share some IRs from the Helix (not even considering the fact that they're stored on your computer already anyway), as is, it's a one click affair (export function in the IR list). With my proposed improvement, all that would happen is that a patch file would be saved as well (and that clearly isn't relevant as far as legal aspects go - sure, you could share a commercial preset, but let's please not open that can of worms...). Another one click affair, same legal risks as before, no less, no more - and certainly no reason to even discuss this. All I want is to be able to load a patch properly in 10 years from now (maybe on a 3rd Helix hardware revision, whatever) without having to look up whether there might be any informational text files around, telling me which IR I would have to use. Textfiles that I would have to create manually in the first place - which would be the next thing that I just don't want to do and that simply shouldn't be necessary. Also, look at it that way: With my proposed improvement in terms of IR management, it'd be a lot easier to deal with the limited amount of just 128 IRs (I know, for some people it's more than enough, for other's it's not - each to their own, shouldn't be part of this discussion). You could just freely move any number of IRs out of your Helix at any time to "mass-check" a new IR library at once (which works extremely well in case you can place them all straight after each other so you can go through them in pedal edit mode) and easily move the temporarily removed ones back in after that as the patches requiring them would instantly find them, regardless of the slot you load them into. With the proposed functionality of HX Edit telling you which IRs are actually used by whatever patches (or better: which are *not* used), things would get even better because it'd make it absolutely trivial to get rid of "orphaned" IRs. IR housekeeping the easy way. Whatever it might be, as said, pretty much any improvement would be welcomed.

Yes, I can. What I suggested would make *zero* difference in terms of easier or harder IR sharing. Zero. Hence there's no differences regarding the legal aspects, either. It's something you don't seem to understand - and hence part of the reason why I would prefer to not discuss this very issue any further.

I wasn't talking about you but about the FR employee who seems to rely on Reapers driver menu reports.

As said, legal issues are a non issue in this case. Anything that could be abused illegally could happen just as well with the current IR implementation. What I'm suggesting isn't making it harder or easier, so it's simply not required to make this minefield a part of this discussion.

Sorry, but without physically testing, you can't say for sure there's a tiny difference. And with certain interfaces, the difference is huge.

I have no idea how Customtone treats anything, it's none of my business. I won't buy or sell things there, either (ok, well, who knows, never say never...). Anyhow, what I do know is, if people want to share stuff illegally, it's gonna happen anyway (and it's not gonna happen on Customtone for sure) and you have to adress it at the source. But as said, all that is none of my business, all I want is to be able to keep track of my patches and their corresponding IRs for my own sake. Oh well, I would happily share my own IRs with anybody as well, I have zero financial interests regarding those (even if I think some of them are quite great, especially for the live playing folks). Whatever, I'd prefer to not talk too much about whatever legal side issues anymore. Been through that debate (at least regarding "normal" samples) a lot of times and it's tiresome. And as said, I also don't think legal issues are part of the reason why IRs are treated this way in the Helix (especially since you can share them as easily as it gets should you feel like). I would really only be interested in how this can be improved for users who want to use IRs in multiple ways and keep track of things. And I'm pretty sure I'm not the only one interested in that.

See, this is not at all about spreading IRs. This is about keeping track of *my own* patches. Really, it's every bit the same as with softsamplers. And I don't think Line 6 treated IR management that bad because of legal issues.

No, I'm not a lawyer. But it's absolutely irrelevant whether you can export an IR in one step along with a patch or whether it'd take two steps. And yes, I know that much about the laws behind sample copyrights (which is essentially what an IR is, a sample). And fwiw, I hope they won't add any encryption. It's not necessary anyway, unless IR theft is a serious issue (which it might be or not, I wouldn't happen to know).

Well, I am not saying that I "hear" the difference between 4.5ms and 7.9ms (the numbers I'm getting out of my Zoom UAC-2 at 32 samples and the Helix at 64), but when using headphones, I "feel" the difference with my picking hand. Reliably that is (would happily take part in an ABX blindtest). I know about most of the physical implications (such as 10ms being equal to a distance of just 3 meters, how things might be entirely different for singers as they may run into phasing issues with very low latencies, etc...) and I've read the AES paper long time ago with great interest. And I also know about many (as in "more than you'd think") drivers not reporting the interface latency properly to the host. I have been building and configuring audio workstations for a good while, so checking things such as latencies and recording offsets (another thing many interfaces suffer from) was more or less 101 to me. Which is why it's a bit astonishing to see that some Focusrite employee seems to be trusting the driver values reported in Reaper. Not that they're necessarily wrong, but the only way to make sure they're right is by measuring things physically.

I'm using the input blocks gate to adjust the patch in use (I usually just use one patch per gig) according to the situation. Sometimes there's noisier enviroments (light interferences and such), so it's nice being able to get rid of a portion of noise as close to the source as possible. And I usually switch on another gate simultaneously with other things introducing noise. I usually don't need to touch that gate once the patch is done.

Regarding the IR licensing issues: There'd be no other issues than those that are existing already. Whether you export an IR manually or whether HX Edit would do it along with a patch is making zero difference regarding any legal issues. If at all, Line 6 would have to come up with an encryption scheme, such as what Native Instruments is offering with Kontakt. And well, re: artificial intelligence: I haven't even been thinking about anything like that. All I'd like to see is HX Edit telling me which IRs are in use or not. Plain data management. Any "delete" actions would still be entirely in your hands.

https://line6.ideascale.com/a/dtd/IR-Management/967324-23508?submitted=1

Idescale: https://line6.ideascale.com/a/dtd/IR-Management/967324-23508?submitted=1

Fwiw, I wish this wasn't a global setting but could be (ab)used per patch. I could imagine to use the authentic delay adjustment sound creatively - but usually I prefer the "transparent" setting.

Before I start, to avoid any possible misunderstandings, let me make clear that I absolutely love the Helix. As a result, anything I'm saying isn't to badmouth the unit or Line 6 or their programmers, it's solely in the interest of improving the Helix. Ok. The Helix needs something to organize/manage IRs. As far as the status quo goes, there is literally nothing (!). Yes, you can load IRs and you can export them. And that was about it, nothing else to see. This is absolutely bad. In fact, considering all kinds of organisational aspects, this is by far the worst area in the Helix. It's so bad that there's good chances of "data" (=patch) loss. Which IMO isn't acceptable. Fwiw, all this hasn't got anything to do with the amount of IRs you can load into the Helix, it's just as bad when you use just 10 IRs and it'd very likely become a nightmare in case we could use, say, 1000 IRs. Let me illustrate things using an example: If I would post 10 patches, each of them using 2 IR blocks and I'd also post the 20 IRs used for those patches, you would very likely *never* be able to recreate the patches as they were meant to sound. The IR blocks within the patches would only tell you which IR slot was used (and load whatever might be there on your unit). There's absolutely no further meaningful connection between a patch and IR. So, if you wanted to load my patches properly, I would have to explain which IRs would have to load in which IR block. That already requires me to look it up before exporting them and write it down. It would also require you to find a free IR slot on your unit, place the IRs there, load the patches, read my instructions and set the IR blocks accordingly. Ok, now let's compare this to a softwaresampler patch (yes, it's absolutely comparable, it's software that has to load samples in some sort of "slots" to deliver reproduceable results). I could send you 10 Kontakt (software sampler from Native Instruments) patches using 2 samples each and I could as well send you the 20 samples used. Once you load the patches, Kontakt would ask you about the samples. You'd point it to the folder where you've unzipped them and Kontakt would load them (you could even tell it to do a systemwide search if you wanted). Done. And that is precisely how things should be dealt with. There needs to be a direct connection between a patch and the IRs it's using. As a result, HX Edit would have to tell you an IR was missing when you try to load the patch and didn't load the IR before. It should also be able to re-assign the IRs needed on it's own and ignore any IR slot information. And it should also be able to find out whether the required IR would already be loaded in one of the slots, to avoid doubled IRs. Very obviously, HX Edit should as well allow you to export an IR along with a patch (exactly the same way that software samplers do it), not embedded but next to it inside a folder called "Cool Rock Riff IRs". In addition, it'd be great (and possibly easy to code) if you could check whether and how often each loaded IR would be used in patches. In case it's not used at all - fine, just clear it to have some more IR space. In case it's only used on patches you don't care for anymore, export all these, delete them and the IR as well. Whatever it might be (as usual, there'd be more ways to skin this cat), everything would be better than what we have at the moment, which - well - is nothing.

Amen to that. There's some FX types (and even amps) where it's more or less guesswork regarding what the parameters are doing.

Uhm... Apparently he's relying on what Reaper reports. These numbers often aren't correct. The only way to properly measure RTL is by doing it physically, connecting one output with one input. You can then use Obliques RTL utility, which is made just for these purposes. https://www.oblique-audio.com/free/rtlutility I do believe that they've noticeably improved RTL on their new branch of interfaces, but I only really trust reports of physical measurements.