[yoshimi] Re: Potential fix for LV2 envelopes

  • From: Kristian Amlie <kristian@xxxxxxxxxx>
  • To: yoshimi@xxxxxxxxxxxxx
  • Date: Thu, 1 Apr 2021 19:18:29 +0200

On 31.03.2021 20:20, Will Godfrey wrote:

On Wed, 31 Mar 2021 18:44:56 +0200
Kristian Amlie <kristian@xxxxxxxxxx> wrote:

On 31.03.2021 17:37, Will Godfrey wrote:
<snip>
It's very much dependent on buffer size. Less that 256 frames, and there is 
no
noticeable problem. By the time to get to 1024 frames it's really bad. But 
that
has to be be *both* Yoshimi's internal buffer size and the Jack buffer 
size.  

By this you mean that you also set Yoshimi's buffer size (in
configuration) to 1024 and higher? Did my patch introduce that problem,
or was it always like that?

It's not quite as simple as that :P
Although you can't change the internal buffer size in lV2, it is still
effective and takes whatever value was set standalone. If it is smaller it
just loops until the source buffer has been completed, but this of course
changes the envelope characteristics - well it did! Your patch fixes this.
However, in doing so it makes the warbly bit very obvious (only really bad at
1024 frames and above).

If the buffer size is set larger than the Jack one, you're just wasting 
memory -
so no real loss. With LV2 or an all jack setup there was generally no benefit
in a smaller buffer, apart from fixing both the envelope size issue, and
getting rid of the funky stuff. Having said that, some filter effects sound
better with smaller buffers, and maybe that's related to the warbles.

With Alsa MIDI and Jack audio, you can get better granularity with note, and 
CC
timings while not overworking the Jack graph.

Indeed, the patch is not a miracle cure, and there are still several
places which rely on the buffer size in an audible way.

You could also try with the updated patch in the PR. As discussed
privately there was a small... ahem.. mistake, in the first patch! With
the debug prints it was adding this could have adverse effects on the
real time performance. Though I would expect this problem to be worse at
lower buffer sizes, not higher...

Well I will anyway, but I don't think it's relevant to this - as I said I 
don't
think your patch is making an existing problem worse - just more noticeable.

Right. After reading a bit more, I think a realize what is going on:
What I fixed was the timing of the curve. IOW, the curve is now
guaranteed to take the same amount of time regardless of the buffer size.

However, I didn't change how the curve is applied, and this is
fundamentally tied to the block size. Yoshimi does not follow the curve
exactly, but simply crossfades the effect between the beginning and the
end of the block size. For small block sizes, this is very accurate, for
large block sizes, it is not.

What you get is always a block size which is the smallest of the
host-provided buffer size, and the block size you set in the
configuration. The only reason to increase the block size in the
configuration is better performance, otherwise it should be left pretty
low in order to get accurate results.

I'm not saying that this is the best way it could be. Certainly a better
algorithm could be devised to make the curve more accurate regardless of
the block size. But it's how it is now, and since you can always solve
this problem by reducing the block size in the configuration, I don't
think this is a high priority thing to fix. Maybe we could include this
info in the tooltip.

-- 
Kristian
Yoshimi source code is available from either: 
https://sourceforge.net/projects/yoshimi
Or: https://github.com/Yoshimi/yoshimi
Our list archive is at: https://www.freelists.org/archive/yoshimi
To post, email to yoshimi@xxxxxxxxxxxxx

Other related posts: