Re: [yoshimi-user] An exciting discovery! - further thoughts.

[Kristian A. <kri...@am...>]

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