Wish Reference IRs by waveform instead of location

Dave Merrill

Axe-Master
This is from the Helix 2.9 release notes. It's a feature I've wanted for years, but now I'm on Fractal :)

Improved IR Referencing
Impulse Response blocks now reference each IR file by waveform instead of index number. This means that when presets are shared and the recipient has the same IRs, they'll appear in the right place without having to manually reorder all IRs to match.
 
That was my assumption as well @AlGrenadine . When they announced the feature I assumed they were keying off IR name instead, but since its waveform based they must be doing some form of hashing to get a unique identifier. They have to rebuild the presets with this release as well, which supports them doing some of "replace the IR number field with something else" operation.
 
That was my assumption as well @AlGrenadine . When they announced the feature I assumed they were keying off IR name instead, but since its waveform based they must be doing some form of hashing to get a unique identifier. They have to rebuild the presets with this release as well, which supports them doing some of "replace the IR number field with something else" operation.
Yes, can be done not too hard.
Also they have to hash all the factory irs and user ones
 
Yeah, a lot more IRs to hash in the Fractal world. Or a conditional check to differentiate factory vs user banks, but now the preset file and code is more complex.

It would be a very useful feature though. Download a preset and a corresponding IR and put the IR anywhere you chose rather than having to match the location or go in and manually correct it. Also let you re-order your user IRs without breaking any presets.
 
I wonder how it's implemented.
A md5 hash allowing to find the correct ir back?
Not MD-5. At least SHA-1 hash if not something even longer, you really don't want hash collisions if that's the main way IRs are referenced in a preset.

Also they have to hash all the factory irs and user ones
To REALLY do this right, you'd tell them the root directory on your computer where you keep your IR library, and it'd hash those too.
Benefit would be that it could tell you which IRs on disk were needed for a preset you got from somewhere.
[EDIT] It could also tell you which ones were duplicates :)
That would be very very much awesome!
It's what I've built pieces of, outside the Helix ecosystem and without its cooperation; usability was Not Great.

Yes, can be done not too hard.
One of the hassles with doing it on my own was that Helix modifies IR files every time it saves them, among other tings embedding the timestamp of when it was saved. Upshot was that hashing the entire file contents didn't help. You'd have to extract only the actual waveform and hash that. I was part way down that path, but didn't get there.

This is a great feature, without my wishes above. If all it does is let you reorder your IRs without affecting your presets (does it?), that's HUGE!
 
Last edited:
This is a good wish. We'll look into it. Shouldn't be too hard. A hash table can be created at startup. When a preset is exported the hash values associated with User IRs are contained in the preset. Then when you import a preset it searches for those hash values in the lookup table. The odds of a two IRs having the same hash value are extremely low.
 
Why would you have to hash the factory IRs? They're always in the same location.
I'm really glad you're considering this. I lobbied Line 6 about this for literally years.

So IR references in a preset would be in one of two forms, hash of the IR audio content for user IRs, or a location reference for factory ones.

OTOH, using the hash for factory IRs too could make presets portable across different devices with different IR capacities and different IRs. There's also the IRs on disk thing, but that's pretty big scope creep.

I'm surprised that MD5 strikes you as strong enough. For instance, I think Git and Subversion use SHA1. Neither the storage space or computation cost difference is actually that great. It's not cryptography, but it is context where you don't want collisions, and there are a lot of IRs out there.
 
and there are a lot of IRs out there
2^-64 -- that's a very, very, veeerrrrrryyy small number. Specifically:

Probability of just two hashes accidentally colliding is 1/2^128 which is 1 in 340 undecillion 282 decillion 366 nonillion 920 octillion 938 septillion 463 sextillion 463 quintillion 374 quadrillion 607 trillion 431 billion 768 million 211 thousand 456.

However if you keep all the hashes then the probability is a bit higher thanks to birthday paradox. To have a 50% chance of any hash colliding with any other hash you need 2^64 hashes. This means that to get a collision, on average, you'll need to hash 6 billion files per second for 100 years.
[ref]
 
I was going to post this very wish tonight. I would love this. It works real nice in the Helix so far. Experimented with moving an IR that was shared by a couple of presets. They both switched to the new IR slot without issue. You can reorganize your IRs without worrying about messing things up.

Makes shared/purchased presets so much easier to import. Just put the IR(s) wherever you want, and the preset finds them.

Hopefully, there could be some mechanism that would recognize a duplicate IR and warn you that it is unnecessary to continue with the redundant import, as you already have that IR.
 
I'm not convinced you need something as elaborate as MD5. It's not a security or cryptography application, it's fingerprinting. You simply need something that can generate a digital fingerprint with a reasonable uniqueness.
That's what md5 is, i think, no ?
As of fingerprint you need a hash of the IR, with yes a good uniqueness
 
Last edited:
Given that the odds of collision are hilariously low, a 64-bit hash like this would be very effective (probably 32-bit would be enough):

for (i = 0; i < len; i++)
{
hash = (hash << 5) | buf;
}
 
Back
Top Bottom