Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[David O. <da...@ol...>]

On Monday 12 January 2004 17.36, Mark Knecht wrote:
> On Mon, 2004-01-12 at 08:13, David Olofson wrote:
> > > I think priorities could address my request. If the first X
> > > number of voices for any gig were high priority, then the
> > > piano's 50th note couldn't steal the violin's 1st note no
> > > matter how soft it was.
> >
> > That should work - and it has the advantage of not having to
> > figure out some "sensible" number of voices to reserve for each
> > gig, MIDI port, MIDI channel or whatever.
>
> And gives the user some control. If this could be a per 'port'
> setting in the LS GUI that would be pretty cool. (A 'port' in GSt
> is the place a Gig file sits and responds to  specific MIDI
> channel.) If I could say my piano will always get 10 voices, my
> violin will always get 3, etc., then I can tune that song by song
> as necessary.

Yeah. That's what the Roland JV-1080 and later synths do, BTW. Seems=20
to do the job, but most of the time I managed to get away without=20
using it. (64 voices and not too many sounds with extremely slow=20
releases. And some other h/w at times...)


[...]
> > Those 85-90% doesn't add *that* much to the experience, though!
> > ;-)
>
> Well, around library developers I think this statement verges on
> the religious, so I won't respond about their value beyond this
> sentence. ;-)

*hehe* Well, let's hope they don't take that more seriously than it=20
was intended! :-)


> That said, I think my point that by adding the release sample
> support sooner vs. later in LS would allow us to improve the disk
> handling of samples, better look at the overhead of the envelope
> generators (and all the other stuff like LFO's, looping, etc.) and
> thus better benchmark how well we're doing vs. the GSt solution. I
> can run GSt and LS on the same machine with the same sample drives
> and same sound card. It's about as apples to apples as we're going
> to get.

Yeah. The disk streaming and voice mixing (mostly a memory bandwidth=20
thing with simple interpolators, I think) is probably the most=20
critical part WRT performance. Next would be filters and stuff, but=20
control structure and most "little features" probably don't have that=20
a massive impact on performance.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---