Re: [Linuxsampler-devel] Re: Gigasampler curve types

[Mark K. <mar...@co...>]

On Mon, 2003-11-03 at 07:01, be...@ga... wrote:
> Scrive Simon Jenkins <sje...@bl...>:
> 
> > Mark Knecht wrote:
> > 
> > >   Another 'bug' I notice, or maybe a limitation of the GSt coding, is
> > >that the first 2-4mS of a new pulse has the volume of the pulse
> > >preceding it, and then the right volume. I want to look at this more
> > >later. I'm wondering if this could be some psycho-acoustic thing they're
> > >doing? (More likely just a mistake...)
> > >
> > Maybe they're lowering latency by starting to play a note before they've
> > seen the velocity byte? Even after they've seen it - depending on how the
> > engine works - they might have some just-in-time fiddling around to do
> > before they're ready to make use of it.
> 
> that would IMHO be totally silly.
> You would save about 300usec (transfer time of 1 MIDI byte) plus
> what if you play a loud C1 and then a very soft C4 ? I guess this 5msec
> part of loud C4 would be very disturbing (if really present).

I agree. It doesn't make sense, and it doesn't happen on every note. It
only seemed to happen on notes where GSt was making a larger
quantization change. 

However, please remember this is a data point of 1. I had my Hammerfall
Light set at the smallest buffer size, which could effect it. I may not
have the latest update of GST (although I think I do) which could effect
it. It could be based (somehow) on the driver for my sound card. 

Anyway, I just reported it since I think it's better to have the data
out there. It might make sense to one of you, or to someone who joins in
later. It makes no real sense to me, and I don't think that we should
try to do anything like this until we have a good reason to do it.

> 
> Even this velocity curve quantization looks silly to me, it will make
> note volumes more static thus I think it will hurt to note dynamics during
> playing. Let's do it right (mapping the approximate curve but without
>  quantization).
> 

Yes. Having thought about this overnight, I'm pretty sure there is some
major bug in the way GSt does its internal mix buses. The MIDI Velocity
curves and what they are doing to output volume just look really ugly
when channel volume is not at its maximum. I can tell you that I will
never again use GSt with the volume set to less than maximum. 

The curves themselves don't look that bad to me, albeit a bit strange.
What reason would someone have for deciding that some arbitrary number
of high MIDI velocity events should all produce the same volume? The
only reason I could think of was that some MIDI keyboards, no matter how
hard you hit the keyboard, do not produce a full MIDI Velocity range.
Maybe the idea was to give people a way to get more dynamic range out of
GSt when used by that sort of keyboard? Someone on Linux-Audio-User or
PlanetCCRMA was asking for exactly this sort of support in the last
couple of weeks. Possibly that was part of the reason?

None the less, GSt is so badly documented that it takes me 3 hours with
Pro Tools to start discovering this stuff. Normal folks aren't going to
do this, and their also not going to know what range of velocities their
keyboards are producing.

Should we have a Linux app, inside of LS or stand-alone, that allows you
to get this data from your keyboard and 'tune' LS somehow to get the
right dynamics? I think possibly yes....

Cheers,
Mark