Re: [yoshimi-user] An exciting discovery! - further thoughts.
- From: Kristian Amlie <kristian@xxxxxxxxxx>
- To: yoshimi-user@xxxxxxxxxxxxxxxxxxxxx
- Date: Mon, 15 Oct 2012 19:32:34 +0200
On 10/14/12 21:04, Mark McCurry wrote:
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.
I will have to agree with Mark here. If you follow the realtime
programming guides, absolutely no I/O is allowed in a realtime thread.
Both xml file loading and DB operation do I/O, so either one is bad,
even if one may be a little better. The reason is that although such
operations are usually fast, they can't be guaranteed to *always* be
fast. So loading patches safely in realtime simply isn't possible in the
general case.
With this in mind, I think we have to go for one or the other, either:
1. Keep all 128 banks in memory. A "load" in this case will simply be to
point at a new parameter struct.
2. Accept that loading may take some time, and do it in a non-RT thread.
(I'm guessing it's done in a RT thread now? Since there are clicks I
mean...)
I'd vote for the second option, as keeping 128 banks in memory seems a
little excessive to me. With a lot of PADsynths you can eat up memory
quite fast.
--
Kristian
Other related posts:
