Search the Community

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.