IR Management

[mileskb]

I took this comment from another thread as I really think it is the 400 lb gorilla in the room.

 

Additionally, the IR loading needs simplified. IR's should be attached to the patches. Its to complicated I have to worry that a certain IR is in slot 71 to link it to my patch, etc. 

 

I primarily use presets that I've purchased from either Scott or Glenn and will be using Chris as well.  They all seem to speak my language so I see no reason to re-invent the wheel.

 

I'm also still exploring my Helix.  I learn things every time I fire it up, and frankly I'm glad I didn't get into too deep on my own presets as Snapshots has been the game-changer that I didn't realize I was looking for and now I feel comfortable to start.

 

However, IR's...  I'm an old fart.  I need to be sitting at comfortable workstation if I'm going to do extensive editing, and if you get a bunch of presets and want to try them out....  well "a bunch of editing" is what it takes.  You have to go get the IR's, than figure out what slots they go into for each preset and load them.  Of course, you have to hope that the IR from another preset doesn't take that slot, else you need to load the IR into a different slot and then edit the presets to point to it.   Oh yeah... and then some IR's have a recommended global EQ setting and that's something you'll want to dial in anyway...

 

There has got to be a better way.  

 

Thinking as a programmer, functions have names.  It doesn't matter how they get into memory as long as they do, and then they are called by their name.   I wonder if there is a way to do this with IR's.  It would seem that the current coding with modification could almost support this.

 

To be specific...

 

1.  You would load your IR's.  Each would have to have a unique name, but that's it.  Just load'em.  They don't go into slots as such, just load'em until you can't load no mo...   I assume the limit would be the same number of slots..  but the "slots" won't matter.

 

2.  When you need to add an IR block, you get a list of loaded IR's.

 

Now here's where the beauty lies...    If you have loaded an IR called "Vox AC30 1a"  ANY preset, that has "Vox AC30 1a" in the IR Block is going to find that IR.   A couple of corollary ideas would be that if you loaded a preset that referenced an IR that you didn't have loaded yet, the IR block be maybe Yellow or some other color to let you know that an IR is being referenced that isn't loaded.  Then all you need to do it load that IR if you have room.  

 

Just spit-ball'n here, but it would seem "name" based rather than "slot" based would make life a whole lot easier in the long haul.

 

I'm sure those with more experience have idea's too.  But at the very least, this would eliminate the whole annoying restore process after updates.   Doesn't matter what slot, just load'em up.

 

[steevo1977]

1) A solution you can implement:

 

As you add IRs rename them with only a number (increases per unique IR) and store them in a folder and note in your record what the number is then when importing them back to Helix you select them from start to finish and it will import them all in one go in numeric order. This is an initial effort however the patches on reload will always use the right IR as they will always be in the right place.

 

Maybe I didn't word that well but ask questions

 

2) A solution Line 6 could implement (depending on empty space/fields in the patch/IR database)

 

I think that fingerprinting of files might be an idea. The data of IRs should remain the same (unless you are changing the data and resaving) however rather than using the files name (this after all is file system thing no part of the file itself) a hash algorithm could be used to produce a digest/signature that helix could instantly recognise from its IR list.

 

So in other words the patch will store the hash digest for the IR meaning where ever the IR appears in the list it will know it from it the digest/signature and load it. It could probably recalc the list locations upon addition of new IRs to avoid drop outs at patch change. This would mean loading your IRs always from your IR cache rather than any other process which may change the data of the file.

 

I understand that the import process itself may actually change the file but as long as the process is uniform in what it changes then helix will still be able to match the digest/signature from the creators patch (ie their Helix will have created the digest/signature based on the imported IR and not the original file)

 

I maybe didn't word that well either.....

 

---------------------------

 

I strongly believe name based would be a bad idea because of how easy it is to change names or duplicate names and when 3rd parties are involved this is more than likely.

 

Anyways you are right that the whole IR list can become unmanageable.

 

Cheers

 

Steevo

[spikey]

Since Im just staring to play with a few IR's, I think I will just number them and place them in the same folder.

Starting simply with #1, #2, etc etc. in front of every IR (with the identifer as to what they are suppose to be after).

This way even if I have to manually put them back they will always be in the order they go back, and marked for easy finding. 

 

Edited: I found out fast that this idea only works well if you are using 20 or so IR's. A hundred or so would become very cumbersome.

 

So Im thinking why not have some good hearted smart neat'o programmer like Fractal got to do their "Cab Lab" software, only for Helix? Just Run it along side the Helix editor and just swap out, add to and mix IR's on the fly per patch!!! Find the one you want and then save it.. Easy peezy...

 

Any software gurus out there like to take this on? Im sure you would have a audience.  ;)

[zooey]

@Steevo, I think there's a germ of an idea in there, with hashing IRs to provide some kind of globally unique identifier for them. Ideally there would be some infrastructure to make it user friendly though.

 

Even if Helix understood that a given IR that's already loaded is the one referenced by some preset(s), that doesn't help much with IR management outside of Helix -- which file in the file system is that, which ones do I need to load for this bank of presets, how can I talk to people about which IR that is -- the whole human-readable side.

 

Maybe the Helix app should keep a local database of all the IRs it has ever loaded, with their hash, original filename, Helix filename if different, and original path. I haven't thought through what the UI should be, but at least then it could tell you where to find the IR that goes with a given preset, if you've ever loaded one into it.

 

Crude ideas, fleshing out and related notions are most welcome.

[mileskb]

I like the conversation, but I think you guys are overthinking it.   The hash idea is adding a layer...    Not sure if this will make sence.. but here goes..

 

If I have a program that uses a function...  I can load that function at any time, or not at all.  It only matters if it gets called and it's not there.

 

It's not "called" by anything magic... it's called by it's name.   The windows operating system uses .dll's   Dynamic Link Libraries... but essentially they are functions.  Ever get an error   "missing .dll"   then you just register (so it loads) that .dll and all is fine..??    This is a WAY oversimplification... but...  for the purpose..

 

The way IR's are stored now, is probably an Array.   There are however many slots there are.   When we select an IR, it's being told go to slot 6 or whatever.  It's probably just as easy to tell it to load -insert name of IR-  

 

The value added of this is that when you go to select an IR, rather than a long list of slots... some empty, some full..  you would just get a list of IR's that are loaded.

 

In the real world example..  Someone sends you a preset, or you download a preset that uses a specific Ownhammer IR.    If you already know that you have that IR loaded....   All you have to do is load the preset and rock away...

[bsd512]

I like the conversation, but I think you guys are overthinking it.   The hash idea is adding a layer...    Not sure if this will make sence.. but here goes..

 

If I have a program that uses a function...  I can load that function at any time, or not at all.  It only matters if it gets called and it's not there.

 

It's not "called" by anything magic... it's called by it's name.   The windows operating system uses .dll's   Dynamic Link Libraries... but essentially they are functions.  Ever get an error   "missing .dll"   then you just register (so it loads) that .dll and all is fine..??    This is a WAY oversimplification... but...  for the purpose..

 

The way IR's are stored now, is probably an Array.   There are however many slots there are.   When we select an IR, it's being told go to slot 6 or whatever.  It's probably just as easy to tell it to load -insert name of IR-  

 

The value added of this is that when you go to select an IR, rather than a long list of slots... some empty, some full..  you would just get a list of IR's that are loaded.

 

In the real world example..  Someone sends you a preset, or you download a preset that uses a specific Ownhammer IR.    If you already know that you have that IR loaded....   All you have to do is load the preset and rock away...

 

I really like this idea and had been thinking of something along the same lines.

 

For software, the linker is what does function name resolution to it's location in memory and builds the executable.  Helix would just need a similar concept - store the IR name (or checksum + name) in the preset instead of the IR slot number - and display the name on the screen (not the checksum if they go that route), and behind the scenes, reference the appropriate slot number where that IR happens to to be loaded.

 

There's always the possibility for things to get out of sync if you remove IR's that existing presets use, and that could be dealt with by going through the "rebuild preset" boot sequence which could "relink" the IR locations.  I really like the idea of highlighting presets that have missing IR's in both the on-board display and the editor.  That way you know immediately which ones are broken - Helix can't fix that, but it can tell you which ones you need to go fix.

 

And finally, more IR space would be great.  There's a few ideascale entries for that.  Someone mentioned the Axe has 700'ish.  Seems about right - 768 seems like a good round computer sciency number (512+256).  And should be more than adequate for the bulk of users to store their full pre-auditioned library of IRs from a handful of sources.

 

This would solve so many of the IR issues folks have:

1) allow loading IRs in any order and presets still work as designed

2) allow sharing presets that contain IRs that you already own but are stored in different slots in your Helix

3) allow folks like Fremen to include the 25 IRs in his pack along with his presets without you having to reshuffle your IR locations and edit all your other patches that reference your own IRs that happen to sit in the locations that he used for his IRs

4) etc, etc, etc

 

And I think the additional IR management implementation code within the Helix would be fairly trivial - certainly trivial in comparison to all the other advanced things the Helix firmware is doing.  Yet would be a huge win for user-friendliness.

[mileskb]

and behind the scenes, reference the appropriate slot number where that IR happens to to be loaded.

 

There's always the possibility for things to get out of sync if you remove IR's that existing presets use, and that could be dealt with by going through the "rebuild preset" boot sequence which could "relink" the IR locations. 

 

We are basically on the same page, but this is where the "overthinking" may be taking place.  I could be wrong as different program languages do thing differently, but as In web design as the most basic example....  I use "includes".  I put all my includes in a folder.  When a page loads.. if there is an include called on that page... it loads it.    Like each page has a menu, so near the top of every page is a "include menu" line.  When each page is loaded, the menu code is loaded, so when the page is rendered... you see a menu.  Same thing for header, footer, etc..  (Probably lost a lot of folks here)..  My point is..  my "includes" or functions or IR's if you will, are just sitting there in no particular order.  They get pulled into memory when the page (preset) is loaded (selected).

 

In this scenario, there is no "relinking" to happen.  If for some reason I forget to load the include into the folder of includes... the page coughs with a "missing include" error.  In our Helix world, that might simple be the different color IR Block noting...  that IR isn't out there.

 

 

 

And I think the additional IR management implementation code within the Helix would be fairly trivial - certainly trivial in comparison to all the other advanced things the Helix firmware is doing.  Yet would be a huge win for user-friendliness.

 

 

I have no idea how difficult this is for the Line6 engineers.  If they are anything like me it's one of two scenarios... it's either, "oh wow, just edit some procedures to implement that"  or it's "oh crap... if I had only written those procedures one way instead of the way I did, I could implement this in a heartbeat... now I have to re-write the whole damn routine."  

 

Of course there is the third option... much like what happened with Snapshots and all of 2.01 ... We all had idea's for "scenes" and thoughts of how it could work...  and they came up with an option for implementation that pretty much blew all the backseat programmer idea's out the water.   That's kinda what I'm hoping for here.   I think my idea is pretty good and fairly easy, so I'm looking to be blown away if they actually take the whole "IR Management" thing on.  

 

Other than some effects and amp models that might be left on the table and some MIDI enhancements, along with the general improvements they've been doing...   I frankly can't imagine what else we need that's not going to end up being a major upgrade maybe involving replacing a chip or two.  

 

I wouldn't be surprised at all to find out they're already working on IR Management of some sort..   When IR's were just "cabinets" that was one thing, but now folks like Glenn are using IR's for tone matching...    Putting a setlist together that involves IR's could start to get a little time-consuming.

[steevo1977]

@mileskb

 

Using hash signatures is a more accurate way of "naming" the files. Filenames are a file system thing; the file itself doesn't care what it's called. The signatures are based on the data INSIDE the IR file. You could download IRs with the same filename as one you had before but it could be entirely different in terms of data contained within. This is entirely undesirable!

 

In theory regardless of the filename of the IR the signatures would allow Helix to KNOW if it's about to import a duplicate IR and in the same way know if it is MISSING the IR for a patch.

 

I'm guessing but I reckon the helix system is probably has a linux kernel at its core. Adding a little crypto function should be possible.

 

@zooey

 

Yes the edit app should be able to calculate IRs required from a table held of IRs used in patches and pull in the IRs required from your file system using exactly the same method of signature calc and recognition.

[steevo1977]

@bsd512

 

Also, checksum.....it's the same concept as a hash digest/signature.

 

---

 

Text is a very inaccurate way to reference anything

[bsd512]

Yes, I know. At any rate, I was supporting the concept and idea proposed, but I hate getting into the weeds of advising Line 6 how to implement, other than some nice features that would be possible that would make IR management easier and more intuitive. I'm sure they can figure it out, and those of us without access to the code or internal architecture are just whistling in the wind beyond suggesting the idea. Implementation details are best left to the developers to come up with how it may be best integrated.

 

As far as naming the IRs using the checksum/hash, I think that's a terrible idea - they'll all look like gibberish. The main idea behind the checksum/fingerprint is that it could identify the same IR regardless of its displayed filename since the likelihood of two IRs having the same MD5 checksum for example are extraordinarily small. So the IR could be identified and tracked internally by its checksum, but displayed on-screen by the actual name given to it by its creator. If filenames collide, so-be-it, might be a little confusing, but I'd think that's more of a "don't do that" edge case. If IRs are identified internally by their checksum, and you tried to load the same IR again under a different name, the Helix could either allow that (taking up IR space) or it could tell you you already have this IR installed under a different name. Again - this is going too far into the implementation details.

 

I just like the concept. And I think it would make a whole lot of folks' lives easier.

[Rocco_Crocco]

It would be great to be able to rename IRs in the Helix editor... Right in their slots. I would just add the prefix 1, 2, 3 etc to correspond with the slot number in which each IR resides.

 

Then it would be a breeze to relaod the IRs after any firmware updates. They would already be stored in numerical order on my laptop's hard drive. Easy peasy.

[steevo1977]

Yes, I know. At any rate, I was supporting the concept and idea proposed, but I hate getting into the weeds of advising Line 6 how to implement, other than some nice features that would be possible that would make IR management easier and more intuitive. I'm sure they can figure it out, and those of us without access to the code or internal architecture are just whistling in the wind beyond suggesting the idea. Implementation details are best left to the developers to come up with how it may be best integrated.As far as naming the IRs using the checksum/hash, I think that's a terrible idea - they'll all look like gibberish. The main idea behind the checksum/fingerprint is that it could identify the same IR regardless of its displayed filename since the likelihood of two IRs having the same MD5 checksum for example are extraordinarily small. So the IR could be identified and tracked internally by its checksum, but displayed on-screen by the actual name given to it by its creator. If filenames collide, so-be-it, might be a little confusing, but I'd think that's more of a "don't do that" edge case. If IRs are identified internally by their checksum, and you tried to load the same IR again under a different name, the Helix could either allow that (taking up IR space) or it could tell you you already have this IR installed under a different name. Again - this is going too far into the implementation details.I just like the concept. And I think it would make a whole lot of folks' lives easier.

I wasn't suggesting that they wouldn't have names. Helix would still display the filename as the visual reference however it would make its decisions based on the hash digest /signatures. I doubt MD5 would be the flavour of algorithm used. SHA256 is more likely due to its much larger domain, maybe even SHA512 since it works best on 64bit kernels (again a bit of a leap regarding the Helix OS)

 

I'm not telling line 6 what to do or even trying to inluence them...I was taking part in what I thought was an iSntersting topic.

 

@Rocco

 

Yes exactly. It's not that hard to keep things tidy and organise hence my suggestion regarding the numbering to the OP. I think some folk need a bit more support maybe and it would very neat for Helix and edit app to reliably recognise/differentiate between IRs...I wouldn't hold my breath as it's not as powerful a feature as the likes of snapshots regardless of the implementation.

 

S

[steevo1977]

In fact @bsd you basically just said you thought my idea (as you misread it) was bad then reiterated my actual point as a better idea...gotta love forums!

 

;-)

[bsd512]

In fact @bsd you basically just said you thought my idea (as you misread it) was bad then reiterated my actual point as a better idea...gotta love forums!

 

;-)

 

:) All good.

 

I just hope Line 6 takes some of these suggestions - the IR slot number reference thing is pretty limiting both for personal use since order is cumbersome to maintain, and especially also when patches are shared with the broader community.  Referencing them by their creator-given-name or derived checksum/hash within patches would be much better and let the IR's sit wherever internally - the idea of an IR slot number wouldn't even need to be exposed to the end user.

 

And I'd love to have more IR space while their at it.

 

And a puppy.  Preferably all free.  :)

[steevo1977]

Yeah ditto.

 

Good luck with the puppy. Is that Fractal or Kemper? :D

[mileskb]

:) All good.

 

I just hope Line 6 takes some of these suggestions - the IR slot number reference thing is pretty limiting both for personal use since order is cumbersome to maintain, and especially also when patches are shared with the broader community.  Referencing them by their creator-given-name or derived checksum/hash within patches would be much better and let the IR's sit wherever internally - the idea of an IR slot number wouldn't even need to be exposed to the end user.

 

And I'd love to have more IR space while their at it.

 

And a puppy.  Preferably all free.   :)

 

I'm pretty excited to see what they come up with too.  I can't imagine it's not already on the "how can we do this better" list.  

 

Maybe a simple IdeaScale suggestion?   

 

Does this cover it? 

 

======================================================

Improve IR Management

• The primary goal is to not have to worry about what IR is in which slot.  
• Functionally, If a preset is loaded that references an IR that's already been loaded, it should automagically find the IR and use it, and if the IR isn't already loaded, some visual reference that a block references a non-existant IR.
  • Value Added
    • When adding an IR to an IR Block, only display loaded IR's.
    • When sharing presets that reference IR's, as long as you have the IR loaded on your Helix, the preset works.
    • Restoring IR's after a RESET/Update is just a matter of loading the IR's onto the Helix in no particular order.

[bsd512]

 

I'm pretty excited to see what they come up with too.  I can't imagine it's not already on the "how can we do this better" list.  

 

Maybe a simple IdeaScale suggestion?   

 

Does this cover it? 

 

======================================================

Improve IR Management

• The primary goal is to not have to worry about what IR is in which slot.  
• Functionally, If a preset is loaded that references an IR that's already been loaded, it should automagically find the IR and use it, and if the IR isn't already loaded, some visual reference that a block references a non-existant IR.
  • Value Added
    • When adding an IR to an IR Block, only display loaded IR's.
    • When sharing presets that reference IR's, as long as you have the IR loaded on your Helix, the preset works.
    • Restoring IR's after a RESET/Update is just a matter of loading the IR's onto the Helix in no particular order.

 

 

Looks good to me, it'll get my vote.

 

I think another value is the case like Fremen's Big Pack where he included 25 IR's which greatly enhanced his presets, but for everything to work right you had to load them starting at slot 74 - 98 or something like that, since, obviously, his patches reference them by slot number like normal.

 

I had to delete all of my own IRs in that range when I got his preset package, and now all my patches that referenced my own presets in that range don't work right, and I'll need to go back and reconnect them to some alternate slot number.  This could get out of hand real quick.  And the solution proposed would solve that, too.

 

Not sure how to succinctly say that for idea scale - maybe under value add:

 

* allows third party patch providers to include custom IRs and not interfere with their customer's IR slot locations

[mileskb]

Looks good to me, it'll get my vote.

 

I think another value is the case like Fremen's Big Pack where he included 25 IR's which greatly enhanced his presets, but for everything to work right you had to load them starting at slot 74 - 98 or something like that, since, obviously, his patches reference them by slot number like normal.

 

I had to delete all of my own IRs in that range when I got his preset package, and now all my patches that referenced my own presets in that range don't work right, and I'll need to go back and reconnect them to some alternate slot number.  This could get out of hand real quick.  And the solution proposed would solve that, too.

 

Not sure how to succinctly say that for idea scale - maybe under value add:

 

* allows third party patch providers to include custom IRs and not interfere with their customer's IR slot locations

 

I agree... I'm it's sortof covered, but not directly addressed as value added, and you are right.. it could get out of hand very quickly..     I can only imagine what a gigging musician who plays in different cover bands must go through putting setlists together.   Can you imagine the flow charts and spreadsheets involved?

[mileskb]

Vote it up.  !!!

 

http://line6.ideascale.com/a/dtd/Improve-Impulse-Response-IR-Management/836099-23508 

[bsd512]

Voted! Thanks!

[HonestOpinion]

Voted!

[soundog]

Voted also.

 

In the meantime, I set up my own method of IR management, which works for me. I duplicate my IRs and keep them in one folder, and rename the dupe IRs (on the Mac) using "A Better Finder Rename" utility. I use a standard convention: sortable number;manufacturer/creator abbreviation;manufacturer filename. I keep an excel spreadsheet with the filenames and a description of the IRs.

 

The filenames in the folder are easily sorted on the Mac, and I can do a mass drag-and-drop into the Helix editor if I ever need to backup and restore. Result: the numbered preset names always line up with the Helix IR slot numbers, and my presets always align to these.

[Verne-Bunsen]

Just to play devil's advocate, one upside of the slot reference system is that you can have the referenced slot number change like any parameter with your snapshots or foot switches. For instance if you have a Bassman and a Plexi in your patch, you can load one 2048 sample IR block and point it at your 4x10 with Jensens for the cleanish Bassman and your 4x12 with Greenbacks for the smoking Plexi. Or whatever. If you find yourself running multiple amps in a patch and you like your 2048 IRs, it's a pretty nice option. Running two separate IR blocks (on the same DSP) would require that you use 1024 sample IRs, as you can only load one 2048. If the IR management system looked at the IRs the way it looks at the amps or cabs or other blocks, then I don't think that could be managed. I'm not arguing that changes to the system shouldn't be made, I voted this one up myself, just saying that there are in fact some merits to the current arrangement. Okay, ONE merit.

[roscoe5]

Appologies in advance if this was previously mentioned.

 

Helix app will read in an IR *.wav file's title by default. If it is null/blank, it will bring in the file name.

 

Note that when you export IR's from the Helix app, it populates the file title with the name that appeared in Helix. At that point, you could rename the file whatever you want, but the file title will always come into Helix on reimport.

 

What would really be cool is if the Helix app gave us the option to append the IR list sequence number 001-128 to prefix the file name on export without changing the file title (i.e. 096_Marsh412_SM57_2in). This would keep the files in sequence in the computer OS file system so you could drag them all back in order after an update, but the IR names in Helix would not show the redundant sequence prefix as the file titles would be populated with the original pre-export Helix names.

 

Regardless, you could still do this manually if you file your active Helix IR'S separately. Note the Helix app IR sequence, maybe use Excel to manage this. Export all IR's once. Add a 3 digit prefix to the file name (note the file title will still bear the name as it was in Helix). Then drag them back in after an update.

 

Of course you could use Excel macros and a little scripting to read in the IR file names from a specified folder, manually sort them once in the order they were in Helix, concatenate the filename with a corresponding sequence prefix, then rename IR files with specified sequence prefixes.

[mileskb]

Appologies in advance if this was previously mentioned..........

 

.....................................cros and a little scripting to read in the IR file names from a specified folder, manually sort them once in the order they were in Helix, concatenate the filename with a corresponding sequence prefix, then rename IR files with specified sequence prefixes.

 

All of what you said is valid if you already know what IR's you'll be using and you aren't purchasing or trading presets with someone.

 

As example.. I just purchased Glenn's artist II presets and they come with IR's.  I already had IR's in the spots he has his presets pointing to for his IR's.  So I had to go through and either redo all my presets that used IR's which meant flipping through every preset I have experimented with in the past 9 months, or load the IR's into other slots and go through each of the new presets, find the IR reference and point it to the correct IR.

 

Not very pleasant chore when all I wanted to do was load the presets and play around a bit.   Workable for sure... but we're not even into the Helix for a year yet.  More and more folks are creating IR's for tone matching... and well... as I mentioned above... I can only imagine what a session player must go through, or someone in a couple 3 cover bands...  

 

It may not be much of an issue today...  but I think it will be soon.     As I stated above, if Line6 decides to address IR Management, they'll likely come up with a solution better than any of us thought of.   At least that's been their model (excuse the pun) so far.   Until then, like everyone else..  renumbering, spread-sheets, and having to come up with a "plan" any time you get some new presets or IR's to play with.  

 

I do wonder if they realized the power of "tone matching" with IR's that some are using.  I wouldn't have thought it would work due to the resolution one usually needs for impulse responses for rooms and such.... but they work really well.   

 

As they say... we shall see.

[taylorbeats]

All great ideas, but I had to laugh a little bit when I realized in the time I used to read this I could have been double checking all of my IR assignments! :lol:

[roscoe5]

Ha, no doubt.  We definitely have a tech-savvy group here.  Get a bunch of engineers in a room and tell them to design a box ;)  I think we were having a bit of fun with this one.

 

mileskb, I definitely can see from your write up how the current Helix IR system could be a constraint to 3rd party patch importing, swapping and management.

 

I haven't jumped into the 3rd party patch game and have pulled back from 3rd party IR's.  I prefer to build, know and control every moving part of my sound (no offense, it's a personality trait).  I prefer my own IR's, which are basically tone matches of my Mesa cabs and amps applied to similar Helix amp models.

 

Very few were biting on them when I threw them out there earlier this year, and granted it was a flood of random, unorganized experiments.  But tone match IR's seem to make sense to the master patch builders and their users now.  I guess I never incorporated the golden ones into a patch pack like Fremen and Glenn.  Ah well, not trying to capitalize on it, was just trying to help out the community.  Wonder if any of them are "free sources" for the patch masters ;)

[bsd512]

IRs have a lot of unique applications that might not be apparent on first look. For example, I read or saw somewhere some folks are looking at using an IR to essentially do guitar/pickup modeling - i.e., an IR that will make your Les Paul w/humbucker sound very similar to a single coil strat. Pretty cool.

 

I think we're just scratching the surface using IRs for just cabinets. Lots of other applications and will continue to grow.

 

So more IR space and something along the lines of the above ideascale would go along way to enabling easy experimenting and application of the creative uses.

[roscoe5]

That's true. I do use some acoustic IRs I created of my acoustic guitar on a couple of song breaks. They never get swapped out though.

 

There is certainly room for improvement on the Helix IR scheme. It's no good when a seemingly simple update procedure can break your patches if you are not careful.

[mileskb]

Ok, I decided to bring this back up again in hopes more people will vote it up in IdeaScale. < - click here

 

 

As the Helix gets more popular I'm seeing more and more issues with IR Management or lack thereof, least of which is only 128 slots.

 

While I'm sure at some point I'm gonna narrow it down to just a few...  Right now like I assume many others I'm in experimentation and learning mode.  

 

JMHO but, If I can load the presets, I should have enough space to load the IR's that support them.

 

And this nonesense of loading a set of presets, then having to go through and spending a bunch of time loading the assigning the IR's to their blocks is insane.  I've got a dozen presets using the same couple of IR's we shouldn't have to go to every single pre-set and assign it.  Maybe that wouldn't be so bad if it didn't involve printing out emails cause there is no way of looking at a preset and knowing what IR it's supposed to use.

 

Sorry for the mini rant...  but this part of the process is not fun.   I don't have a lot of time, I'd rather spend the time I have playing and listening to the cool sounds than loading IR's and adding them to Blocks.

 

I have confidence that Line6 will come up with a better solution... my only fear is that to get there, I'm going to have to reload the 120 IR's I just loaded and assign them again.  But I'm sure hoping it will be worth it at that time, and that will be the LAST time.

[DunedinDragon]

This reminds me of the old joke about the guy that goes to the doctor and says, "doc, it hurts when I do this...", the doctor says "don't do that!"

 

Honestly, why do you need so many IR's?  Just because you can?  I play a very wide range of genres with different types of guitars and I have a total of 4 IR's that satisfy all of my needs across a variety of amp configurations.  One 1x12 configuration, one 2x12 configuration and two 4x12 configurations.  It sounds to me like the problems you're running into are self-inflicted...

 

Even if I decide to eventually expand this, I'll audition IR's till I find one I like, then I'll add it to it's permanant slot, rename, and save it starting with the slot number it goes in.  My patches are mapped to a slot number, so that's all that's necessary.

[mileskb]

Honestly, why do you need so many IR's? 

 

Because I purchased a few sets of presets and they either came with IR's like Fremen and Glenn or I chose to purchase the IR's that the presets were created for from others.

 

They add up quite quickly.  Even if I just want to listen to a preset to audition it...  it's kinda useless unless I put the IR's in their blocks and most take two.   That compounds the adding up quickly.

[DarrellM5]

The ultimate solution would be the ability to save the IR's as part of their corresponding presets (bake them in).  

 

I definitely agree that something needs to be improved.  128 is not enough; just my Delaune, Fremen and Chris Beaver IR's can use all of the slots.  That leaves no room for my 3 Sigma, cabIR, Taylor acoustics or other IR's.  I'd even be wiling to sacrifice 1 or 2 of the setlists for more IR storage.

 

And......Voted!

[DunedinDragon]

I guess I'm still mystified by the amount of IRs people are using.  I understand if you use someone else's presets that are dependent on an IR, that you would have to keep that one loaded.  But why would you actually keep an entire set of presets loaded if you're only using a few of them?

 

Maybe I don't get it because I only use presets I build, but it still seems kind of excessive.  I honestly can't even imagine the situation where I would actually need 128 slots, much less more than that.

[HonestOpinion]

I like the conversation, but I think you guys are overthinking it.   The hash idea is adding a layer...    Not sure if this will make sence.. but here goes..

 

If I have a program that uses a function...  I can load that function at any time, or not at all.  It only matters if it gets called and it's not there.

 

It's not "called" by anything magic... it's called by it's name.   The windows operating system uses .dll's   Dynamic Link Libraries... but essentially they are functions.  Ever get an error   "missing .dll"   then you just register (so it loads) that .dll and all is fine..??    This is a WAY oversimplification... but...  for the purpose..

 

The way IR's are stored now, is probably an Array.   There are however many slots there are.   When we select an IR, it's being told go to slot 6 or whatever.  It's probably just as easy to tell it to load -insert name of IR-  

 

The value added of this is that when you go to select an IR, rather than a long list of slots... some empty, some full..  you would just get a list of IR's that are loaded.

 

In the real world example..  Someone sends you a preset, or you download a preset that uses a specific Ownhammer IR.    If you already know that you have that IR loaded....   All you have to do is load the preset and rock away...

 

I love this idea for its simplicity but it does add a couple of minor challenges. One is that two vendors could name their IRs identically. This means now instead of using a hashed reference number that is unique you will have to rename one of the IRs, no big deal I guess. This means that if someone tries to load two IRs with the same name into the Helix; you need to either prevent it with an error message or somehow resolve or rename (e.g. add a "(2)" ) the second IR. I also wonder if the Helix having to manipulate the full namespace internally instead of a numerical hash would add any significant processing or memory overhead or latency, quite possibly not but something to consider. This method does mean you no longer have to worry about which slot the IR goes into which is the whole point.  It also as you point out could make presets more portable by having a named IR referenced within the preset instead of a meaningless hash number. Overall I love this approach!

[JMetal96]

HI everyone, Im new to the custom IR world and i recently just bought the helix and love it! But i would like to add some IRs to my unit...I already updated the helix to the latest sofware and have the latest helix editor software. Everytime i try to import or drag some of the IRs I've got, the application doesnt allow it...and ive tried opening and relclosing, restarting, even using different files. Nothings working... please help!

 

Thanks

[HonestOpinion]

HI everyone, Im new to the custom IR world and i recently just bought the helix and love it! But i would like to add some IRs to my unit...I already updated the helix to the latest sofware and have the latest helix editor software. Everytime i try to import or drag some of the IRs I've got, the application doesnt allow it...and ive tried opening and relclosing, restarting, even using different files. Nothings working... please help!

 

Thanks

 

My first thought is that you are having a problem with the format. Here is a the blurb from the Helix manual: " Helix can load and store up to 128 IRs at a time. 48kHz, 16-bit, mono, .WAV type IRs of up to 2,048 samples are natively supported. But the Helix app allows you to import IR .WAVfilesofdifferentsamplerate,bitdepth,lengthandstereoformat,andthe app will convert these attributes automatically before sending to the Helix hardware."

 

I know it sounds weird but some people who have had problems loading IRs find that they can drag them first to the desktop and then successfully to the Editor. You may want to give that a try. Maybe it has something to do with the permissions in the IR folder, I have no idea. Btw, I believe Arislaf originally contributed that idea.

[DunedinDragon]

I love this idea for its simplicity but it does add a couple of minor challenges. One is that two vendors could name their IRs identically. This means now instead of using a hashed reference number that is unique you will have to rename one of the IRs, no big deal I guess. This means that if someone tries to load two IRs with the same name into the Helix; you need to either prevent it with an error message or somehow resolve or rename (e.g. add a "(2)" ) the second IR. I also wonder if the Helix having to manipulate the full namespace internally instead of a numerical hash would add any significant processing or memory overhead or latency, quite possibly not but something to consider. This method does mean you no longer have to worry about which slot the IR goes into which is the whole point.  It also as you point out could make presets more portable by having a named IR referenced within the preset instead of a meaningless hash number. Overall I love this approach!

 

Actually the type of naming convention used for Windows .DLLs was replaced many years ago in the 90's with the preferred method of using a GUID (Globally Unique Identifier) which is a 128 bit unique integer number associated with a resource.  This is on Windows but other systems use something similar called a UUID (Universally Unique Identifier).  These are used to address the exact types of problems you're describing and are somewhat of an industry standard way of doing dynamically loaded resources.

 

The way this works in Windows is you have a human understandable name which is used for reference, but the system converts this (through the registry in windows) to it's associated GUID which points it to the specific resource to load.  There's a significant amount of programming within the operating system to ensure no two resources could point to the same GUID and it depends on everyone playing nice in the GUID world when resources get installed and that registry entries don't get corrupted.

 

The advantage to this type of approach would be that all that has to be stored with the patch is the 128 bit integer, from there it could find the appropriate resource.  The question is, how much would this type of architecture affect the available DSP and not steal from other more important aspects of FX and amp processing?

[mileskb]

Actually the type of naming convention used for Windows .DLLs was replaced many years ago in the 90's with the preferred method of using a GUID (Globally Unique Identifier) which is a 128 bit unique integer number associated with a resource.  This is on Windows but other systems use something similar called a UUID (Universally Unique Identifier).  These are used to address the exact types of problems you're describing and are somewhat of an industry standard way of doing dynamically loaded resources.

 

I would think they would go something similar.  I purposely didn't put a suggestion of "how" to accomplish it in the IdeaScale but something along this would work.  

 

But... if they don't expand too far, maybe just a simple "file already exists" type trap would be less overhead.  Not as slick, or future proof but less overhead.... maybe.

 

Anyway, I'm comfortable letting their engineers figure it out.  They haven't disappointed yet.

[mileskb]

Actually the type of naming convention used for Windows .DLLs was replaced many years ago in the 90's with the preferred method of using a GUID (Globally Unique Identifier) which is a 128 bit unique integer number associated with a resource.  This is on Windows but other systems use something similar called a UUID (Universally Unique Identifier).  These are used to address the exact types of problems you're describing and are somewhat of an industry standard way of doing dynamically loaded resources.

 

I would guess that or something similar would be the way to go.  I trust their engineers to figure it out.  They haven't disappointed me yet.

 

While some think the "only 128" and the whole way they're managed is a bit of a design oops, I'm willing to cut them some slack as not only has the use of IR's from speakers rather than just "spaces" become more widespread rather recently, but there are actual companies popping up since the Helix has been in production to create them.  Add in the number of folks who figured out how to do tone matching.

 

I'm not sure they expected such a response so fast, and honestly, I'm not sure they expected the results to add so much to the unit by being able to not only match gear (cabs) but match tones (tone matching).  

 

Kinda reminds me of the commercial that featured a webpage launching...  1 hit... 2 hits...  10 hits.. 10,000 hits...100,000 hits.. 1,000,000....CRASH!!!!!   But in this case.. no crash... just run out of room.