Heads-up about an IR numbering gotcha

[zooey]

Everybody but me may already be aware of this, but there's a really natural sequence of IR management moves that won't produce the results you expect and probably want.

I think most people name their IRs with a 3-digit slot number prefix, to make it easier to restore them from backups after an upgrade -- just drag them back into the editor in one go.

However, if after you export, you then rename them in the file system, like when you reorganize to make room for new stuff, there's a problem: If IRs you import have a Title metadata field, which exports from Helix do, it's used as the IR name in Helix, instead of the file name. So your nicely NAMED files may end up in the right slots in Helix, but it'll be super confusing, because the exported titles are still there, causing the names in Helix to be like they were when you exported.

Small example:

• Your first 3 IRs are named foo, bar, and honk, with numbered prefixes on them 001, 002, and 003
• Those export as 001 foo, 002 bar, and 003 honk
• To change their order, you rename them in the file system as 001 bar, 002 honk, and 003 foo.
  That's a simplified example, in reality you might move them to slots 81-83, and move some new ones in 1-3.

Note what's happened here. During the export, behind the scenes Helix also set their Title metadata fields to be the same as the filenames it used. You renamed the files, but the titles in those 3 files are still what they were when they were exported. They no longer match their file names.

• Drag them back into Helix to import them, and the result looks really weird, like the files ended up in the wrong slots, or something.
  If you look closely at the actual patch contents, they're in the rights slots, but they have the wrong names in Helix, because Helix used their no-longer-correct Title metadata as their names.

The simplest workaround I know of is to use an audio tagging tool like kid3 to strip out the title metadata field before reimporting them again. I'd suggest doing that immediately after exporting, so you don't have to worry about it. kid3 can also set the title from the filename automatically, but there's really no point, just kill it, so Helix uses the file name.

 

IMO, Helix's auto-title behavior is super unconstructive, firstly for the reason explained above, but also because it means that whenever you move your IRs around and renumber them, the actual contents of the files change, not just the file name. You can't use any standard tools to search for dupes in your backups, or connect an exported IR whose name got truncated back to the original version, etc..

(You can't do that second one directly anyway, because Helix also changes the audio format, making the audio part of the content different too. But in theory you could import ant export everything in some (or all!?!) your vendor directories, then compare them to an exported backup file you were trying to identify. But that can't work, because if the file name is different, Helix will make the title different too.)

 

Semi-OT, Helix exports also erase all other metadata fields except title, like Author, Album, etc., and other attribution info. Stripping out out copyright info seems especially unfortunate to me. If I were an IR vendor, I'd object.

That also means you can't use metadata fields to store the vendor, package, and IR name, so you know what it is after Helix truncates the name.

[duncann]

I actually use the Title metadata so that when I import the original (always keep the originals), unHelixed IR files, that's what will be displayed on the device. This way I can manage a potentially growing list of IRs in a file manager. The file names will always start with the index number for the slot they are supposed to be in, and upon import to Helix, since the title metadata will be used, I can have a more descriptive name because I do not have to include the slot number in the title metadata, which is in the filename.

 

As far as reordering the IRs, or changing their slot number: the way things are now with the whole IR system, engaging in this activity would seem to be self-destructive behavior. Hopefully once the new editor is released, this might be one of the things they address.

[DunedinDragon]

Incidentally, this metadata naming thing can also be used to your advantage.  For example, lets say you export a patch to the disk drive named "My Cool Patch".  Now you'd like to annotate the My Cool Patch is designed to be used on a Stratocaster.  You can change the name in the file system to to "My Cool Patch - Strat".  When you import it into Helix it will still show up as "My Cool Patch".  But it's a nice easy way to annotate info about the patch without it showing up in the title of the patch in Helix.

[zooey]

So I guess folks are aware of this behavior, and and using it to their advantage.

 

My negative view of it comes from being in the middle of a major IR reorganization, involving renumbering everything I had used in a patch, before loading up new stuff to audition, with the plan of keeping some of it for real. In that scenario, it's just a PITA, cured by nuking all titles.

 

Really, there are so many things wrong here, from nuking copyright info and all other metadata fields you might make use of, to making the contents of a file dependent on its slot-numbered name. I love my Helix, but this aspect of it is a pretty resounding Fail in my book.

 

I'm sure Line 6 will improve matters some time relatively soon, and I'm very ready. I care much more about these basic workflow impediments than more amps etc.

[gbbaker]

Nice post Zooey.  Interesting that kit3 uses QT as a front end.  Just now getting into that.  If I understand you correctly,  the issue ONLY arises if you make changes to the IR files "outside" of the Helix.  In other words, if you simply export files, do an update, and import them back there is no issue.  However; if you make changes to the file data OR change the file order then the issues you mention will become problematic - right?

As long as you make changes on the Helix, save on the Helix and then export (perhaps under a different folder name then the "original folder name"); and then import from one of those files,things will line up and have the correct info?

 

Thanks again for the heads up as I never really looked at what was going on.  . . . . too busy trying to learn how to play guitar after 40+ years of trying!! lOL

 

Bo

[gunpointmetal]

How do you know which slots you want which IR in if its not in the Helix? Are you simply grouping types of cabs, or making a mass change to patches? 

[duncann]

Nice post Zooey.  Interesting that kit3 uses QT as a front end.  Just now getting into that.  If I understand you correctly,  the issue ONLY arises if you make changes to the IR files "outside" of the Helix.  In other words, if you simply export files, do an update, and import them back there is no issue.  However; if you make changes to the file data OR change the file order then the issues you mention will become problematic - right?

 

As long as you make changes on the Helix, save on the Helix and then export (perhaps under a different folder name then the "original folder name"); and then import from one of those files,things will line up and have the correct info?

 

Thanks again for the heads up as I never really looked at what was going on.  . . . . too busy trying to learn how to play guitar after 40+ years of trying!! lOL

 

Bo

 

It sounds like you might be hinting at automatic IR slot change recognition. So if you move an IR to a different slot using Helix as the method, any presets that use the slot the IR was in would automatically be updated to the new slot. However, this is not the case. It'd be nice if it was though.

[FlyingsCool]

Thanks!  That's some great info.  I wouldn't have thought of using mp3tag to change it. I was wondering what was going on with my GD IR's.

[zooey]

If I understand you correctly,  the issue ONLY arises if you make changes to the IR files "outside" of the Helix.  In other words, if you simply export files, do an update, and import them back there is no issue.  However; if you make changes to the file data OR change the file order then the issues you mention will become problematic - right?

 

As long as you make changes on the Helix, save on the Helix and then export (perhaps under a different folder name then the "original folder name"); and then import from one of those files,things will line up and have the correct info?

That's right. The problem happens if you rename IRs exported from Helix, then import the renamed versions back into Helix. The files get renamed, but the title metadata field inside the file doesn't, and if a title exists, Helix uses it as the name of the IR when importing.

 

Easiest solution is just to strip out the title as soon as you export, then you're free to rename/renumber with no side effects.

 

That also has the side benefit of making IR exports that are identical except for the name actually identical, which allows dupe checking etc..

[zooey]

How do you know which slots you want which IR in if its not in the Helix? Are you simply grouping types of cabs, or making a mass change to patches? 

Not sure if that was addressed to me, or if I'm understanding your question right, but here's my situation:

 

I was out of IR slots, and had new stuff I wanted to audition and potentially keep some of. Since some of my existing patches used IRs I already had loaded, I was stuck in the dreaded Inaction Zone, not knowing how to deal.

 

What I decided to do was move all the in-use IRs to low-numbered slots, starting at #1, nuke everything else, and start over, auditioning things and keeping ones I liked. That meant moving the used IRs, and manually editing all the patches that used them to point to their new locations.

 

To do that, I used a tool I wrote (I'm a programmer by trade), that lets you choose a directory of backups, and analyzes all the presets and IRs in the one you pick. It exports a file with the slot numbers of all IRs that are used in any patches, and one with the IRs used by each patch. I opened those in Excel, made a plan for how to map old locations to new, and did it, by hand.

 

I considered rewriting the patch files programmatically, but I'm wary of past and future changes to the patch file format, and special cases in the current one that I'm unaware of, since it's not publicly documented. I also have confidence that Line 6 will build better tools for this, so mine is just a temporary workaround for a (big) hole in the Helix ecosystem.

 

Even with my crude tool, that process chewed it, badly. It would have been even worse if more of my patches used IRs, and/or more of my IRs were used. But it's done, and I've been happily trying out new IRs in my (hah) free time since.

[Verne-Bunsen]

To do that, I used a tool I wrote (I'm a programmer by trade), that lets you choose a directory of backups, and analyzes all the presets and IRs in the one you pick. It exports a file with the slot numbers of all IRs that are used in any patches, and one with the IRs used by each patch. I opened those in Excel, made a plan for how to map old locations to new, and did it, by hand.

Who says IR management with Helix is cumbersome?  :lol:

[zooey]

It sounds like you might be hinting at automatic IR slot change recognition. So if you move an IR to a different slot using Helix as the method, any presets that use the slot the IR was in would automatically be updated to the new slot. However, this is not the case. It'd be nice if it was though.

Not sure if duncann was, but I am :)

 

Since nobody asked, here's how I think IR management in Helix should work...

• Helix should track which IR each patch uses not by its slot number, but by the hash of its actual content. (A hash is kind of a digital signature that uniquely identifies a piece of data, independent of its file name or location on disk, even across different computers and operating systems.)
• Among other benefits (more below), that removes the need for slot number prefixes, since locations don't matter any more.
• [EDIT] It also means Helix doesn't have to do any housekeeping if you reorder your IRs, since those hashes won't change.
• The Helix app should also know about a set of directories where your original IRs as received from the vendor (not Helix exports of them) are stored, and maintain a local database of the hash signatures of all those files after conversion to Helix format, by vendor, product, and original filename.
• That would allow it to identify the original vendor IR for any whose names got truncated in Helix, including ones whose truncated names are the same.
• It would also let it definitively recognize IRs in third-party patches, as long as you already had them.
• An extension of this would be that Line 6 (or someone else) could maintain an online global database of the Helix-format hashes of all IRs owned by anyone who wanted to participate. That'd let the Helix app tell you what IR was used in any patch, even if you don't have it yourself.
• [EDIT] The ability to audition IRs directly from disk, without explicitly loading them into your Helix would also be a big workflow enhancement. Of course it needs to actually load them to use them, but it could do that into a hidden buffer that doesn't overwrite any of you loaded IRs.

I've been thinking about passing those ideas along to the Helix team, but I haven't gotten around to it, and I'm sure they have their own ideas percolating anyway. Thoughts are welcome of course. Speaking of which, guess I should put this up on IdeaScale...

[DunedinDragon]

Not sure if duncann was, but I am :)

 

Since nobody asked, here's how I think IR management in Helix should work...

• Helix should track which IR each patch uses not by its slot number, but by the hash of its actual content. (A hash is kind of a digital signature that uniquely identifies a piece of data, independent of its file name or location on disk, even across different computers and operating systems.)
• Among other benefits (more below), that removes the need for slot number prefixes, since locations don't matter any more.
• The Helix app should also know about a set of directories where your original IRs as received from the vendor (not Helix exports of them) are stored, and maintain a local database of the hash signatures of all those files after conversion to Helix format, by vendor, product, and original filename.
• That would allow it to identify the original vendor IR for any whose names got truncated in Helix, including ones whose truncated names are the same.
• It would also let it definitively recognize IRs in third-party patches, as long as you already had them.
• An extension of this would be that Line 6 (or someone else) could maintain an online global database of the Helix-format hashes of all IRs owned by anyone who wanted to participate. That'd let the Helix app tell you what IR was used in any patch, even if you don't have it yourself.

I've been thinking about passing those ideas along to the Helix team, but I haven't gotten around to it, and I'm sure they have their own ideas percolating anyway. Thoughts are welcome of course. Speaking of which, guess I should put this up on IdeaScale...

 

 

What you're describing is within a hair's breadth of being a UUID or GUID scheme, which is probably the most reasonable and industry standard way this whole nightmare of name resolution for IR's and slots should be resolved.  I'm hopefully waiting to see if Line 6 will introduce some form of more sophisticated IR management scheme in the next FW update.  If not, I might be interested in using the utility you wrote to at least do some basic housekeeping on my IRs.  It sure would be nice if they'd pin that utility on this Forum so at least we could easily download it and use it until Line 6 comes up with something better.

[zooey]

What you're describing is within a hair's breadth of being a UUID or GUID scheme, which is probably the most reasonable and industry standard way this whole nightmare of name resolution for IR's and slots should be resolved.  I'm hopefully waiting to see if Line 6 will introduce some form of more sophisticated IR management scheme in the next FW update.  If not, I might be interested in using the utility you wrote to at least do some basic housekeeping on my IRs.  It sure would be nice if they'd pin that utility on this Forum so at least we could easily download it and use it until Line 6 comes up with something better.

Yes it is similar to a GUID, only better, because it doesn't rely on some "original source of truth" to issue "the one true ID" for a given file. It depends only on the actual audio in the file, and a specific algorithm to generate the hash from it, which is completely standardized and repeatable, just have to pick one (probably SHA-1, SHA-256, or SHA-512).

 

The current Helix behavior of including the file name in exported IRs as the Title metadata field makes this harder. It means you can't just calculate the hash of the file contents, you have to extract the audio portion of it (or to put it differently, remove all metadata), and hash only that.

 

Building the local database of every IR you have is also complicated by the lack of detailed specs for exactly how Helix does audio conversion. I tried using  the sox Sound Exchange app to convert some IRs I had to the stated Helix spec of 16-bit 48kHz mono 20,48 samples, but dithering or some other variable in how Helix does this resulted in tons of low level differences, which might or might not be audible, but absolutely do prevent the hash of those files from being identical to what Helix would export, even after stripping out the Title and all other metadata fields.

 

I haven't tried contacting Line 6 yet to ask for detailed audio conversion specs, I should.

 

 

As far as making my utility available to others, I'm game. It's a clunky process still, but it definitely is more useful than not having it. Just to be clear though, it doesn't do the hashing thing or build a database of all the IRs you have. It just inventories your patches and IRs, and tells you what IRs are used by what patches. I think at least one other person here has built something similar for their own use.

 

The other thing about it distributing it is that it's written in ColdFusion, which is easy for me because I already have it installed. For non-CF folks (i.e. most everyone) to use it on their own machines, it would need to be packaged up as a one-piece install. I can look into that.

 

The plan though was that it could easily be made available online, so people didn't have to install anything, just hit it in a web browser, but that has other hangs. The main one is that ideally you'd be able to upload a single Helix bundle file to analyze, but bundles (and setlists) are compressed internally using ZLIB, which I haven't worked out how to unpack yet.

 

All of which goes into the "beware the things you have to do before the things you have to do before the things you have to do" pile. Wish I had more time for all this. Wish it was my job even :)

 

I have talked with Jason from Helix Help about contributing to his IR Manager (a file prefix renumbering utility), at least building the Windows executable of it (which I've done), and possibly integrating some of these ideas into it, though they really are pretty separate. Our communication seems to have faded off though, I know he's crazy busy, me too.

[DunedinDragon]

 

 

As far as making my utility available to others, I'm game. It's a clunky process still, but it definitely is more useful than not having it. Just to be clear though, it doesn't do the hashing thing or build a database of all the IRs you have. It just inventories your patches and IRs, and tells you what IRs are used by what patches. I think at least one other person here has built something similar for their own use.

 

 

 

Yeah..and that's exactly what I'm after.  I was considering writing something like that myself but I just don't have the time with all my other commitments nowdays.  All I really want is to figure out what IRs I'm REALLY using across my patches then I can make some decisions about how I want to manage it.  Mostly I just want to get it down to a handful of IRs I tend to use and leave it at that.

[gunpointmetal]

I guess I'm lucky. I found 4-5 I like for everything and haven't felt the need to change. I think I have maybe 40 of the slots filled. That seems like a lot of work. 

Awesome on you for figuring it out, though!