Re: [yoshimi-user] An exciting discovery! - further thoughts.
- From: Mark McCurry <mark.d.mccurry@xxxxxxxxx>
- To: yoshimi-user@xxxxxxxxxxxxxxxxxxxxx
- Date: Sun, 14 Oct 2012 15:04:35 -0400
I think I now understand why Cal went for the DB idea (that Mark was so
hostile
to).
Just to clarify, it was not the DB as a replacement of XML that I
intended to be hostile towards, it was the replacement of the
parameter structs with the DB.
This appears to introduce far too tight of a coupling between the
synth code and the DB itself.
I honestly do not care too much about how the data is stored on disk,
but if sane behavior is to be seen there are certain requirements for
the in memory storage, which I suspect the DB botches up completely.
Hyper Matrix is 580k of xml, whereas simple voices are around 5k. Before doing
anything else, all that xml has to be parsed - which is obviously going to
take
a finite time.
Yes, though this does not need to be spent in the RT thread (though it
currently is in zyn as I have been bogged down far too much to fix
that properly).
Also, for MIDI controls to work efficiently, you either need to parse the
filenames or have the files in each bank to be strictly in numerical order,
with
no gaps - no prizes for guessing which will be faster! Also, of course, to be
MIDI compatible you can only have 128 voices per bank.
Unless I missed some code yoshimi and zyn both store all of the
instruments names in the Bank class which should be sitting around.
If many instrument swaps are expected on multiple channels, then it
would be logical for this to be on the part level, but it was
previously on the global level.
(or as indicated below some metadata on all instruments could be kept
on the global level)
The DB does away with all of these problems, but creates problems of its own.
Honestly I do not think that it solves these problems, which is not to
say that they have not been solved via other means within yoshimi.
It may result in smaller images, but it should not be too huge of a
difference when compared to compressed xml (though IIRC yoshimi
disabled that a while back).
Phew!
Ideas?
Good?
Bad?
Unless I have misread something the proposal is an optimization for
something that takes a fairly small part of the time required to load
an instrument.
If this is aimed at full realtime swapping, it is not something that
is really possible (without keeping all possible instrument in
memory).
One of the issues is that loading a patch does require some
fundamentally non-realtime operations to be performed, (like PADsynth
generation), which is why I mention the above.
Apologies if this seems ranty.
As per the topic of the zyn/yoshimi relationship I should send some
mail this next weekend on the topic, but my studies are consuming at
them moment.
--Mark
Other related posts:
