Perhaps this is part of the problem for us on the outside, not understanding your work flow. And not that you owe us an explanation of that, by the way. It's none of our business.
But when you say we really had to do "everything else" first, it's confusing for us morons, who don't understand why you "had to."
It’s important to remember that these devices are primarily software with dedicated hardware to support it. In software development, especially when working against a roadmap of future features that are where the company wants the product to go, and a long-standing wishlist of requests from the users, the team has to find the changes and additions that add the most “bang for the buck”.
In other words, if they add code block A, and it only supports future feature 1, is that a better development effort over B which supports 2, 3, 4 and 5? No, it’s not. In my past lives we’d go with the code that supports more subsequent features. What if A can be knocked out in an afternoon and B will take weeks? Then we'd hash it out in subsequent meetings and decide priorities and add them to the project timeline, and we'd stick to the timeline unless something huge forces a change, because humans suck at context switching, and switching back and forth to different tasks is an invitation for bugs in the code and major discontent in the workers.
Fractal maintains a set of master wishlists for bugs and wishes. If something is not on the list it doesn’t mean they are ignoring it, because the lists are periodically curated, instead the odds are good it will be added during the next cycle. At the same time it doesn’t hurt to participate in the thread for that request to help shape what is being asked for and show it is important to you
and why. If one person says they want something without any sort of specifics then my teams would have read it and shuffled it into the “for further consideration” stack unless it’s obviously important and the features are clear. If a bunch of people asked and helped define the features then the request would get a lot higher priority, but maybe not top priority because it still has to fit into the timeline and other coding efforts.
The idea is that there are intelligent decisions made to get from point to point in the product’s feature growth, based on the company’s resources, it’s not a crapshoot, nor is it whim or fancy. They listen, they provide a view into what has been requested, it’s for us to look and then trust them to work toward something that is in the best interest of the product and the company and all the users/customers.
In other words, I would trade this entire update and everything in it for an improved Virtual Capo. The amp improvements, the block improvements, the UI improvements, all of it, etc.
This is where we differ. I have absolutely no use for that.
The user base has a wide variety of styles, and while some play a style that would use it and want that, others see it as an “oh, there’s that for them” feature. And Fractal is aware of the user base so they try to prioritize, again based on the project timeline. That something is not there is not a personal attack that some make it out to be, the inclusion or exclusion is based on hard limits in processing power and the goals for the product with a little steering from the community.
[...]
So we ask ourselves, is it that Virtual Capo improvements are impossible to do, or that other things just had priority (had to do "everything else")? Again, you don't have to answer that question. But it is something at least some of us are wondering. And it can be difficult to understand why it is more important to improve a block 3 or 4 percent when a major feature for live gigging is not usable.
Because the "3 or 4 percent" that was seen in that block might be the tip of the iceberg of a major code optimization that will affect other effects, or maybe even enable them to exist. Those improvements in speed and efficiency could make all the difference in getting the improved tracking you want. That they're chasing those improvements says a lot about Fractal. I'm happy for every gain in the system, every improvement in the modeling or flexibility. Those make the unit even more powerful and useful, whether I use them or not.
I think these are legitimate thoughts to have on a forum that don't deserve other forum members telling them to "buy something else."
While "buy something else" might seem abrupt, we're expected to do that in real life in so many other devices we use, from our cell phones, to our TVs, cars, cameras, amplifiers, effect pedals, etc. We're expected to analyze our needs, make a purchase, use it and determine if it truly meets those needs, and if it doesn't, what do we do? We return it or sell it, and "buy something else."
Railing at the company
sometimes works when a product that already has a feature turns out to have defects in the design. In my experience, only security and safety defects get addressed consistently. Fractal is a shining star when it comes to their products and their responsiveness.