On Wed, 23 Apr 2025 10:38:20 +0200 Kristian Amlie <krist...@amlie.name> wrote:
>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. The Zyn format, is the instrument file frozen at Zyn 2.4.1. I've been told that this is still recognised by recent versions of Zyn. However later version of Zyn are NOT recognised by Yoshimi as they have changed some representations from chars to floats but not in a backward compatible manner. The Yoshi format is this Zyn format with extensions added. In particular it includes all the part level controls in the bottom half of the main window. I think this should include the OMNI control (I haven't checked that). This was requested by one of our users, as all of these can make quite dramatic changes to the sound. None of the rest of our file types would be recognised by Zyn. I probably should have used a different extension for patchsets instead of XMZ, but it's a bit late for that now! These days, the extension is used by the file manager to quickly identify valid data so you only see files of the type you're managing. When loading, the XML code also checks the header as well. Presets are 'unified' in several ways. Firstly the clipboard uses exactly the same process as the saved files, simplifying the code. A new clipboard entry simply overwrites any existing one of the same type, so if you stop, then start again later, or there is a crash (surely not!) you haven't lost that information. Next, it's available to the CLI now, and finally it's presented in the GUI in a human comprehensible form :P There is no need for presets to distinguish between Zyn and Yoshi as there are only clips from effects or instruments (not full parts). As an aside, while going through this I discovered there was an error in the formant filter preset. It didn't store all the data for the individual formants. It does now. There's probably stuff I've forgotten, but i hope this clarifies things. -- Will J Godfrey _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
