On 22.04.2025 22:55, ichthyo wrote:
Made good progress the last days...
Now I'm facing a challenge with the meaning of "yoshimi format".
Basically I try to rearrange the parsing / handling of headers,
because the goal is to get rid of direct MXML related data in the core
logic.
I want to get code directly touching XML into a small number of generic
backend-functions, and otherwise get all core logic removed from the
backend
and controlled from outside, from the caller...
I am still having difficulties to grasp the concept / the meaning of the
"yoshimi format".
The value of the DOCTYPE seems to set the flag (if its Yoshimi-data or
ZynAddSubFx-data). But then, even for zyn-format, a yoshimi version number
is extracted. Which is then somehow sneaked into the SynthEngine.
And the code 3 call levels above then evaluates this to give a
compatibility
warning. However, that code for loading the config has constructed the
XMLwrapper in the same scope and could thus just directly check the
yoshimi flag or version in the metadata. So maybe I'm missing some
crucial part which requires to pass that information out indirectly.
Furthermore, when loading, it is solely the extension found on the file
which controls what data is loaded. The header is evaluated, and leads
to setting the flag Part::PyoshiType. But this seemingly only controls
the presentation of some background colour of the label in the GUI.
Rather, the extension determines if an attempt is made to load additional
content for the controllers.
Anyway, in the end I can roughly see some convergence and it does
not seem to matter much, since the actual loading code always evaluates
directly if some additional settings are present. It's just that my head
is smoking right now when attempting to rearrange code while trying to
make it behave equivalent when seen from the outside.
I'm no expert on this code, but from a resiliency perspective, I think
that the the checking of each setting is more robust anyway. During the
loading, the question of whether it is Zyn or Yoshi really only comes
into play if a setting is truly incompatible between the two, in a way
that cannot otherwise be distinguished.
It would be nice if every piece of code that does need to know the
doctype and/or version number is adapted to use that, instead of the
extension which I consider less reliable. But this is arguably a job
which is unrelated to what you're doing, so take care not to overcommit! 🙂
On a related question:
Is it intentional that the UnifiedPresets always set the XML format
to Zyn, not Yoshimi? Does this mean that we intend that presets
(or clipboard contents? not sure about that?) shall in some way
be compatible and can be read by ZynAddSub?
Not that I know of. This sounds like a bug to me. Both the presets and
clipboard should contain Yoshimi XML, otherwise they may not work correctly.
Other than that, the instrument saving deliberately sets the format
type (based on the config setting if we want to save as .xiz or .xiy
or both), while all other usages in the code base always sets the
XMLwrapper::isYoshi = true
I guess we only say that we support it for instruments. I believe other
types of files would also work at least partially, although some have
diverged more than others (probably state has diverged the most). I
would not change this without significant testing though, and perhaps
comparisons of file contents.
--
Kristian
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
