Re: [Linuxsampler-devel] NI Kontakt vs Halion performance (voice count)

[<be...@ga...>]

Scrive Mark Knecht <mar...@co...>:

> On Thu, 2003-10-30 at 09:54, be...@ga... wrote:
> 
> > I have to admit it NI Kontakt is damn efficient but I think we 
> > can achieve a similar number of voices.
> > (let's wait for the envelopes, sustain pedal etc working then 
> > we will able to produce useful numbers)
> > 
> > Benno
> 
> Benno,
>    For many, if not most of my GSt libraries, I think that even the
> current version would be almost usable musically if we had both the
> sustain pedal and at least got rid of the annoying clicks with some sort
> of built in envelope. With that much working, I'd probably start using
> it with Pro Tools just to see how things really work. (I.e. - polyphony
> issues, stability, weird little things that pop up but you don't find
> until people really use it.)
> 
>    Granted, it would be one library at a time, and may not exactly
> duplicate GSt's operation identically, but would possibly be useful
> enough that we'd get a few users, like folks in the Rosegarden or Muse
> communities, to take a more serious look and do some extended testing
> like I'm doing.
> 
>    Don't go at this idea too fast, or look for too many people too
> early, but just keep the possibility in mind. Instead of implementing
> full blown ADSR's, just build in a fail safe click eliminator and then
> turn us loose! ;-)

While your toughts make sense I don't think that this hack will be
that beneficial since it still takes away some time.

Basically what we need is to allow more than one voice per midi key
(for sustain and multiple note-ons on the same key) this means
we need to add a linked list per midi key that represent the active notes
on that key (if the hold (sustain) controller is on, delay
the note-offs etc).

Sustain is relatively easy to implement (GSt style, just add new voices
 if the same key is pressed multiple times).

As for enveloping, a simple release envelope is not THAT hard to implement.

So in theory with a bit of hacking I could provide the features you need.

The question is as said above, will that be beneficial in this development
phase ?

I'd like to hear the opinion of a few list subscribers before deciding
to hack in this stuff. (but I'd prefer to go the full enveloping route).

Anyway keep in mind I'm currently working on the basic GUI and the 
remote control protocol (both go hand in hand).
The GUI has voice counters too, so those will be very very handy for
the performance tests you describe.
Of course a bigger number of testers could speed up the fixing of problems
but currently most the small issues we are experiencing are all either
 known bugs or glitches due to unimplemented routines, eg. when you send
two note-on on the same midi key and then two note-off on that midi key,
one stream buffer will remain active because the note-off code believes
that there is no active voice on that key.

I'm waiting for Christian's opinion (here on the list_) too whether we should do
this quick'n dirty hack otherwise I risk getting beaten by him :-)


cheers,
Benno
http://www.linuxsampler.org



-------------------------------------------------
This mail sent through http://www.gardena.net