Helix IR Search or Drag and Drop

[salty09]

It sure would be nice if the Helix Editor had a find function for impulses. I bought the Freeman pack and just bought a Glenn Dalune pack as well and of course they have the IR's in the same banks. :) 

 

 

It would be great if I could do a Ctrl F on an IR in the list and it show me a list of all patches that are using that IR... or better yet, if I drag and drop an existing IR in the Impulses list, it would update all existing patches that use that IR with the new location.  Actually, both of those solutions would be handy to be honest. 

 

Of course it would require an update to the actual Helix hardware to adjust the patches that are changed, but that has to happen with any other change to a patch anyway. 

 

If this sounds useful to anyone else, I can put the idea into IdeaScale, if not I will quietly just go about my day... :p 

 

I am of course going to manual move the Dalune ones, since I bought a small pack with like 25 patches, but ugh! LOL. 

 

 

 

[DunedinDragon]

It sure would be nice if the Helix Editor had a find function for impulses. I bought the Freeman pack and just bought a Glenn Dalune pack as well and of course they have the IR's in the same banks. :)

 

 

It would be great if I could do a Ctrl F on an IR in the list and it show me a list of all patches that are using that IR... or better yet, if I drag and drop an existing IR in the Impulses list, it would update all existing patches that use that IR with the new location.  Actually, both of those solutions would be handy to be honest. 

 

Of course it would require an update to the actual Helix hardware to adjust the patches that are changed, but that has to happen with any other change to a patch anyway. 

 

If this sounds useful to anyone else, I can put the idea into IdeaScale, if not I will quietly just go about my day... :P

 

I am of course going to manual move the Dalune ones, since I bought a small pack with like 25 patches, but ugh! LOL. 

 

The problem here is you're making an assumption that all your patches are loaded in the Helix, but that's not always true.  I keep most of my presets saved on disk and load them as needed.  A more likely solution would be to have an external facility in the editor that could go through all your saved presets to show you what presets use that specific IR number.  You'd still have to determine on your own whether those are all the same IR's as it's entirely possible to have two patches pointing to the same IR number but were built with different actual IR's when they were saved.  No matter how you slice it, it's going to be a tedious and nasty process.

[salty09]

The problem here is you're making an assumption that all your patches are loaded in the Helix, but that's not always true.  I keep most of my presets saved on disk and load them as needed.  A more likely solution would be to have an external facility in the editor that could go through all your saved presets to show you what presets use that specific IR number.  You'd still have to determine on your own whether those are all the same IR's as it's entirely possible to have two patches pointing to the same IR number but were built with different actual IR's when they were saved.  No matter how you slice it, it's going to be a tedious and nasty process.

 

 

Meh, that is not that big of a deal really. I mean the Helix Native would be able to use the same functionality I am talking about implementing in my mind as well as you situation of storing them on your machine instead of on the unit. So I would not say I made any assumption that rules out your methodology of ordering your patches. 

 

My guess is that the file construction for patches you save on your PC has to be the same format as the file in the data on the physical device. So when you would do a search function using the editor, if my hunch is correct, the same exact code could read through the files on the unit and the files in your library at the same time. Given that the position is not going to necessarily be enough to go on, if what you are saying is that you load some irs in and then make patches, then load a different set of irs in and make more patches, they may have to add a second layer of comparison of the ir based on the name of the ir file. 

 

I mean, yeah what you do does complicate the process some, but being a developer, I write code for my customers based on a set standard of usage and functionality with a realistic amount of flexibility for other uses when feasible.  There is always some customer that wants to do things totally different in our application and I can not always accommodate them because it limits the standard user's ability to have a straight forward approach that follows what our initial design elements were. 

 

But back to the IR library search, I see no reason that doing a drag and drop of an ir and updating the patches currently on the device to reflect that change could not prompt you to ask if you want to search your library and update other patches effected by the change. 

The same thing of course would need to occur for the Ctrl F. It would need to search your currently loaded patches and prompt to see if you want to search your computer library as well.

 

The Helix Native would just need to skip over the logic to search the device and go straight to searching the computer library of course. 

[rd2rk]

I'm thinking that the helix database is probably a very simple flat file model without much of a query capability. But I totally agree that there needs to be a better way of dealing with IRs than we have now, and this has been brought up here before. There's probably been an idea scale entry about it, but I haven't seen one lately. Go for it! I'll vote it up for sure!

[rd2rk]

I'm thinking that the helix database is probably a very simple flat file model without much of a query capability. But I totally agree that there needs to be a better way of dealing with IRs than we have now, and this has been brought up here before. There's probably been an idea scale entry about it, but I haven't seen one lately. Go for it! I'll vote it up for sure!

[DunedinDragon]

This has been talked about several times and I know there have been several IdeaScale entries on it.  Typically this subject comes up in response to a FW upgrade when people need to save and restore their patches and IR's.  It's seems to be a bit less of an issue since a lot of people have settled on the informal convention of renaming their IR's starting with a 3 digit number that designates which IR slot it should go into so that presets get linked back up correctly to their patches.

 

I personally don't find the IR arrangement all that cumbersome.  It's very simple and easy to understand and relatively easy to maintain once you adopt the convention of including the slot number in the IR name when it's backed up.  It might be easier and less error prone if the editor would simply allow you to save your IR's in the same way as you save a setlist, so that it's one JSON file which would include the slot number for each preset.  That one feature alone would provide a simple way of addressing some bulk maintenance issues like determining which IR's are not referenced by any patches in a given setlist, or which patches use a given IR.

 

Since the Editor application only REALLY loads the data from the Helix one patch at a time for editing, and given the lag time it takes for the editor to load each patch, bulk operations across all of the patches in a setlist might better be served as JSON file operations until the day the Editor application is re-engineered to load the data from all the patches in the current setlist in memory all at one time.  But I suspect we're quite a few updates away from something like that...but you never know....

[zooey]

This has been talked about several times and I know there have been several IdeaScale entries on it.  Typically this subject comes up in response to a FW upgrade when people need to save and restore their patches and IR's.  It's seems to be a bit less of an issue since a lot of people have settled on the informal convention of renaming their IR's starting with a 3 digit number that designates which IR slot it should go into so that presets get linked back up correctly to their patches.

 

I personally don't find the IR arrangement all that cumbersome.  It's very simple and easy to understand and relatively easy to maintain once you adopt the convention of including the slot number in the IR name when it's backed up.

I disagree. There are some big weaknesses that convention doesn't cover:

 

- You can't easily see what slots are actually used by a given universe of patches and which aren't, or tell Helix to dump all unused ones. That matters when you want to use or try some new ones and need to free up some slots, without breaking existing patches you care about.

 

- You can't audition IRs without first loading them into your Helix, or using an IR loader on your computer.

 

- IR names in Helix are too short to accommodate the full file names used by commercial libraries.

 

What's needed here is an integrated solution that's aware of your whole IR library on disk, as well as but separate from what's currently loaded into your Helix. It should let you audition from disk (or pretend that's what it's doing, using a hidden buffer etc). It should let you easily manage which ones you want in your Helix, and warn you if you're taking IRs off that are in use by any patches on it.

 

 

Ideally you'd have room in the filename length to prepend a short manufacturer prefix too -- OH=Ownhammer, RW=RedWirez, 3S=3Sigma, CP=CelestionPlus, AL=Allure, etc.

 

Even better, it would understand a given directory in your library as belonging to a manufacturer, let you assign a prefix to each one, and automatically prepend it to each filename when you moved the file onto your Helix. Or even more better, IRs on Helix would be inside "folders" too, preserving that structure without monkeying w filenames.

 

Also ideally, there would be way more total IR slots on Helix, so you didn't have to be so careful about which ones to load. I'd gladly give up a bank of patches for that personally.

[DunedinDragon]

I don't disagree with any of what you're saying here, but some of that's really all part and parcel of the limitations relating to the way the current editor only loads one patch at a time, and that patches and IR's operate in two separate worlds that depend on manual integration.  And maybe we're referring to the same thing given your term "Integrated Solution", or better yet a comprehensive integrated solution.  But I think that's a pretty significant leap from where we're at right now with the editor.

 

I wouldn't mind just a couple of baby steps toward that vision which could work on an interim basis with an eye toward a more comprehensive solution, such as a JSON formatted IR setlist (perhaps with longer names and maybe some additional descriptor fields) that retains the IR slot position and name (and whatever other descriptive data) that can be loaded and saved in one operation.  Otherwise we might be waiting quite a long time.

[salty09]

I'm thinking that the helix database is probably a very simple flat file model without much of a query capability. But I totally agree that there needs to be a better way of dealing with IRs than we have now, and this has been brought up here before. There's probably been an idea scale entry about it, but I haven't seen one lately. Go for it! I'll vote it up for sure!

 

Oh yeah, I figured it was probably XML at the very least though. We work a lot with Pervasive which is a database based off the old Btrieve flat file system and it allows quite a bit of functionality and is super fast and light, if you are not using the relational engine.  

[DunedinDragon]

Oh yeah, I figured it was probably XML at the very least though. We work a lot with Pervasive which is a database based off the old Btrieve flat file system and it allows quite a bit of functionality and is super fast and light, if you are not using the relational engine.  

 

The file based storage is JSON (which is a variant of XML).  But the internal storage of the data within the Helix may or may not be that.  I would think for performance reasons it's likely stored in the helix unit in a more efficient data structure that doesn't need to be translated and keeps the overhead down for switching and loading presets in real time.  But that's just a guess.

[salty09]

The file based storage is JSON (which is a variant of XML).  But the internal storage of the data within the Helix may or may not be that.  I would think for performance reasons it's likely stored in the helix unit in a more efficient data structure that doesn't need to be translated and keeps the overhead down for switching and loading presets in real time.  But that's just a guess.

Cool, just checked it out and see the similarities and differences. Thanks. 

[zooey]

The IRs "DB" is probably just an array or object of filenames. There's no other​ metadata besides the IR .wav files themselves, and it'd be strange for the export to include those, since as it stands now at least, you need to menage them as files anyway.