[LAD] New kid on the block

[Mark D. McCurry]

On Wed, Apr 02, 2014 at 10:31:42PM +0100, Will Godfrey wrote:
> I, and a number of other people, have found that yoshi is consistently more
> stable, reliable and less prone to xruns under stress.
>
> ...
>
> I frequently use very large patch sets. zyn is unable to load  these even
> if it saved them. I'm informed that this has been dealt with in one of the
> development branches, but when that will appear in the release version is
> unknown. For me, this is a show-stopper.

In regards to this issue, I'm going to have to firmly sit with the approach that
I've been implementing in ZynAddSubFX for quite some time.
First, the overall issue is that both codebases have a lot of real time Faux pas.
The difference is how the projects have gone about trying to fix things.
In every case that I have observed in yoshimi where an xrun is less likely to
occur it is due to undefined behavior (almost exclusively through threading).
For the longest time the user interface has synchronized everything with a
horrid mutex, which was used in such a way that it really broke realtime
guarantees in quite a few dimensions, but when it was used it did ensure that
well defined program behavior was present.
I have seen a number of locations where yoshimi has simply omitted the use of
this with nothing else to stop nasal daemons from popping up.
This approach certainly can be seen as a shortcut to a better experience, but
it's not really a true fix.

I'm not encouraging the use of non-realtime operations at all, but in the mean
time I'll take a well defined error over undefined behavior.
As for a real fix, in what I've been calling the anti-broken system I've made
sure that this mutex is quite solidly dead and unsafe/costly operations do not
interfere with any audio generation.
This branch was quite time consuming to implement and the internals are working
quite well for the most part (and this conversion has also resulted in a number
of features that are getting fine tuned such as arbitrary midi learning, OSC
exposure of *all* parameters, basic undo, etc).
As per when this will appear in a release version, that will happen as soon as I
stop finding regressions in the user interface.
I cannot nail down any set timeline as I'm the only person actively working on
this part of the code and coding time varies wildly.

So, I'm fine with yoshimi continuing to plug along, but there seems to be some
FUD surrounding it's relationship to ZynAddSubFX.
This FUD goes back to some of the origins of the project when the code changes
were purported to drastically improve performance when 95% of that claim was
simply a basic change in compiler flags and those flags along with the 5% (and
then some) have all been integrated for those curious.

Does it appear to do some operations better than the current released version of
ZynAddSubFX?
Yes, loading a very large patch in the master version does end up blocking.
(In the ABS version this is simply a pointer swap)

Does it do so in a manner that is well defined and maintainable?
Not in my opinion

--Mark McCurry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20140402/2e2b3a36/attachment.pgp>