As part of the changes, I had to understand some aspects of the usage
made by Yoshimi's core code, and especially the version and compatibilty
checks turned out somewhat difficult to understand, since this logic
has evolved over a long time and the implementation was partially
in Config, partially in the XMLwrapper.
First to mention, to test the changed behaviour, one can load an
existing file, save it back and compare both with a diff tool.
For this to work, you need to set the "gzip compression level" to 0,
so that it becomes possible to read the actual XML data on disk.
You will notice some minor changes, like line wrap, and a small
number of attributes which I have rearranged (waveshaping before
filter, and the bypass of effects). Furthermore, I have changed
some toggles in the config storage to bool parameters (which
is now implemented backward compatible, but obviously is not
forward compatible, i.e. older versions of Yoshimi will fail
back to the default settings of these toggles)
Please consider these changes as proposal and feel free
to question and discuss anything...
Regarding the compatibility check, I tried to re-create the
existing behaviour, as can be inferred from code and Git commits.
But I have not automated it a bit more, and removed the build variables
MIN_CONFIG_MAJOR |MINOR
However, I am not sure that this behaviour is actually what we want,
because it will warn on each regular upgrade of Yoshimi. This is
probably a very defensive approach, because usually we care very
much to provide a soft migration whenever we introduce changes.
- right now the rule is: warn if major or minor version differs
- an alternative rule would be: tolerate one minor version back
and on upgrade of the major version, tolerate all minor versions
from previous releases, but always warn when loading config
from a newer version into an older Yoshimi.
This logic could be easily implemented in code
- yet another solution would be, to handle compatibility slightly
more manually; we could add a new build var COMPATIBLE_CONFIG_VER
with a string spec into the CMakeList.txt -- as you may have
noticed, I have implemented a parsing function for version
specs, and I have added equality and ordering predicates
(see Misc/VerInfo.h and the implementation at the top of Config.cpp)
Any thoughts?
Another thing which I've notice (but not changed) is the fact
that Bank::generateSingleRoot() always stores the new files
in Zyn-format. Was this done intentionally so?
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
