While i think the localized strings can be included with the next (or the
next release of MPT, i plan on making some drastic changes, not only in regards to the GUI customization discussed in an earlier thread, but also in the refactoring of the code modules (standardizing the variable names, separating classes into smaller, more manageable files, etc.), as well as a streamlining of the composition process for the user (making it easier to jump in and compose with little knowledge of the interface and with as few steps between inspiration and composition as possible). Would it be better to put these kinds of changes in a SEPARATE build, or would it be better to definitely include drastic changes in the current build, but user changes made optionable (which will make it more work than it'll already be)?
A lot of this has to do with the overall directive we all share with ModPlug: which changes are too much change? How far do we want to go from the original concept? For example, i can -- given time and a little more expertise -- cut the tabs from 5 to 3 (Samples/Instruments, Patterns, Mixer/General), make the channels & columns hideable, and even add tabs to the mixer page. Perhaps this grand idea of simplification might be too much change. (On the flip side, i don't want to make the page so complicated like Renoise.) But i've made a lot of my own requests over the past few years in which now i can see the work involved in implementing them, but i'm almost at the point where i might be able to grant my own wishes.
The first step for
anything is to "deconstruct" the code modules -- separate the classes from each other (where reasonable) so that changes can be made easily, although we'll be adding a lot more #includes. I want to break them down to basic parts. Some of the parts may need to be given some surgery to separate the "organs" as it were! I will also hafta figure out how to test that my changes have not broken something we've all grown to love. (Apparently the VSExpress d/l has a debugger application that may help me there.) While a lot of this refactoring will require lots of time, i consider it menial work, in the sense there are greater magicks the wizards can work on, while the apprentices (like me) can spend time learning the scrolls while transcribing the original phrases -- to continue the metaphor. :wink:
One of the reasons why we should compartmentalize the classes even more is to make it easier not only for future development, but also for future porting. For this reason, i am also writing up a spreadsheet reference on all the variables and methods, and descriptions of each, what they do, and which other functions they call or call them. VS has the "which-goes-to-which" feature as well, but if i were to add all the descriptions to the code files themselves, i'd end up with more comments than actual function! :wink: Only problem is, if i'm going to do this reference, i hafta find and list all the variables, enums, and functions, then figure out what they do -- and it's not always obvious. Hell, it took me a while to realize that most of the function parameters in the .h files were DUMMY variables.
But if all goes well, the code will be a LOT easier to amend and emend, transfer to other programming "dialects", and generally just explore and work with. I remember one of us remarking many, many months ago that the code was too "tight" to make any big changes. Now i understand how. My goal is to loosen up the code and make it a lot more malleable. I understand it won't be easy, nor quick, but we've all agreed on the ship, now we need to make sure we're using the same map...
I'm interested in the thoughts of programmers and users alike on this subject...