Leaderboard

Time is an illusion, lunchtime doubly so. Douglas Adams

Since the universe appears to be about 14.5bn years old and anatomically modern humans have been around for no more than 400ky (a generous estimate), then there is good evidence that reality exists without us being here to perceive it...

It's a bit more subtle than that :-) Now is indefinable. Only the past is definite. But the past is permanently inaccessible - it has gone forever. The future doesn't exist because it hasn't happened yet, so the strong sense of self we experience as conscious beings may be less secure than it feels :-) Where, exactly, do we exist?

Put it this way, if you were in a music store and plugged into different amps with the same settings, would they all be the same volume? There's your answer....

This is a first I think. A thread about a Customtone tone. They've been mentioned in threads but haven't been the subject of a thread as far as I can remember. I will have to check this out.

I use it with my bassoon. The flexible of the Helix makes it a good choice for us wind players.

Doesn't really help if you dump in 128 IR's (max limit currently), futz around for a couple of weeks setting up patches that ultimately end up using say a dozen or so of them, and then want to house-clean and get rid of the unused ones to make space to try out another IR pack. You have no way of knowing which of the original 128 you actually used, and no practical way of consolidating them into slots 1-12 as "keepers". As mentioned by others here, IR management on the Helix is brutal, and really IMO, the only half-baked feature that seems to have gotten no thought on how it would actually be a useful implementation during development. Everything else about the Helix is user-friendly and makes sense. IR management doesn't. Cheers

Let's count the different components John is using... Amp / Cali EQ within the AMP Cabinet 2 different microphones A mic pre-amp (not visible) Post production EQ/Comp (also not visible) That's at least 5 components, maybe even 6 or 7 components.... IMO, if you can do it in 3 or 4 blocks you are doing good! No he is not plugged into a Mark IV... he is plugged into his signature series JP-2C which is a spin off from the Mark V. I have not researched to see how it is voiced... but there will be differences or that amp wouldn't exist. To match the chain I see in the video.... IMO, this is what you need.... Mark IV Channel 2 Amp (if the Cali EQ is not included in the amp, then you need to add it as well) Dual Cab (mic choice I'd have to research...). Keep the mics at 1" - 2" Apply the title EQ after the cabinet then set it to DARK 20 or DARK 30 (this simulates the mic positions on his cabinet NOTE: You could use a custom IR for #2 and #3, but you really need to make sure it matches his setup since you have no adjustments with an IR Add the Studio PRE (that will simulate a pre-amp for the mics) Add the LA Studio Comp (that will simulate any compression that is occurring in the video. Voila - 5 blocks.... pretty much what John required in the number of components.

It depends on the type of cabs you are using. I am using a similar setup with very transparent cabs (Glockenklang) which are similar to FRFR cabs. With "character cabs" like a Ampeg810 or something similar, it might be hard. One approach is to use an EQ to compensate for the cabs frequency response: Pull out some mids (that are likely to be emphasized by the cab) and crank the highs (which are killed by the cabs). Another option would be adding subtle distortion which will add more highs and high mids - and through the cab it might not sound like "distorted". Can you describe the kind of sound you are after?

There are approximately 11,483 threads bemoaning the fact that volume leveling from patch to patch has to be done. There's nothing you can do except to adjust everything by ear. Some amp models are inherently louder than others, regardless of the where the channel volume parameter is set... it's just the way it is. Significant EQ differences can make one patch seem louder than another as well, even if their outputs levels are identical. If the channel volume doesn't give you what you need for a particular patch, the output block will.

I thought I had this solved by creating a new setlist instead of adding my presets to the default preset setlist. Hadn't had a sound drop in months, until today during rehearsal. Again it happened immediately after switching a preset during a song. I opened a support ticket with Line 6. I see various other threads describing a similar problem, so hopefully they have a fix for it by now. Until then, I am going to transition to using SNAPSHOTS ONLY for scene changes within a single song. Not sure if that is a viable workaround, but I don't think I've ever had the problem when switching snapshots. Sucks because there are a few songs in our set where I like a completely different amp model for clean vs. high gain, which means using preset banks rather than just snapshots. Would love to know if anybody else above has received a response or fix from Line 6 on this. If there is no solution, I will unfortunately have to give up the Stomp for something else. I think I will put a deposit on Neural DSP quad cortex just in case. EDIT: Just read in another thread that you can have more than one Amp block in a straight (i.e. un-split) Preset signal path, which I did not realize before. Therefore, it is still possible to have two different amps in a Preset and use snapshots to switch between them. However, it uses a lot of DSP, so you may find your choices for the second Amp(+Cab) are limited. And, of course, with only 6 blocks available on the stomp, you'll need to be creative/economical with effects. Still, IF this bug only occurs when switching Presets, this might be the best workaround for reliable live use.

I already said so elsewhere, but all that was required to export and import presets along with the correct IRs was a file management as we know from software samplers (or sequencers in general). When you export a patch, there should be options to save just the patch file, the patch file along with the used IR(s) or a consolidated file. Works exactly like that with, say, Native Instruments' Kontakt or Battery. Then, when you import a patch, it should automatically find the right IR(s) - in case it's loaded into the Helix already (fwiw, there should be a checksum check in addition to a name check). In case it's not, HX Edit should ask you to locate the correct IR or perform a search (entire filesystem, just a drive, just a folder). Once the right IR is found, HX Edit should ask you which slot to import the IR to (or just use the first free one). In case all slots are filled up already, you should be asked whether you wanted to replace an IR. Ok, this might introduce some (correct patch) data loss. So let's see for further things proper IR management should allow for to adress this: All IRs in use should be tagged as such. That way, you'd know which ones could be deleted easily. Should be a piece of cake to implement that (at least compared to some of the other coding marvels we see being done on modelers). But that still could be improved. When you select a loaded IR that is tagged as being in use, there should be an option to display a list of all patches the IR is used in. That way you'd know whether deleting the IR would affect important patches. It should further be possible to batch save all patches using a certain IR, so you could safely delete them (along with the IR). Amen to all that! It's 2020 and I still have to deal with truncated file names? I could actually understand if reading them would become problematic on some displays (so they would possibly scroll and it'd take a while for us to see the full name) - but truncation? Really, that's just embarrassingly Win95-ish. I would absolutely love to be able to free up large parts of my IR slots to temporarily explore larger chunks of IRs straight on the Helix, simply because it's just friggin' excellent to do that in pedal edit mode while playing. But it's impossible to go for that unless I do a full backup (which takes time and hence reduces fun instantly). And even if I decide to do so, what if I wanted to keep some of the fresh IRs? Take note of the fresh IRs I want to keep, backup all new patches using the fresh IRs individually, take note which patch uses which fresh IR, reload the backup, find slots for the fresh IRs, load the new patches, re-assign the fresh IRs to them. If it wasn't that sad, you'd think this was a comedy. Fwiw, just some days ago I imported a bunch of IRs and found some of them extremely nice. So I went crazy creating patches with them. Let's say like around 30. Now I want to throw the unused ones out but don't exactly remember which ones I didn't use (ignoring my own advice that I give to everybody asking me about these things, how clever...). In addition, I placed those IRs somewhere in the middle of the IR slots - but I'd prefer the 2-3 ones I'd actually like to keep be moved up to my first 30 slots (which I decided to reserve for "keep these on the unit all the time until there's a solution for the IR dilemma" duties), so I would have to re-assign them anyway. As a result, I will now have to try to remember all the patches I created ever since the IR import, write down the IRs used, delete the new IRs or move the ones used up and then re-assign them in the patches using them. And that was just dealing with a mere 10 (!) IRs. Now try to imagine what I would end up with in case I started to select IRs from the RedWirez Big Pack that way (which comes in with around 20k IRs). I'd likely spend the rest of my life taking patch-IR-relationship notes.

Yes. I did. After quite a number of fruitless efforts the actual fix was finally arrived at. The final fix was a completely different approach from all the other efforts which were basically nothing more than "try it again now." For anybody else who might be pulling their hair out making countless attempts that yield no result I can tell you that the eventual solution involved manually removing all related software from the computer and purging all evidence of it left behind in the form of driver files and system and environment files and then reloading from scratch. Even then, it still took a couple of attempts. The fix was not a simple task and it could not have been done by any kind of automated process or app. It had to be done manually and it's not a job for the average layman without a lot of help. Get your support ticket started, be prepared to wait a long time for them to get back to you and try, try, try to get them to jump to the end as quickly as possible because the first 20 steps are all BS. I have "closed" the support ticket but just because the situation is resolved does not mean I am going to retract my earlier sentiment. In fact, if anything, this experience has permanently cemented my opinion that Line 6 needs to spend a WHOLE lot more time making the update process simple, reliable and painless and a whole lot less time working on bells and whistles. There is absolutely no excuse for this unacceptable situation and expecting people in this day and age to tiptoe on eggshells around a common, everyday occurrence like a software update is unreasonable. Here is the lesson I have taken away from all of this. It is my intention to fabricate some kind of cover for the USB port on the back of my Helix. Something that is not permanent but is still a complete nuisance to remove. Something to remind myself (because I will probably forget six months down the road) that there is a 99.9% chance I will be better off not updating at all and just leaving it the hell alone. I have no intention of ever repeating this experience unless it is absolutely necessary.