Jump to content
SaschaFranck

FR: IR Management

Recommended Posts

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.

 

Share this post


Link to post
Share on other sites
6 hours ago, SaschaFranck said:

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.

 

ABSOLUTELY!

 

6 hours ago, SaschaFranck said:

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".

 

A potential IR licensing issue. I'd rather that L6 put it's resources into SOUND development, rather than paying lawyers.

 

6 hours ago, SaschaFranck said:

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.

 

Helix is a MUSIC computer. Incorporating Artificial Intelligence to make my storage decisions for me sounds like a BAD idea.

Share this post


Link to post
Share on other sites
4 minutes ago, rd2rk said:

 

ABSOLUTELY!

 

 

A potential IR licensing issue. I'd rather that L6 put it's resources into SOUND development, rather than paying lawyers.

 

 

Helix is a MUSIC computer. Incorporating Artificial Intelligence to make my storage decisions for me sounds like a BAD idea.

 I could see the last part being helpful for me.  I only use a handful of IR's, but if I want to work on a sound and potentially change the amp type and IR type....it'd be cool to click on the IR I was using and see what presets it is linked to...so I can easily copy the amp block over and reassign the IR to the 'new' slot.  I already sorta do the same thing with my preset management, but having it visually accessible in Edit would be helpful and save time snooping around

Share this post


Link to post
Share on other sites
12 minutes ago, rd2rk said:

A potential IR licensing issue. I'd rather that L6 put it's resources into SOUND development, rather than paying lawyers.

 

 

Helix is a MUSIC computer. Incorporating Artificial Intelligence to make my storage decisions for me sounds like a BAD idea.

 

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.

Share this post


Link to post
Share on other sites
6 minutes ago, SaschaFranck said:

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.

 

You're a lawyer? :-)

If NI is doing it with Kontakt, maybe encryption would work, but wouldn't the IR providers need to include some kind of tag in the IR so that Helix would know that there was a licensing issue? Also, Kontakt runs on full blown computers. There could be a resources issue.

 

6 minutes ago, SaschaFranck said:

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.

 

I misunderstood. Thought you wanted Helix to do the housekeeping automatically.

Share this post


Link to post
Share on other sites

No, I'm not a lawyer. But it's absolutely irrelevant whether you can export an IR in one step along with a patch or whether it'd take two steps. And yes, I know that much about the laws behind sample copyrights (which is essentially what an IR is, a sample). And fwiw, I hope they won't add any encryption. It's not necessary anyway, unless IR theft is a serious issue (which it might be or not, I wouldn't happen to know).

Share this post


Link to post
Share on other sites

It's a little relevant because Line 6 doesn't offer a place for users to exchange paid IR's like they do with presets. I could maybe see them allowing it for FREE impulse responses available through the Line 6 Shop, but for other situations, I'm sure Ownhammer, ML Soundlabs, RedwireZ, etc don't want their IRs getting spread around for free with user presets on Custom Tone.

 

I think that some of this is a good idea, especially about the logical management, but you can't just go giving away free versions of stuff that would otherwise require you to pay for it. 

 

3 minutes ago, SaschaFranck said:

No, I'm not a lawyer. But it's absolutely irrelevant whether you can export an IR in one step along with a patch or whether it'd take two steps.

 

  • Like 1

Share this post


Link to post
Share on other sites

See, this is not at all about spreading IRs. This is about keeping track of *my own* patches. Really, it's every bit the same as with softsamplers.

And I don't think Line 6 treated IR management that bad because of legal issues.

Share this post


Link to post
Share on other sites
11 minutes ago, SaschaFranck said:

See, this is not at all about spreading IRs. This is about keeping track of *my own* patches. Really, it's every bit the same as with softsamplers.

And I don't think Line 6 treated IR management that bad because of legal issues.

No, I don't think they did either, but I also don't think it's that bad. And the legal issues regarding the IR's would need be considered, even if MOST users would never share their paid IRs anyways. Is there supposed to then be a filter on Custom Tone that somehow knows to strip an IR from a preset if that information were to be included with the preset when you export it for storage? The Kontakt example is just as problematic though, because if you're using a paid sample pack, you shouldn't be sending those samples to whoever needs to open a patch, either. There's also the possibility that the internal storage system on the Helix just doesn't have the ability to manage data like that. 

 

  • Like 1

Share this post


Link to post
Share on other sites

I have no idea how Customtone treats anything, it's none of my business. I won't buy or sell things there, either (ok, well, who knows, never say never...).

Anyhow, what I do know is, if people want to share stuff illegally, it's gonna happen anyway (and it's not gonna happen on Customtone for sure) and you have to adress it at the source.

But as said, all that is none of my business, all I want is to be able to keep track of my patches and their corresponding IRs for my own sake. Oh well, I would happily share my own IRs with anybody as well, I have zero financial interests regarding those (even if I think some of them are quite great, especially for the live playing folks).
 

Whatever, I'd prefer to not talk too much about whatever legal side issues anymore. Been through that debate (at least regarding "normal" samples) a lot of times and it's tiresome. And as said, I also don't think legal issues are part of the reason why IRs are treated this way in the Helix (especially since you can share them as easily as it gets should you feel like).

 

I would really only be interested in how this can be improved for users who want to use IRs in multiple ways and keep track of things. And I'm pretty sure I'm not the only one interested in that.

Share this post


Link to post
Share on other sites
7 minutes ago, SaschaFranck said:

I would really only be interested in how this can be improved for users who want to use IRs in multiple ways and keep track of things. And I'm pretty sure I'm not the only one interested in that.

 

We're with ya on that!

As for the legal implications, always a tedious and depressing subject. But keep in mind that MacDonald's paid millions to some Darwin Award Candidate because he spilled hot coffee on himself while breaking the law drinking it while driving!

Share this post


Link to post
Share on other sites

As said, legal issues are a non issue in this case. Anything that could be abused illegally could happen just as well with the current IR implementation. What I'm suggesting isn't making it harder or easier, so it's simply not required to make this minefield a part of this discussion.

Share this post


Link to post
Share on other sites
8 minutes ago, SaschaFranck said:

As said, legal issues are a non issue in this case. Anything that could be abused illegally could happen just as well with the current IR implementation. What I'm suggesting isn't making it harder or easier, so it's simply not required to make this minefield a part of this discussion.

 

And without a law degree AND a prior Supreme Court Ruling, you can't say for sure that it's a non-issue!

For not wanting to discuss the legal issues any further, you sure are adamant about making unfounded claims about the legalities involved!

Share this post


Link to post
Share on other sites
5 minutes ago, rd2rk said:

And without a law degree AND a prior Supreme Court Ruling, you can't say for sure that it's a non-issue!

 

 

Yes, I can. What I suggested would make *zero* difference in terms of easier or harder IR sharing. Zero. Hence there's no differences regarding the legal aspects, either. It's something you don't seem to understand - and hence part of the reason why I would prefer to not discuss this very issue any further.

Share this post


Link to post
Share on other sites

Ok, I think maybe I misunderstood what you meant by sharing patches/IRs.

Basically what you're saying is to have presets acknowledge the IR on a individual file data level instead of which slot it would be stored in? So patches that have "EVH_V30_SM57_EDGE.wav" as the cab IR would find that particular file instead of looking to load the IR from a given slot no matter where in the memory it is located?

That does make some sense, then. 

Share this post


Link to post
Share on other sites
41 minutes ago, SaschaFranck said:

 

Yes, I can. What I suggested would make *zero* difference in terms of easier or harder IR sharing. Zero. Hence there's no differences regarding the legal aspects, either. It's something you don't seem to understand - and hence part of the reason why I would prefer to not discuss this very issue any further.

 

I DO understand. What YOU don't want to acknowledge is that neither of us make the legal decisions for the IR providers. If THEY decide it's an issue, then it IS an issue!

If NI has figured this out, GREAT! I hope L6 has a contact there. Then again, NI is bound by the laws and legal precedents of Germany, not the U.S.

 

You are absolutely correct that this is a pointless and annoying discussion. Why don't we both agree to end it here?

 

PEACE!

Share this post


Link to post
Share on other sites
9 hours ago, SaschaFranck said:

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.

 

 

I am in full agreement that we need better IR management. There has got to be a better way!

 

I think I get where you are headed with this and I like it. You sidestep a lot of the potential copyright issues as the IR file is separate from the preset backup, contained either in the same directory as the preset or potentially a different location entirely. The preset simply includes a directory and file location pointer to the IR that is only used during the initial load of the preset to the Helix. That preset load would also load the IR in a slot - ANY SLOT.  The linkage between the preset and the IR location would be maintained internally by the Helix. In practice I think this approach would probably lend itself to a bit more unauthorized sharing of proprietary IRs but there is nothing about this approach that seems inherently illegal. The number of people pirating IRs hopefully would not change significantly. As long as the IR is not actually contained in the preset this does not seem like a particularly problematic approach.

 

You will require proper error handling in the Helix to alert the user that the IR is missing when the preset points to an IR in a file location that does not exist. This might happen for example when presets are downloaded from CustomTone or when using commercial downloads, or if the IR is moved or deleted. This would only be significant during the initial load of the preset. After the preset load the IR would be located on the Helix. One of the benefits of this approach might be for example though that IR and preset designers might have more of a tendency to partner and sell you a pack of presets with their corresponding IRs already included in for example either a named directory for each preset or even a separate directory, as long as the IR is not contained in the preset itself.

 

I would also like to see a visual indication or report of which IRs are in use so their storage space can be reclaimed.  Better yet a more robust IR management screen. There was a user here on the forum who did write an app/script that parses through the exported presets and produces a report such as you are describing.  Awesome as it was for them to contribute that, they would have been the first to admit there is probably a more elegant and useful way to manage IRs. Hopefully they can chime in and provide the link to that script if it is still around.

 

Anyway, not that this is the first one but I hope threads like this persist because there is definitely a better mousetrap to be built when it comes to IR management. I do take a bit of exception with calling what we have now "nothing". A backup restore is able to place IRs back in the same slots they were stored in.  This was actually functionality that was missing for many of the early firmware revisions so there has been improvement in the process. I heartily agree IR management could be significantly enhanced though.

  • Like 1

Share this post


Link to post
Share on other sites
19 minutes ago, gunpointmetal said:

Ok, I think maybe I misunderstood what you meant by sharing patches/IRs.

Basically what you're saying is to have presets acknowledge the IR on a individual file data level instead of which slot it would be stored in? So patches that have "EVH_V30_SM57_EDGE.wav" as the cab IR would find that particular file instead of looking to load the IR from a given slot no matter where in the memory it is located?

That does make some sense, then. 

 

Absolutely that!

I was just using the example of sharing patches as an example as it demonstrates things (or rather their shortcomings) in the most obvious way. But the same things apply when you keep backups and what not strictly for personal purposes.

I haven't even thought about any legal aspects because they're irrelevant in this case. If someone wanted to illegally share some IRs from the Helix (not even considering the fact that they're stored on your computer already anyway), as is, it's a one click affair (export function in the IR list). With my proposed improvement, all that would happen is that a patch file would be saved as well (and that clearly isn't relevant as far as legal aspects go - sure, you could share a commercial preset, but let's please not open that can of worms...). Another one click affair, same legal risks as before, no less, no more - and certainly no reason to even discuss this.

 

All I want is to be able to load a patch properly in 10 years from now (maybe on a 3rd Helix hardware revision, whatever) without having to look up whether there might be any informational text files around, telling me which IR I would have to use. Textfiles that I would have to create manually in the first place - which would be the next thing that I just don't want to do and that simply shouldn't be necessary.

 

Also, look at it that way: With my proposed improvement in terms of IR management, it'd be a lot easier to deal with the limited amount of just 128 IRs (I know, for some people it's more than enough, for other's it's not - each to their own, shouldn't be part of this discussion). You could just freely move any number of IRs out of your Helix at any time to "mass-check" a new IR library at once (which works extremely well in case you can place them all straight after each other so you can go through them in pedal edit mode) and easily move the temporarily removed ones back in after that as the patches requiring them would instantly find them, regardless of the slot you load them into.


With the proposed functionality of HX Edit telling you which IRs are actually used by whatever patches (or better: which are *not* used), things would get even better because it'd make it absolutely trivial to get rid of "orphaned" IRs. IR housekeeping the easy way.
 

Whatever it might be, as said, pretty much any improvement would be welcomed.

  • Like 1

Share this post


Link to post
Share on other sites
13 minutes ago, rd2rk said:

 

I DO understand. What YOU don't want to acknowledge is that neither of us make the legal decisions for the IR providers. If THEY decide it's an issue, then it IS an issue!

 

You obviously don't understand that my proposal makes *no*, *zero*, *zilch* of a difference in terms of sharing IRs. And *if* IR providers had a problem with all that stuff, they would already have the problem. What I'm suggesting doesn't change anything. It's not even remotely required to discuss that any further in this thread. You raised an issue that simply isn't an issue. For nobody.

  • Like 1

Share this post


Link to post
Share on other sites
2 minutes ago, SaschaFranck said:

 

You obviously don't understand that my proposal makes *no*, *zero*, *zilch* of a difference in terms of sharing IRs. And *if* IR providers had a problem with all that stuff, they would already have the problem. What I'm suggesting doesn't change anything. It's not even remotely required to discuss that any further in this thread. You raised an issue that simply isn't an issue. For nobody.

 

And what you're never going to admit is that it doesn't matter whether or not YOU think it changes anything. That's your OPINION, and when it comes to legalities, your opinion is absolutely irrelevant. Even your opinion that it's not an issue (despite the double negative.....), is irrelevant. The only thing about this discussion that IS relevant is that it's all irrelevant, which we've now both agreed on, so again I'll suggest that we drop it, since we're in agreement that it's irrelevant.

 

OK? Olive branch proffered. Accept? Trust me, I'm as stubborn as you!

 

 

Share this post


Link to post
Share on other sites
17 minutes ago, HonestOpinion said:

In practice I think this approach would probably lend itself to a bit more unauthorized sharing of proprietary IRs

 

See, I have thought about this quite a bit (especially as it has been raised again and again, even just in this rather short thread), I even stepped back (for other reasons as well, but still...) from the idea of perhaps having IRs embedded in a patch file. I think the percentage of illegally shared Helix patches and their required IRs would perhaps raise by 0.0001% or so (ok, it might as well be 0.001%), simply because exporting IRs from the Helix is as easy as it gets already.

If one wanted to do something against this, the best way would perhaps be to not allow any IR export from the Helix - and believe it or don't, I'd be perfectly fine with that. All the IRs I need are on my drives already anyway. And I can keep gazillions there and back them up for the rest of my life as well (these things are just too small to worry).

Basically, all I want is HX Edit to tell me "You need "GreatIR_01.wav" for this patch to work - can't find it in the internal memory, search drives for it, yes/no?" And in case the internal memory would be full already, I would like it to continue with "Insufficient storage space for "GreatIR_01.wav", want me to look for unused IRs, yes/no?", obviously followed by a dialog allowing me to delete any number of unused IRs. And then, as the final option, in case there's no unused IRs anymore, I'd like HX Edit to show me which IRs are used by which patches, so I could probably find some that I could delete manually.

  • Like 1

Share this post


Link to post
Share on other sites

I am not going to continue this discussion with you, @rd2rk. There's nothing worthwile to discuss. I'd rather spend my energy thinking about decent solutions regarding the IR management situation.

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
11 hours ago, SaschaFranck said:

 

See, I have thought about this quite a bit (especially as it has been raised again and again, even just in this rather short thread), I even stepped back (for other reasons as well, but still...) from the idea of perhaps having IRs embedded in a patch file. I think the percentage of illegally shared Helix patches and their required IRs would perhaps raise by 0.0001% or so (ok, it might as well be 0.001%), simply because exporting IRs from the Helix is as easy as it gets already.

If one wanted to do something against this, the best way would perhaps be to not allow any IR export from the Helix - and believe it or don't, I'd be perfectly fine with that. All the IRs I need are on my drives already anyway. And I can keep gazillions there and back them up for the rest of my life as well (these things are just too small to worry).

Basically, all I want is HX Edit to tell me "You need "GreatIR_01.wav" for this patch to work - can't find it in the internal memory, search drives for it, yes/no?" And in case the internal memory would be full already, I would like it to continue with "Insufficient storage space for "GreatIR_01.wav", want me to look for unused IRs, yes/no?", obviously followed by a dialog allowing me to delete any number of unused IRs. And then, as the final option, in case there's no unused IRs anymore, I'd like HX Edit to show me which IRs are used by which patches, so I could probably find some that I could delete manually.

 

When it comes time to do backups this was exactly the issue that gave me pause. You're right, you might be compelled not to include the IRs in the backups for the reasons you described even though it would be ideal if you could. A great way to maintain your presets would be for example to backup each preset and its corresponding IR into a separate directory named for the preset. That has got to be the simplest method for executing this approach to IR management. Otherwise you would require even more changes to HX Edit to indicate where the IR file is located on your computer. You still have not violated copyright at this point as far as I can see ( no lawyer here) but things could potentially get sticky for Line6 when some people, hopefully a minority, started shipping around Line6 created preset directories with unauthorized inclusions of IRs.

  • Like 1

Share this post


Link to post
Share on other sites

Well now that I understand what you're talking about, I'm all for it as long as it doesn't require software to fill up space on the physical unit that could be used for more FX and amp models, lol.

Share this post


Link to post
Share on other sites

I actually have no idea what would be the best way to skin this cat, but I can safely say that I'd be fine if it'd require to keep my entire enchillada of IR folders around for the rest of my life, even if it was just for 37 Helix patches to work properly in some years to come - simply because I backup all my IRs since years already in all their glory and keep them on each and every computer anyway.

But I'd feel better if I could just have the required IRs next to my patch.

 

Whatever, it's really not so much about how IRs are backed up, it's much more about how HX Edit (or the Helix) deals with them. I'm sure I could always find the required IRs somehow on my harddrives, but it's a lot tougher to find out which IRs are required by a patch - and in case you a) didn't manually write a note and b) erased or re-ordered the internal IRs, there's absolutely no way to find that out ever again. Exporting IRs wouldn't even have to be changed. I can do that manually, it's a bit more work but no big deal. Importing and re-assigning them is where the drama starts.

 

Share this post


Link to post
Share on other sites
12 minutes ago, gunpointmetal said:

Well now that I understand what you're talking about, I'm all for it as long as it doesn't require software to fill up space on the physical unit that could be used for more FX and amp

models, lol.

 

I don't think *anything* would have to be changed on the Helix itself (as you can't slap IRs onto it and rearrange them others than by using HX Edit), it could all be done solely in HX Edit.

And given that IR management is done properly, I would very likely never ask about more IR slots, either. Right now I would only wish for more of them because you need to keep all kinds of IRs "just in case" - as some arbitrary patch may need them.

  • Like 1

Share this post


Link to post
Share on other sites

I do agree with rd2rk that until a copyright lawyer chimes in here with a definitive analysis (probably not going to happen) we musicians are not going to be able to conclusively say what's legal and what's not. On the face of it though a lot of what's being proposed sounds doable.

Share this post


Link to post
Share on other sites
8 minutes ago, HonestOpinion said:

I do agree with rd2rk that until a copyright lawyer chimes in here with a definitely analysis, probably not going to happen, us musicians are probably not going to be able to conclusively say what's legal and what's not. On the face of it though a lot of what's being proposed sounds doable.

As long as the IR isn't being exported in the patch file so it can be uploaded to Custom Tone for sharing or sent out via some other method as a file containing a paid IR file, shouldn't be an issue. 

  • Upvote 1

Share this post


Link to post
Share on other sites
5 hours ago, gunpointmetal said:

As long as the IR isn't being exported in the patch file so it can be uploaded to Custom Tone for sharing or sent out via some other method as a file containing a paid IR file, shouldn't be an issue. 

 

I would tend to agree. Just because you create something that makes people more likely to pirate doesn't mean you are responsible for their actions. Doh, and then there's Napster. Anyone remember them?

Share this post


Link to post
Share on other sites

 

Ok, let me get into the possible legal aspects of one possible method I was suggesting (exporting patches and IRs simultaneously) for one more time.

 

First thing to remember is that you already *can* export IRs from the Helix. And quite obviously, you can as well export patches already. So, given all "raw" technical aspects, nothing new would be introduced.

 

Would a method such as proposed by yours truly make illegal file sharing easier, though? Perhaps, yes.

But oh, hold on! For this very illegal file sharing to work, you would have to have the patch/IR in question on your computer already! Boom! Why would anyone with whatever criminal intentions in his mind load the patch into the Helix and re-export it to accomplish his evil plans? I give you that there might be some esoteric scenarios when this would seem halfway plausible, such as carrying your Helix to another location with another HX Edit equipped computer. But then, you could go for your bad moral intentions with the current implementation already.

 

And now, let's take this a step further. With that new proposed IR management, the very first noticeable improvement wouldn't be an easier export of patches and IRs (which, as said several times, is possible already) but it would be an easier import procedure of those in the first place.

Even in my comparatively short time with the Helix I have already stumbled across several postings here and there where people were complaining about not getting a certain patch to work - the problem being IRs not assigned properly. As a result, people may think "Uhm, everybody's praising these Fremen patches so much, I don't get it, they sound horrible to my ears" - no wonder, because they have, say, just played through a patch with a thin-ish resonant acoustic IR instead of a thick, juicy cab IR. Due to the convoluted way the Helix treats the relationship between patches and IRs.

In the end, professional patch and IR makers may feel less inclined to create patches for the Helix because of that. They would have to carefully explain how to make the IRs coming with the patch work as intended each time (which is getting even more complicated once there's multiple IRs in use for one patch). And Helix newcomers (especially those new to modeling and IRs as well) would possibly still not get it right (as said, I have seen that more than once - I'm sure you folks have as well...). And those that still create patches with IRs included may as well experience less sales because - well - there's reports of patch XYZ not sounding properly.

 

Bottomline: The way I think IR management should work could perhaps even lead to more sales of patches with IRs included as the patch maker wouldn't have to wade through whatever support inquiries anymore (aka "The patch I purchased from you sounds like an icepick in the forehead!") and the folks purchasing patches would have a lovely "just works" experience. Defenitely a win-win situation.

 

  • Like 1

Share this post


Link to post
Share on other sites
On 10/31/2019 at 2:22 PM, SaschaFranck said:

I have no idea how Customtone treats anything, it's none of my business. I won't buy or sell things there, either (ok, well, who knows, never say never...).

 

To clarify, Customtone has boatloads of free presets. 

 

I haven't purchased one paid preset and I visit the site all the time to check out other people's presets. 

 

Lots to enjoy there with no IRs.  YMMV. 

Share this post


Link to post
Share on other sites

Well, I have of course checked out Customtone. But so far I have absolutely no need for other peoples creations - and I don't think this will change a lot.

Share this post


Link to post
Share on other sites
44 minutes ago, SaschaFranck said:

Well, I have of course checked out Customtone. But so far I have absolutely no need for other peoples creations - and I don't think this will change a lot.

Self- righteous much?  Your loss. 

 

There's stuff out there from Jeff Schroeder of Smashing Pumpkins and Vernon Reid from Living Colour but whatevs. 

Share this post


Link to post
Share on other sites

What in the world does it even remotely have to do with being self righteous when I don't have any interest in using others patches?

I have never used any presets of any guitar MFX units and it worked out fine with me. Why would I change that just because there's a place where I could grab some patches?

Apart from that, my main axe isn't exactly "run of the mill" so many patches won't translate properly.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...