linuxsampler-devel

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

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

Some interesting performance comparisons the PMI (they produce piano sample
libraries) guys have done:

http://forum.cubase.net/forum/Forum24/HTML/000344.html
http://www.northernsounds.com/ubb/NonCGI/ultimatebb.php?ubb=get_topic;f=3;t=005941;p=2


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



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

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

[Mark K. <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! ;-)

Cheers,
Mark

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

[Robert J. <rob...@da...>]

torsdagen den 30 oktober 2003 19.37 skrev Mark Knecht:
> 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! ;-)
>

Yes yes yes :)

Ofcourse we should aim for the stars, but for now I'm happy just as long as it 
plays simple things without any serious problems. 
First thing's first, get something functional out the door and the crowd will 
come.
The only thing I'm missing (short term) is removal of the clicking, fix of the 
midimap and possibly addition of jack support.

Then I'll test it to bits!! And tell everybody else to start poking at it :)

---
To be truthful, I don't even believe LS has to match the performance of 
Kontakt anytime soon. Hardware is cheap and since they won't support 64bits 
for a long time coming, LS will run circles around it!!

Pinky: Brain, what are we going to do today?
Brain: The same thing we do every day. Try and take over the world.

/Robert




> Cheers,
> Mark
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

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

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

On Thu, 2003-10-30 at 10:57, Robert Jonsson wrote:

> Yes yes yes :)
> 
> Ofcourse we should aim for the stars, but for now I'm happy just as long as it 
> plays simple things without any serious problems. 
> First thing's first, get something functional out the door and the crowd will 
> come.
> The only thing I'm missing (short term) is removal of the clicking, fix of the 
> midimap and possibly addition of jack support.
> 

Yes, I forgot the MIDI mapping thing, but even that is manageable for me
since I have more MIDI ports than I know what to do with I just have
this tool on a port by itself. For most users that may not be true.

I wouldn't even suggest going 'out the door' at all in the beginning.
For people subscribed to this list, those interested could put it
through a few weeks paces before we announced anything more widely. 

When it was announced, if we could place 3-5 non-copyrighted, but
tested, GSt libraries on the LinuxSampler web site, then interested
people could get libraries that we knew worked. This (to me) would be
far more preferable than supply LS with no libraries and having people
choose anything they want, resulting in a huge number of questions on
day one.

Let people test known, good libraries first, work out their hardware
problems, and then if they have specific problems, report those via some
bug tracker and *not* just on this list. I have literally 100's of
libraries. I don't think you want me to report each problem as an
individual email.

My 2 cents,
Mark

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

[ian e. <de...@cu...>]

amen to that!
i definitely agree that getting a first working version is absolutely
key. just as long as the code is designed the right way, there's nothing
to lose. performance tweaking using the various techniques available can
come once the framework is implemented, along with the bells and
whistles!
i'm so excited for a first version of this - now that we have ardour,
jack and all the effects and synth apps that have sprung up around jack,
linuxsampler is perhaps the biggest missing piece of the linux pro audio
puzzle!
ian

On Thu, 2003-10-30 at 13:57, Robert Jonsson wrote:
> Yes yes yes :)
> 
> Ofcourse we should aim for the stars, but for now I'm happy just as long as it 
> plays simple things without any serious problems. 
> First thing's first, get something functional out the door and the crowd will 
> come.
> The only thing I'm missing (short term) is removal of the clicking, fix of the 
> midimap and possibly addition of jack support.
> 
> Then I'll test it to bits!! And tell everybody else to start poking at it :)
> 
> ---
> To be truthful, I don't even believe LS has to match the performance of 
> Kontakt anytime soon. Hardware is cheap and since they won't support 64bits 
> for a long time coming, LS will run circles around it!!
> 
> Pinky: Brain, what are we going to do today?
> Brain: The same thing we do every day. Try and take over the world.
> 
> /Robert
> 

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

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

Scrive Robert Jonsson <rob...@da...>:


> >
> >    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! ;-)
> >
> 
> Yes yes yes :)

Hmmm, you were faster than I in responding.
You seem one more quick'n dirty supporter :-)
Let's see other's opinions ....

> 
> Ofcourse we should aim for the stars, but for now I'm happy just as long as
> it 
> plays simple things without any serious problems. 
> First thing's first, get something functional out the door and the crowd will
> 
> come.

Do you think so ?
Would it not be better make something that does at least
the basic enveloping, looping and articulation so that those
large libs play well ?

> The only thing I'm missing (short term) is removal of the clicking, fix of
> the 
> midimap and possibly addition of jack support.
> 
> Then I'll test it to bits!! And tell everybody else to start poking at it :)

but that would ruin our "shock-and-awe" strategy.
:-)

> 
> ---
> To be truthful, I don't even believe LS has to match the performance of 
> Kontakt anytime soon.

Why not ? our code is very simple, modular and configurable.
For example when playing those large libraries that are sampled 
key by key we could turn off interpolation completely, or use linear
(linear is quite a bit faster than cubic).
Or use SIMD instructions if those are beneficial in certain situations.

> Hardware is cheap and since they won't support 64bits 
> for a long time coming, LS will run circles around it!!

That's true, but we need to act fast to beat the the competition,
otherwise meanwhile uncle bill will fix his crappy Windows :-)

Hmmm Mark, release+sustian on 64bit boxes ?
I'm going to get persuaded in following your suggestions :-)

> 
> Pinky: Brain, what are we going to do today?
> Brain: The same thing we do every day. Try and take over the world.

Sounds good, just like LS :-)

PS: technical question about Linux on amd 64:
Are pointers 4bytes (32bit = 4GB address space) or can you
use 64bit pointers too ? 
If the second case is not possible it would a bit sad because
it would mean you can manage more than 4GB but you would still
have the 4GB per process limit which would hurt LS.
ok we could fire up multiple instances and load some sample libraries
in each instance thus maxing out the RAM anyway but it would not
be as cool as doing all within one instance plus it could lead to
some performance problems.

Can someone of you shed some light here (or look up the stuff on google
and post links to the relevant stuff eg kernel ML etc) ?


cheers,
Benno



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

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

[Robert J. <rob...@da...>]

Hi ho,

> > ---
> > To be truthful, I don't even believe LS has to match the performance of
> > Kontakt anytime soon.
>
> Why not ? our code is very simple, modular and configurable.
> For example when playing those large libraries that are sampled
> key by key we could turn off interpolation completely, or use linear
> (linear is quite a bit faster than cubic).
> Or use SIMD instructions if those are beneficial in certain situations.

Yes, indeed. What I meant is that it doesn't matter ;~). 

The killer feature of LS isn't that it's the fastest, biggest, baddest in town 
(well, it may be someday :-).
The killer features are in my opinion that it's an open implementation based 
on linux and that it supports GIG to some reasonable extent.
These three things are the basics that make it awsome. The rest can wait a 
littlebit.

>
> > Hardware is cheap and since they won't support 64bits
> > for a long time coming, LS will run circles around it!!
>
> That's true, but we need to act fast to beat the the competition,
> otherwise meanwhile uncle bill will fix his crappy Windows :-)

I think we have a headstart of atleast 2 years. Before that there won't be any 
drivers, and definitely no 64bit samplers for windows :)

But eeeeven if we/you guys fail to deliver a topnotch sampler in that time 
they STILL can't top LS's killer features, 
- open implementation 
- based on linux.

So ... you win however you do it :)

>
> Hmmm Mark, release+sustian on 64bit boxes ?
> I'm going to get persuaded in following your suggestions :-)
>
> > Pinky: Brain, what are we going to do today?
> > Brain: The same thing we do every day. Try and take over the world.
>
> Sounds good, just like LS :-)
;)

>
> PS: technical question about Linux on amd 64:
> Are pointers 4bytes (32bit = 4GB address space) or can you
> use 64bit pointers too ?
This is just a guess, but I would be disappointed if pointers wheren't bigger 
than 32bits. 

> If the second case is not possible it would a bit sad because
> it would mean you can manage more than 4GB but you would still
> have the 4GB per process limit which would hurt LS.
> ok we could fire up multiple instances and load some sample libraries
> in each instance thus maxing out the RAM anyway but it would not
> be as cool as doing all within one instance plus it could lead to
> some performance problems.

Worry about it when the time comes :)

>
> Can someone of you shed some light here (or look up the stuff on google
> and post links to the relevant stuff eg kernel ML etc) ?

This interests me so I will check at a later time... But right now I got some 
coding to do, muse is going through a major revision, go go Werner! :)

/Robert

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

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

On Thu, 2003-10-30 at 11:59, be...@ga... wrote:
> Scrive Robert Jonsson <rob...@da...>:
> > 
> > Ofcourse we should aim for the stars, but for now I'm happy just as long as
> > it 
> > plays simple things without any serious problems. 
> > First thing's first, get something functional out the door and the crowd will
> > 
> > come.
> 
> Do you think so ?
> Would it not be better make something that does at least
> the basic enveloping, looping and articulation so that those
> large libs play well ?

Ah, so my simple minded list missed looping also. Maybe it's best to
start a list. People can add to it as they see fit.

Critical private tester requirements:
1) Sustain pedal (with or without same note playback like GSt)
2) Click elimination
3) Looping
4) Single library

At this point folks like Robert and I could just bang away on it and see
if it's stable. We can watch top, run other apps, try it on different
computers with different sound cards, and just make sure it's stable. We
give you feedback, but with an understanding that it's completely beta.
I think I can make musical use of LS in this state, but that's a guess.
I KNOW I can test it and give feedback.

Some things I would be looking at:

1) Actual comparison of waveforms, volume, signal integrity between LS
and GSt.
2) Streaming efficiency of Linux vs. Windows using different disk types
(FAT vs. FAT, FAT vs. ext3/reiser/?, EIDE vs. 1394, primary drive vs.
audio drive, etc.)

To be clear, I'm thinking that Robert and I are only talking about the
hack version to accelerate early testing, not as a product for release.
Follow through the rest of my list to see what is in my mind for a
possible plan.

Critical early adopter requirements:
1) Envelopes
2) Articulation file support
3) Cross fades
4) Probably filters, LFO's and other GSt features
5) Still single library

This might go to one or two new people with some real deep GSt
experience, but only if they were technically ready to do some work.

Desired early adopter features
1) Key switching
2) MIDI channel support

Critical Pre-release features
1) GUI - 16 libraries
2) Key switching
3) MIDI channel support

Desired Pre-release features
1) Jack support

At this point we have to look at things like the mix buses, making sure
they really work well and sound good.

If everything looks good, then we see about getting some real GSt
library developers involved. I'll drive down to L.A. in December
sometime and set it up for one or two of the guys down there if
required. (Heck, I'll even set it up for Hans Zimmer, user of 30 copies
of GSt, if he asks nicely!) ;-) (OK, even if he doesn't as I'd like to
meet him.)

With everything above working, you release publicly and get your 'shock
and awe' strategy.

Anyway, that's my thoughts right now. Sort of bold for me to put all
that down. I'm not tied to any of it, but hopefully the list would be
something others would add to or rearrange as the group sees fit.

Cheers,
Mark

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

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

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

> 
> If everything looks good, then we see about getting some real GSt
> library developers involved. I'll drive down to L.A. in December
> sometime and set it up for one or two of the guys down there if
> required. (Heck, I'll even set it up for Hans Zimmer, user of 30 copies
> of GSt, if he asks nicely!) ;-) (OK, even if he doesn't as I'd like to
> meet him.)
> 
> With everything above working, you release publicly and get your 'shock
> and awe' strategy.
> 
> Anyway, that's my thoughts right now. Sort of bold for me to put all
> that down. I'm not tied to any of it, but hopefully the list would be
> something others would add to or rearrange as the group sees fit.

Mark your strategy makes sense to me.
For now don't announce LS to the world, it is currently a developer version
and as long as it does not provide the basic features to be usable
by non technical users, provides stability and correct audio playback
of at least 95% of the available sample libraries we should not announce
LS anywhere except in developer circles (this list and possibly LAD).

The fact that the GUI I'm writing runs on on multiple platforms
(written in Qt thus runs on Windows and Mac too) will probably be very 
beneficial for those that want dedicate entire PCs to LS.
The cheap price of hardware is a big plus for us.
For the price of windows xp + a good softsampler you can buy a relatively
powerful PC with a soundcard (perhaps even a 24bit card like the m-audio delta
 cards which start from $200-$250).
Powerful hardware cheaper than commercial software .... silly :-)

LS .... the poor man's "Hans Zimmer Studio" :-)

cheers,
Benno


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

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

[Robert J. <rob...@da...>]

Hi,

>
> PS: technical question about Linux on amd 64:
> Are pointers 4bytes (32bit =3D 4GB address space) or can you
> use 64bit pointers too ?

It was a long time since I poked around in lowlevel stuff, and I've never h=
ad=20
much experience with x86... your comments below seem to suggest there can b=
e=20
constraints in the operating system, is that the issue you want to find out?

Anyway I took a peek at:=20
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/245=
92.pdf
from
http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_739_7044,00.h=
tml

=46rom what is in there I can't find any such constraints unless running in=
=20
compatibility-mode.
There are a few new modes with different level of compatibility, they seem =
all=20
to support adressing in larger chunks though...

All registers are 64bit that should be enough, or?

amd64 has all x86 registers (8 of them) extended to 64bit. It also has 8 ne=
w=20
general purpose registers that are 64 bit. Ontop of that there are 8 64bit=
=20
MMX registers (though they seem to occupy the same space as the FPU=20
registers) and 16 128-bit XMM registers. (see page 4 in pdf)

This all suggests to me that compilers will be able to do much better=20
optimizations on a64...

Oh, the instruction pointer is also 64bit.

/Robert


> If the second case is not possible it would a bit sad because
> it would mean you can manage more than 4GB but you would still
> have the 4GB per process limit which would hurt LS.
> ok we could fire up multiple instances and load some sample libraries
> in each instance thus maxing out the RAM anyway but it would not
> be as cool as doing all within one instance plus it could lead to
> some performance problems.
>
> Can someone of you shed some light here (or look up the stuff on google
> and post links to the relevant stuff eg kernel ML etc) ?
>
>
> cheers,
> Benno
>
>
>
> -------------------------------------------------
> This mail sent through http://www.gardena.net
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

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

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

[Robert J. <rob...@da...>]

torsdagen den 30 oktober 2003 22.34 skrev Mark Knecht:
> On Thu, 2003-10-30 at 11:59, be...@ga... wrote:
> > Scrive Robert Jonsson <rob...@da...>:
> > > Ofcourse we should aim for the stars, but for now I'm happy just as
> > > long as it
> > > plays simple things without any serious problems.
> > > First thing's first, get something functional out the door and the
> > > crowd will
> > >
> > > come.
> >
> > Do you think so ?
> > Would it not be better make something that does at least
> > the basic enveloping, looping and articulation so that those
> > large libs play well ?

The below list seems a very good start (or even finish, was quite thorough). 
It doesn't fit exactly with my view of LS but it is close enough :).

To repeat, I'd like an early release with the basics supported that we can 
start testing real life scenarios on. (Mark doesn't want to call it a 
release, but I think it is a release ;)
After that the other phases will follow quite naturally. More developers may 
even get involved as bonus :).

/R


>
> Ah, so my simple minded list missed looping also. Maybe it's best to
> start a list. People can add to it as they see fit.
>
> Critical private tester requirements:
> 1) Sustain pedal (with or without same note playback like GSt)
> 2) Click elimination
> 3) Looping
> 4) Single library
>
> At this point folks like Robert and I could just bang away on it and see
> if it's stable. We can watch top, run other apps, try it on different
> computers with different sound cards, and just make sure it's stable. We
> give you feedback, but with an understanding that it's completely beta.
> I think I can make musical use of LS in this state, but that's a guess.
> I KNOW I can test it and give feedback.
>
> Some things I would be looking at:
>
> 1) Actual comparison of waveforms, volume, signal integrity between LS
> and GSt.
> 2) Streaming efficiency of Linux vs. Windows using different disk types
> (FAT vs. FAT, FAT vs. ext3/reiser/?, EIDE vs. 1394, primary drive vs.
> audio drive, etc.)
>
> To be clear, I'm thinking that Robert and I are only talking about the
> hack version to accelerate early testing, not as a product for release.
> Follow through the rest of my list to see what is in my mind for a
> possible plan.
>
> Critical early adopter requirements:
> 1) Envelopes
> 2) Articulation file support
> 3) Cross fades
> 4) Probably filters, LFO's and other GSt features
> 5) Still single library
>
> This might go to one or two new people with some real deep GSt
> experience, but only if they were technically ready to do some work.
>
> Desired early adopter features
> 1) Key switching
> 2) MIDI channel support
>
> Critical Pre-release features
> 1) GUI - 16 libraries
> 2) Key switching
> 3) MIDI channel support
>
> Desired Pre-release features
> 1) Jack support
>
> At this point we have to look at things like the mix buses, making sure
> they really work well and sound good.
>
> If everything looks good, then we see about getting some real GSt
> library developers involved. I'll drive down to L.A. in December
> sometime and set it up for one or two of the guys down there if
> required. (Heck, I'll even set it up for Hans Zimmer, user of 30 copies
> of GSt, if he asks nicely!) ;-) (OK, even if he doesn't as I'd like to
> meet him.)
>
> With everything above working, you release publicly and get your 'shock
> and awe' strategy.
>
> Anyway, that's my thoughts right now. Sort of bold for me to put all
> that down. I'm not tied to any of it, but hopefully the list would be
> something others would add to or rearrange as the group sees fit.
>
> Cheers,
> Mark
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

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

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

On Thu, 2003-10-30 at 13:57, Robert Jonsson wrote:

> The below list seems a very good start (or even finish, was quite thorough). 
> It doesn't fit exactly with my view of LS but it is close enough :).
> 
> To repeat, I'd like an early release with the basics supported that we can 
> start testing real life scenarios on. (Mark doesn't want to call it a 
> release, but I think it is a release ;)
> After that the other phases will follow quite naturally. More developers may 
> even get involved as bonus :).
> 
> /R

You say tomato... ;-)

You and I agree, I think, on the reasons for the early release. I don't
want to release it with any big announcement publicly, even though it
will get 'released' to people, since any distribution of the code will
naturally draw comparisons with GSt, Kontakt and other personal
favorites. I am thinking that not having enough features when it is
'announced' will bring bad press. I don't think the 1-voicce, no GUI, no
filters or articulation file support will stand up very well, even if it
works very well for you and I.

Better, maybe, to release it without announcing it, so that we don't get
people's expectations set too high.

I say tomato... ;-)

Either way it makes good music. :-)

- Mark

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

[Christian S. <chr...@ep...>]

Es geschah am Donnerstag, 30. Oktober 2003 20:46 als be...@ga... 
schrieb:
> >    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.
>
[snip]
>
> 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
> :-)
 
I will definetely hurt you Benno if you do that! No Mark, we will add the 
remaining basic stuff very soon (envelopes, sustain, etc.). Fortunately I 
have time for that now, so maybe we can finish the envelopes this weekend.

CU
Christian

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

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

On Fri, 2003-10-31 at 13:05, Christian Schoenebeck wrote:

> > 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
> > :-)
>  
> I will definetely hurt you Benno if you do that! No Mark, we will add the 
> remaining basic stuff very soon (envelopes, sustain, etc.). Fortunately I 
> have time for that now, so maybe we can finish the envelopes this weekend.
> 
> CU
> Christian

Just what I like...CLEAR communication! ;-)

I'll probably have filter data for Steve by Saturday around noon my
time. I'm going a bit slowly to learn about octave, check the data a bit
myself, and learn how to use those tools. I hope this saves Steve from
any stupid mistakes on my part.

Maybe in another week or two we'll have the next big step in
functionality. Sounds like fun!

Cheers,
Mark

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

[Sebastien M. <me...@me...>]

As one of the developper of the UVI Sampling Engine (which is behind the
plugsounds/spectrasonics/MachFive plugins) I'd be very happy about a
"sampler performance test suite" that could be used to test objective
and subjective perfomances of all the sampling engines on the market.
The suite should include (at least):
streaming and non streaming polyphony perfs
effects perfs
routing perfs
memory footprints test
signal handling tests and benchs (enveloppes, pitch correctness, LFOs,
etc...).

It could be a good idea to develop a set of typical samples and
methodology to test comercial and non comercial samplers on the market.
I'd be quite happy to contribute to such a project, and give the input
of my fellow sound designers a USB Sounds.

Any one care to comment on this idea?

Sebastien


be...@ga... wrote:

>Some interesting performance comparisons the PMI (they produce piano sample
>libraries) guys have done:
>
>http://forum.cubase.net/forum/Forum24/HTML/000344.html
>http://www.northernsounds.com/ubb/NonCGI/ultimatebb.php?ubb=get_topic;f=3;t=005941;p=2
>
>
>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
>  
>