Leaderboard

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.

If it were only so simple: I am afraid that this is a (new) machine that has never until today had Helix Native on it. This is EXACTLY what is being installed. I just don't understand it at all - although yes: M1. I was reading it earlier.Thank you though. T. EDIT: I have it working - I cleaned it all out AGAIN, and reinstalled - this time it works Fine. I noticed there were a couple of mounted dmg's that did not show up in the finder "side Bar" to the left, but only show in the finder "proper". Anyway - my brain REALLY hertz now, as I can not explain the above images. WHY??WHY?? Time to clone a copy of my ssd. Thanks any and all who were reading this. T. Xx

It's definitely easier to shove MIDI data down a cable compared to audio. The signal levels are much higher, and crosstalk isn't as much of an issue because dynamics info is embedded in the data, rather than an amplitude change with audio. Now, if MIDI really could reproduce all the nuances of playing guitar, and there was a guitar synth at the other end that could translate these nuances to sound, then it would be easier to process the synth sound than the raw audio. Ultimately, I do think the end run will be a controller that plays like a guitar, feels mostly like a guitar, and can translate nuances to data, but is not a retrofitted version of a conventional guitar. From a physics standpoint, conventional guitars just weren't designed for this kind of application. The Jammy-E guitar's technology is very promising, and it was a finalist in the 2021 MIDI Innovation Awards. Sadly, the company making it is (was) located in Ukraine, and I don't have to tell you the rest of that story :( However, the founder has been in contact with The MIDI Association, whose members are trying to help. They hope to find a way to keep the technology alive.

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.

Both Redwirez and Ownhammer have some free trial IRs. If you like them, you can purchase more. Free Redwirez: http://www.redwirez.com/free1960g12m25s.jsp?ref=home Free Ownhammer: http://www.ownhammer.com/free/v4-demo/