I’m also waiting for that.
AX8 is great there.
Kemper Stage too.
Even the humble Atomic 6 (I love it) has a very interesting and flexible approach to it.
What does it all mean?
It means we will have a very good hybrid mode with our QCs. Granted 
2 Likes
I really need scenes on the top row and stomps on the bottom row
I’d like an hybrid mode where I can choose what does each footswitch do.
Why should it be limited to top row and bottom row and only 2 modes instead of 3?
The greatest way to do it is that where you decide, for each footswitch, to be preset, scene, or stomp.
4 Likes
An easy thing to integrate that would vastly improve the flexibility in stomp mode would be a flip-flop capability (like on GigRig Quartermasters). All you’d need to do is add a flip-flop switch next to the foot switch number assignment button - this could then simply be toggled on or off per device/block.
…it would also be cool if they could add secondary functions to foot switches; for instance, a double press toggles between alternative settings &/or devices (i.e. cycling through alternative drive pedals that one has inserted on their grid). Momentary functionality would also be cool as it would allow the user to add specific functions to pressing & holding a switch (I’d personally like to use that for pitch shifting effects like one can on the Digitech Whammy DT). If both of these things were to be implemented then each foot switch could be used to activate or deactivate multiple devices (all drive pedals stacked on one foot switch for instance) & also to execute specific tasks like pitch shifting, volume swells, hold functions etc. with a press & hold.
The more I think about this request, the simpler it needs to be. Instead of the Top Row THIS, Bottom Row THAT, just have a toggle on every footswitch to make that switch STOMP or SCENE. The user can then customize the eight switches however he/she needs.
That function, combined with Option for MOMENTARY would open endless options.
Imagine a Momentary Scene that turns on Tremolo, Distortion, Octave, etc, just for a measure of the song (or whatever you need)!
2 Likes
I like it. That would be incredibly powerful
1 Like
Thanks. I think we tend to overlook the much simpler solution sometimes. Just make each footswitch’s function defined by the user, not by row, etc.
1 Like
I’m starting to worry that no matter what they implement it’s not going to make everyone happy
1 Like
Well done, that was a much simpler way of putting what it took me two posts to say (minus the secondary functionality that is but perhaps that complicates matters a bit too much)! Haha.
Is there a way of modifying your feature request to reflect that or will you be posting it as a new thread? I’ll definitely cast my vote for flip-flop capability (i.e. independent assignable scene or stomp modes for each block) & assignable momentary functionality. This would be my number one priority request but I didn’t want to post it as a whole new thread when you already had this one going.
Perhaps a moderator could chime in as to whether my idea should be a new thread or making the programmers could take this idea into account if other users like this evolution of the request.
Apologies, for some reason I thought you were the person who created this thread (my mistake).
I’d like to think they take everyone’s comments into account when reviewing these feature request threads & you echoing what I had already said should only strengthen our case. The hybrid mode is apparently on the way though so I guess we shall soon see! 
IMHO it would be best to close this feature request as soon as ‘top row / bottom row’ hybrid mode gets implemented. Freely customizable footswitches should be addressed in a dedicated feature request. In the end, we don’t know how many of the voters in this thread voted exactly for ‘top row / bottom row’ and nothing else. Therefore it’s not unlikely that a feature request dedicated to full customization may get less votes and a lower priority compared to other highly ranked feature requests.
3 Likes
Scenes and stomps too. A choice for either.
Sorry to trot this old chestnut out again but I sincerely believe that limiting feature request votes to a total of twenty is still causing a serious issue with getting accurate results for the features that are most desired by the community.
My guess is that if you did a deep dive on the underlying vote data you would discover that most forum users, at least the ones with a tendency to vote, tend to exhaust their votes fairly soon after they join the forum. Some small number of them may then consistently manage their votes well enough to pull votes they previously casted from features with many votes, in order to reuse them elsewhere. However, I would be willing to wager that over time, voters weary of that practice and just resign themselves to being out of votes to cast for features they deem equally important as the ones they already exhausted their votes on. I know that is the case for me.
The worst aspect of vote limiting is that it actually makes really worthwhile feature requests, particularly ones that have been created more recently on the forum, appear as if they have no support. When in actuality, they may have large support from forum users who simply have no votes left to cast. In that event it would almost be better not to have the feature request at all, rather than having it artificially appear to have no user base support.
There are simply too many critical or desirable additions that need to be added to the current firmware for a twenty-vote limit to encompass at this time. Not that the QC doesn’t have some unique features of its own, but there is probably a punch-list of, I don’t know, perhaps 50-100 items, that need to be addressed on the QC to get them into the same ballpark as Line6 and Fractal in certain respects. Nothing wrong with that on a fairly new product but let’s at least implement a voting model that is most likely to get them properly prioritized. As the QC matures a twenty-vote limit may prove to be adequate, but not right now.
I do hold out some hope that at least after the 2.0 firmware release, some of those votes will be restored automatically as the features they applied to appear in the new firmware.
Anyway, apologies for harping again on this vote limit subject but I truly believe it is adversely affecting the perception of which features are most important to QC users.
3 Likes
Right. I do feel we should vote for everything that makes sense.
1 Like
This is essentially how things can be set up on the Helix. And it’s pretty easy to change to the all presets mode by pressing the bank up and down at the same time which swaps to that layout.
I’m moving from a Helix to the QC, but there are some interface things the Helix definitely has a leg up on. Most of it is just convenience and not deal breakers (lack of stomp mode was one deal breaker for me though).
I see your point but nevertheless I‘m against increasing the voting capacity due to a simple fact: more votes on even more feature requests doesn’t change anything about NDSP‘s available ressources for developing and implementing new features. You may have noticed how long it takes to implement only a few of the top voted features. It won’t get better with even more votes on even more feature requests. Also, it‘s unlikely that features in development will be put aside just because there is suddenly another new feature with even more votes. Let’s not ruin the options we have as a community. Voting is always a matter of choice. You can’t have all at once but you can choose what you would like to have next / ‚sooner‘.
1 Like
The best lesson to take away is that they DO pay attention to the features requested here. They are slowly knocking out the top voted requests. The system works. The amounts don’t really matter, it’s the relative rankings and that’s the same with 10 votes as it is for 100 - in fact 100 would be worse because it forces no one to actually prioritize what IS important to them. If you have $1M you spend it very differently than if you have $100
3 Likes
Yes, you blow through $100 by Wednesday and don’t have enough money left for food for the rest of the week. Similar to the way people stop voting when they run out, regardless of how delicious those other features look.
Neural is knocking out many top requests. While I’m confident they are looking at the votes, I would think at least several of those features would be on any modeler company’s list of things to deliver in the first couple of years. There were some nice surprises as well.
You make a good point about relative rankings, but I believe those are still being skewed by limited allotment of votes. The most popular feature requests at this early juncture are pretty much what one would expect. Are there enough data points yet to show a direct causal relationship between the voting and the latest update, or an internal Neural development strategy that is tied to voting? I have no idea. Maybe.
The updates that come later in the QC’s lifecycle will probably be more conclusive on that point. Definitely not looking to die on this hill though. Just some good-natured speculation going on here. Voting is relatively trivial in the scheme of things although done properly it can help point Neural towards the user community’s top ten (or hundred). Particularly when it comes to the features that might not be as obvious or intuitive to the product manager. But there’s no time for vote quibbling now. There’s new stuff to play with! 
1 Like