Some of these presets might be ok as starting points but they take up space for the most part. You can save them to the user bank but why are we not able to overwrite some preset that will never get used and isn’t contributing to our needs?
Here’s a previous discussion on this topic:
1 Like
I didn’t see any conversation in my search either. Another reason to post the question I suppose. It’s only a minor issue for me . The first thing I want to do with any gear is make my own presets and sounds. I don’t want to be stuck living with NDSP’s sounds / presets living along side within a device I use and personalize for my sounds. I don’t want to see them or know them or read the titles. Just my own personal thing. I might put the QC back in it’s box for a while and take a step back and look around at some other options. Lots to love but theres a very long way to go.
I also ignore the factory presets and build all of my own custom presets from the ground up to suit my needs. There’s enough memory space for me to make all of the presets I want, more than I will ever practically use, that the thought of needing to delete factory presets has never crossed my mind.
1 Like
Getting the modeler that is right for you is a worthwhile quest. I wouldn’t let the factory presets be a deciding issue for you though. As @DiffractionCircuit pointed out, there is plenty of additional space for presets.
Although Neural might still have a long way to go, you are coming into it when some fairly substantial additions appear to be right around the corner, including the editor. With that said, it comes down to what features are most important to you, and, if they are not here yet, how long you are willing to wait for them (including forever).
I will say this, I have spent time with the Helix, Fractal FM9, Boss GT-1000, and the QC. They are all excellent devices, each with their own very distinct strengths and shortcomings. There is a lot to love about the QC and you may want to give yourself a little time with it. It is a fantastic modeler with the best screen on the market, and no one else has put this many switches into such a compact footprint. That alone makes it singular in its readiness for travel or potential for placing on a pedalboard with other stomp pedals.
Good luck with whatever you land on, but the QC is truly worth giving a thorough trial. Lovin’ mine!
1 Like
Thanks for the insite. Iv’e been using my QC for a year and I agree alot with what you are saying. The overwrite preset thing is not a deal breaker all.
1 Like
Just chiming in that I would LOVE to see this implemented. My issue is if my unit crashes live, it reboots into the factory presets folder which costs me critical seconds in front of thousands of people. Why are we forced to have 1A patch be a factory preset? I don’t see any reason why a user couldn’t customize this.
That is odd behavior as I can power my QC off and or it can lose power and when its back on, it always starts on the last preset I was using at the time as designed. I guess it’s possible that after a crash it will land on the factory preset but I don’t have crashes and can’t validate that behavior unfortunately. I hope support can get to the bottom of your issue quickly!
Yea it’s specifically after a crash… it definitely recalls the most recent preset under normal circumstances, but after a crash they’ve programmed it to go to 1A factory preset (I assume because they don’t want to auto-activate the plugin that crashed and result in an infinite loop). However, I’m a big boy and I really would like the ability to specific WHICH preset (besdies 1A) to default to specifically for playing live. If my preset 5A crashes, I would like the ability to tell it “reboot to 5B, because I know that one is stable”. Very specific use case, but as a live musician these are things you think about!
1 Like
+1 on being able to overwrite all factory presets since that’s valuable space/real-estate for users…
FYI Fractal allowed overwriting all factory prestes but you could easily restore some or all of them from resource files…
So what do you mean by a “crash” if not an accidental power loss? A bug in the software that just happened to surface while you were gigging? How likely is that to happen for the first time when you are on stage? If some aspect of your preset or scene would be the root cause of a crash, wouldn’t you have encountered it while running through your set? I have a hard time imagining when/how this crash could occur.
You may not be able to imagine the possibility, but I live it. I have a patch that works 99% of the time, but the 1% is catastrophic.
If they allow us to specify a “post crash” patch, then no. For my use: I have one patch I use live, and it works 99% of the time (high DSP), but the 1% is a catastrophe. This is not “the first time I’m on stage”… it’s a patch I use for my band that pushes the DSP into 70% range, and ONCE IN A WHILE it crashes. If that happens, I want to be able to specify the QC to reboot into an alternate “safe” patch… which might be 80% of what I would want live (my main patch that crashed), but would at least get me through the rest of the show.
1 Like
1%? Your other thread made sound like it would regularly crash within minutes.
Listen dude, I’m not gonna sit here and argue with you over dumb sh!t. Regardless of the percentage, I have consistent problems with my unit. Support hasn’t been helpful, and I’m simply giving feedback based on what would be helpful to me as a gigging musician. Not here to debate whether or not it’s OK to give feedback or somehow make someone “right vs. wrong”. You win bro, no changes needed. Have a good one!
OK, I hear you. Since the preset is CPU-heavy, maybe you can use some process of elimination to find what effect or combo of effects causes the glitch. And you would want to select this problematic preset to return to upon booting because it’s an almost certainty that the reboot would be needed because of this particular preset glitching? I guess that makes sense but sounds like treating the symptom, not the cause. You should be all over NDSP support to try and solve the issue, but sounds like you tried that.You would think that after an Abend (abnormal end) there should be an automatic facility to save a memory dump so that support could analyze it later.