In Seq66 I've added a version ordinal to the configuration files so that
older versions can be detected, read, then upgraded to the new version upon
writing. The other trick I use is to look for the new stuff, and if not found
assume the old stuff, when that can work.
-------- Will Godfrey 12:27 Thu 18 Mar --------
This concerns a bit of Yoshimi history.
When I first started identifying controls for CLI access and what was to become
the control block structure. I simply used numbers loosely based on the
existing ones taken from both the actual parameters and the GUI. However, I
created significant gaps to allow for additional entries. At the same time I
built up the Yoshimi Control Numbers spreadsheet in dev_notes so I could keep
track of these.
Much later, when even this was getting cumbersome, I built up the enum lists of
labels so the direct numbers were no longer needed, at which point it seemed
new controls could be inserted just about anywhere and the code would
automatically track the changes. When these are saved in XML files, they are
given textual names, not numbers so compatibility was maintained.
However I forgot about MIDI learn!
This saves and loads numeric values so can be confused if the numbers change.
And numbers have changed :(
So far, nobody has complained, but I don't know if that means nobody has stored
the affected controls, or if it's that they haven't called on these files since
the changes were made.
First off, because of this, and just for MIDI learn it is pretty much impossible
to maintain *backward* compatibility before V2.0.
However one extremely laborious way of resolving this in a forward direction,
is by finding the versions where the changes took place, and when loading check
the version number in the file (it's stored in all Yoshimi's XML files), and
make appropriate corrections. I've already made a note in 'globals' to watch out
for this, so that would hopefully be the end of the matter.
An alternative is provided by the fact that we also include a text description
of the command, and it would be possible to parse this in a similar way to that
used for CLI access. This would slightly slow down loading complete learned
list but would not otherwise detract from performance. It would always read the
correct controls. Doing this would take a while to code and would bulk out the
code somewhat.
This text is exactly the same as what is used for reporting to the console or
CLI so it's only the loading that needs to be sorted (CLI entry uses slightly
different wording for convenience of entry). We would then not need to store
the numeric values at all but instead rely on the text.
I'm open to suggestions - as usual.
For the time being, I want to back off from coding, and concentrate on the new
User Guide. The only code that needs to change is the MIDI learn code itself -
whatever route is taken, so if anyone wants to take this on I'd be *extremely*
grateful.
Finally, this becomes urgent if (when?) somebody complains. That would dent our
reputation :(
--
Will J Godfrey
http://www.musically.me.uk
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Yoshimi source code is available from either:
https://sourceforge.net/projects/yoshimi
Or: https://github.com/Yoshimi/yoshimi
Our list archive is at: https://www.freelists.org/archive/yoshimi
To post, email to yoshimi@xxxxxxxxxxxxx
