Therein lies a key challenge for product developers in trying to balance the competing (and sometimes mutually exclusive) demand of the user base. I have the scars on my back to prove it. The key thing to avoid is to p*** off everybody.
I have suggested in the past having some form of structured wish list for enhancements, but I’ve come round to thinking that there are other ways. The most important one is that the developers have a clear vision of where they are going, so they don’t get pulled down endless side tracks. IMHO I believe that @davide and his team has that clear vison and every indication for me is that the evolution of Scaler will be in a direction that suits me. So I’m happy to sit back and take whatever comes.
However, I think we need to distinguish between changes which are of function and those which are changes in data. . Tri-tone requires somebody to write some more COBOL or whatever (joke, @davide), whereas data variation should not.
So adding some songs (as e.g. Gospel) should be a different task to extending data. However, unlike the synth sounds (which are stored separately) songs appears as far as I can see to be embedded in the compiled image, which leads to an ‘all’ delivery
If I may be so presumptuous and bold as to suggest what is known in the trade as a ‘kluge’, if songs (or more likely their category) had a yes/no choice against them, ‘N’ could be used to just supress display. So the effect would be to have a user tailored list, whilst allowing Scaler to do the ‘all’ delivery. You just choose the songs you want to see. This requires a code change, but not as extensive as more elegant solutions. Crude, but effective ?