linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

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 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)

[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)

[<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)

[<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)

[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)

[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)

[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 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

[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] Gigasampler filter analysis

[Steve H. <S.W...@ec...>]

On Thu, Oct 30, 2003 at 05:16:53 +0100, be...@ga... wrote:
> Scrive ian esten <de...@cu...>:
> 
> > the impulse response of a filter completely describes its frequency
> > response... what other information do you need?
> 
> I agree.
> What noise are you refering to ?
> Mark said he recorded the output via digital audio link (Protools)
> and the original sample (non filtered) show all samples zero except one.
> So don't understand where the noise source could lie (except perhaps in
> a wrong GSt setting ?).

Well, something was wrong. Maybe it will become clear after I've seen the
noise plots. The plots quite clearly contained a sinewave of some kind and
some harmonics. Either the impulse wasnt clean or there is some kind of
non-linearity in there.

- Steve

Re: [Linuxsampler-devel] Gigasampler filter analysis

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

On Thu, 2003-10-30 at 08:16, be...@ga... wrote:
> Scrive ian esten <de...@cu...>:
> 
> > the impulse response of a filter completely describes its frequency
> > response... what other information do you need?
> 
> I agree.
> What noise are you refering to ?
> Mark said he recorded the output via digital audio link (Protools)
> and the original sample (non filtered) show all samples zero except one.
> So don't understand where the noise source could lie (except perhaps in
> a wrong GSt setting ?).

Clearly a possibility.

> 
> Steve please show the iFFT of the impulses in a logarithmic scale. (
> at least the y-axis (in dB)
> The graphs you posted are impossible to read.
> Perhaps it looks much better in the log scale ?
> 

I have built the white noise wave file and discussed it with Steve. 

I can now run sox and octave locally, so if there are commands in those
programs people know of to analyze the work I'm doing, please send them
along and I'll do more work up front before spewing out too much stuff.
(I don't have time to try and read octave manuals, nor much interest.)

I am building the gig file based on this today. If I solve my MIDI
problem that cropped up last night I will certainly be able to get some
data of the noise source going through the filters, so we'll have both
versions of filter data to look at.

I would expect that if I made a wrong turn in GSt with the impulses,
then I'll make the same wrong turn using the white noise and we'll see
that, so stay tuned. More data later this evening or tomorrow some time.

- Mark

Re: [Linuxsampler-devel] Gigasampler filter analysis

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

Scrive ian esten <de...@cu...>:

> the impulse response of a filter completely describes its frequency
> response... what other information do you need?

I agree.
What noise are you refering to ?
Mark said he recorded the output via digital audio link (Protools)
and the original sample (non filtered) show all samples zero except one.
So don't understand where the noise source could lie (except perhaps in
a wrong GSt setting ?).

Steve please show the iFFT of the impulses in a logarithmic scale. (
at least the y-axis (in dB)
The graphs you posted are impossible to read.
Perhaps it looks much better in the log scale ?

Let us know please.

Benno


> 
> 
> On Wed, 2003-10-29 at 16:39, Steve Harris wrote:
> > Thanks to Mark for running the impulses through the filters, sadly there
> > isn't enough inforamtion in the impulse (maybe due to some noise that
> > crept in somewhere, maybe due to some non linearity in the filter, to be
> > honest I dont know why) to analyse them, eg here are 4 traces from the
> > lowpass filters:


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

Re: [Linuxsampler-devel] Gigasampler filter analysis

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

the impulse response of a filter completely describes its frequency
response... what other information do you need?


On Wed, 2003-10-29 at 16:39, Steve Harris wrote:
> Thanks to Mark for running the impulses through the filters, sadly there
> isn't enough inforamtion in the impulse (maybe due to some noise that
> crept in somewhere, maybe due to some non linearity in the filter, to be
> honest I dont know why) to analyse them, eg here are 4 traces from the
> lowpass filters:
> 
> http://www.ecs.soton.ac.uk/~swh/gst-impulses/
> 
> They are the highest resonance settings, 4 different frequencies, which
> are the clearest, but still dont have much information in them.
> 
> Mark, if possible could run run a very good whitenoise source (I can
> provide a WAV if you need one) into the same filters, runnning them a
> couple of seconds at each setting? Sorry, I didnt realise the signal
> would be so noisy.
> 
> Just at minimum resonance settings with the 4 cutoffs you used before will
> be great for starters.
> 
> As a note for me, and incase anyone wants to try it, you can produce
> spectrum plots in octave easily:
> 
> 1) chop out the signal into sections to analyse (preferably just over 1
>    sec) with no other signal in them. save as 16bit mono WAV (eg. 01.wav)
> 
> 2) convert to raw PCM file (eg. sox 01.wav 01.raw)
> 
> 3) octave stuff:
> 
> $ octave
> octave:1> # produce an fft of the raw file
> octave:1> f = fft(loadaudio('01', 'raw'), 44100);
> octave:2> # plot the freq response
> octave:2> plot(abs(f(1:22050)/max(abs(f))));
> 
> the plot is frequency (Hz) on the x-axis and normalised amplitude on the
> y-axis.
> 
> plot(20.0 * log(abs(f(1:22050)/max(abs(f))))/log(10));
> will show amplitude in dB's, which can be helpful.
> 
> - Steve
> 
> 
> -------------------------------------------------------
> 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

[Linuxsampler-devel] A little headway

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

Or three steps forward, one big step back...

This evening I did get a bit done:

1) I created the white noise wave file that Steve was talking about in
an earlier email. I also tried out his sox/octave commands, got some
interesting plots and sent those to him. If they look OK then I'll build
the gig file and get the data he was looking for. (Or figure out why
they don't look good...)

2) I wanted to load up my GSt library on LS, but it turned out my GSt
machine no longer has a 1394 adapter installed, meaning I couldn't copy
the library. Bummer... 

3) Not to be deterred, since the GSt machine is octal boot, I booted
into PlanetCCRMA, downloaded, modified and built LS on that platform.
(Dell P3-500 with 768MB) Everything built fine, so I tried loading up
the Bardstown Bosendorfer. This gig is over 1.6GB and is a multi-layer
file. It loaded fine. No error messages, although I did get a few
strange messages about ' caching silence ', whatever that means.

However, I wanted to play the gig file but quickly figured out that I
haven't used MIDI on this machine (in Linux) since I removed the
MidiSport, and I've never used the AP2496 for MIDI under Linux, so I
spent about an hour trying to get that to work but failing.

I then decided to boot into GSt, and, bummer again, found that the MIDI
input on the AP2496, or something else in the studio, is no longer
working. I spent about 30 minutes trying to figure out what died. I was
moving cables tonight working with the 1394 drives, so maybe somethign
came loose somewhere and I haven't found it, but at this point, with no
MIDI on that box I've lost GSt, Reaktor Session and LS all in one fell
swoop.

Anyway, until I find the problem I may be offline a bit. Hopefully it
won't take more than a bit of time tomorrow evening.

Cheers,
Mark

Re: [Linuxsampler-devel] Gigasampler filter analysis

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

On Wed, 2003-10-29 at 13:39, Steve Harris wrote:

> Mark, if possible could run run a very good whitenoise source (I can
> provide a WAV if you need one) into the same filters, runnning them a
> couple of seconds at each setting? Sorry, I didnt realise the signal
> would be so noisy.

Steve,
   This would be no problem at all. I would just take a white noise wave
file and then build a new gig file using it. Now that I know how, that
would take only 30 minutes or so, and running the recording only takes a
few seconds really, so it's no big deal at all for me.

   I can record a wave file using the white noise generator in Pro
Tools. I do not know if it qualifies as 'a very good white noise
source.' If you provided a wave file that you are happy with, then we
wouldn't have this uncertainly.

   Are you sure this noise you're seeing is *not* caused by me messing
up somehow in the way I constructed the gig file? If you provided a
well-known (to you anyway) noise source file would you be more likely to
see me making a mistake? If so, then I think it makes the most sense for
you to supply it.

Please remember, I have done very few gig files, and none of them for
'scientific' purposes! ;-)

> 
> Just at minimum resonance settings with the 4 cutoffs you used before will
> be great for starters.

   Sure. Get that much, make sure it's right, and then move on to the
other settings? Do you want all the filter types initially, or should we
just do the low pass and see if it is working?

   Can you put a wave file you are interested in on your web site
somewhere and point me at it? I'll download it and do it soon.

   BTW - Should i do this next set of recordings in mono?

Mark

[Linuxsampler-devel] Gigasampler filter analysis

[Steve H. <S.W...@ec...>]

Thanks to Mark for running the impulses through the filters, sadly there
isn't enough inforamtion in the impulse (maybe due to some noise that
crept in somewhere, maybe due to some non linearity in the filter, to be
honest I dont know why) to analyse them, eg here are 4 traces from the
lowpass filters:

http://www.ecs.soton.ac.uk/~swh/gst-impulses/

They are the highest resonance settings, 4 different frequencies, which
are the clearest, but still dont have much information in them.

Mark, if possible could run run a very good whitenoise source (I can
provide a WAV if you need one) into the same filters, runnning them a
couple of seconds at each setting? Sorry, I didnt realise the signal
would be so noisy.

Just at minimum resonance settings with the 4 cutoffs you used before will
be great for starters.

As a note for me, and incase anyone wants to try it, you can produce
spectrum plots in octave easily:

1) chop out the signal into sections to analyse (preferably just over 1
   sec) with no other signal in them. save as 16bit mono WAV (eg. 01.wav)

2) convert to raw PCM file (eg. sox 01.wav 01.raw)

3) octave stuff:

$ octave
octave:1> # produce an fft of the raw file
octave:1> f = fft(loadaudio('01', 'raw'), 44100);
octave:2> # plot the freq response
octave:2> plot(abs(f(1:22050)/max(abs(f))));

the plot is frequency (Hz) on the x-axis and normalised amplitude on the
y-axis.

plot(20.0 * log(abs(f(1:22050)/max(abs(f))))/log(10));
will show amplitude in dB's, which can be helpful.

- Steve

Re: SoundFont/DLS2/Gig (was Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity)

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

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

 
> Hi,
>    In a private email to Benno earlier, I had asked the question "What
> sort of sampler do you want LS to be?" (I have no opinion formed today) 
> 
>    I see GSt and Kontakt as the two leaders today, and they really are
> different sorts of animals. GSt is pretty much a playback engine. You do
> all the editing in GigaEdit to set up samples, filters, envelopes, etc.,
> to do what you want, but primarily the wave files just get played in
> digital bit order. Nothing much happens in GSt. The *current* version of
> GSt doesn't do a lot to modify sounds.

This is true about GSt but it's one of it's major strenghts:
most natural instruments do not need any processing at all.
piano, guitars, orchestral stuff, it is all played as recorded and as you
see it sounds so great that film composers can use it in film scores
often by completely replacing real orchestras without the listeners noticing
that the song is played by a sampler and not by humans.
Ok nothing is perfect, the pros will always notice a difference but
since in many case the monetary budget is limited one has to do some
tradeoffs and streaming samplers seem to do quite well in certain areas.

> 
>    Kontakt seems more oriented toward allowing you to mangle the sounds
> in strange and interesting ways. It will chop samples, play parts out of
> order, play them in reverse, etc., so you can get more wild stuff.

Yes this is certainly a strenght of Kontakt and we would like LS
being able to mangle the samples too.
But for now let's focus on standard high performance streaming playback.

> 
>    What does this team want LS to be? I expect that LS will *need* to
> have some wild capabilities or users of GST, Kontakt and others will
> find it sort of boring. 

It could be that it will be boring but I guess even if it provides only
decent GIG playback it will be appealing to some users because it is 
stable, can be tweaked, can be made run on 64 bit CPUs allowing to
precache dozen of gigabytes of RAM (possibly saving quite a few bucks
 over those multi-machine installations), streaming over ethernet
can be added too so LS clusters would provide unlimited scalability
using off the shelf hardware without the need of equipping each machine
with expensive 24bit digital audio cards, midi interfaces and the like.
I think the community feedback loop will help us to identify quickly waht
90% of users want. If we can achieve that the ball will start rolling
and will become unstoppable :-)
 (we will put a discussion forum on the LS site to ease communication
with non technical users)


> GSt 3.0 will be out some day. It will likely go
> beyond where Kontakt is today.

I'll believe that when I'll see it. :-)
I think GSt's biggest strenght (low latency streaming thanks to
kernel level programming) is one of its biggest disadvantages too.
They have big problems when interoperating with other applications
because frankly said putting a sampler in a kernel modules is a bad
hack but probably on Windows the only way to get out the maximum
of the iron (the hardware, disks, RAM, latencies etc).

People want VST integration and I see it hard for GSt achieving
perfect VST integration without giving up its performance lead.
If GSt 3.0 performance level drops to Kontakt then users will probably
have no reason of choosing GSt over Kontakt, even if it will provide
some advanced features. NI has built up a nice knowledge in the
DSP area and I think it is hard for competitors to bring out softsamplers that
offer a considerably more DSP features without investing quite some resources
in R&D. 

> By that measure, LS would seem boring wo
> many without some interesting ways to twist the sounds around.

It could be but for orchestral and natural instrument stuff it would
already be a very appealing because of its ability to adapt to hardware,
CPUs, platforms, etc.

> 
>    Personally, I agree with you. I'll probably just use the standard
> model where LS looks like GSt most of the time. However, like the
> difference between Reaktor and Reaktor Session, should some interesting
> person take LS and mangle it into an interesting new configuration, I'll
> probably use the compiled version of that also.

You already know that I fully agree on this.
I originally wanted to go the "Reaktor" -> "Reaktor Session" route but
it turned out to be a too big task for now. People want to make music
with softsamplers on Linux today and not in several months/years and
probably 90% of users are quite happy with the features that the
first production release of LS will have.
This is why we inverted course and will go the "Reaktor Session" -> "Reaktor"
way. :-)

> 
> I somehow doubt I will ever wire together pieces and compile them
> myself, but it would be fun to see what others dream up.

Yes this is true, never undersestimate the creativity of people.
Sometimes people use a tool and do things that go beyond the wildest dreams
of the original creators of a tool itself.
Let's work hard building such a tool and sit back watching what
those crazy users will do with it :-)

Benno
http://www.linuxsampler.org


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

Re: SoundFont/DLS2/Gig (was Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity)

[Steve H. <S.W...@ec...>]

On Wed, Oct 29, 2003 at 02:04:09 +0100, be...@ga... wrote:
> leave the recompiler stuff for now.
> But since to quote Linus, our goal is total world domination :-) ,
> we should never stop innovating or thinking about new ways to generate
> and manipulate audio.

Sure.

> Let's produce a rock solid standalone version of LS and wait for
> the user's reactions. As we know from other open soruce projects 
> the feedback from the community will help us to improve LS to become
>  a truly professional product that can play in the same league as
> the proprietary samplers.

Absolutly.
 
> PS: let us know when you make progress with the filters.

I'm going to try to have a crack at it this evening (GMT), but my
girlfriend is ill and I might have to go home early.

- Steve

Re: SoundFont/DLS2/Gig (was Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity)

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

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

> > >From a performance point of view if you stream from a single file or a
> bunch
> > of WAV files it makes virtually no difference (even if you open and close
> > the file at each triggering of the sample, it's very fast I did some
> benchmarks
> > and my conclusion is that the performance is exactly the same).
> 
> I know nothing, well, less than nothing if possible, about disk
> fragmentation on Linux, but wouldn't a collection of files be less
> likely to be guaranteed to be collected together on the drive in a
> group?

> 
> If this is true, then wouldn't individual wave files be more likely to
> have playback problems due to disk seek latencies for a single library?
> 
> I completely get that if the drive is slow, *some* library will be
> placed in the slow position, and that library would have problems, but
> for debugging hardware problems and making your system work well, after
> adding and deleting libraries for a year, wouldn't it be better to
> somehow guarantee that all samples are collected together in a
> contiguous disk area?

Well the fact is that most of the wav files will reside in contiguous blocks.
Of course the single WAV files could lie far apart but if you take a 
2GB file, the first block and the last block are quite distant from each other,
even if the whole file is residing in contiguous blocks.

And what happens if you trigger two notes that cause the reading of one sample
in the first part of the 2GB file and one in the last part ?
The disk will have to seek back and forth like mad.

I see no reason to organize files in a certain layout becaue they are usually
so large that the contiguous blocks argument does not hold water.
Ok of course if each 4KB block is spread randomly on the disk then performance
 will suck. But linux filesystems usually try to avoid this by putting large
parts of a file in contiguous blocks.
This ensures that the read performance is still good even on a full disk
because the number of disk seeks/time is low compared to the amount
 of data read.
I would not worry in any way about this.
Of course there are some idiotic cases where fragmentation can slow
down your disk performance, see here:
http://lists.debian.org/debian-user/2003/debian-user-200302/msg02363.html

I don't know if there exist a "defrag-like" util for Linux yet,
but as stated in the link above, if you have really concerns you can
backup all your data to another medium (HD, CDROM,tape etc), reformat
you data disk and copy back the data again.
Not sure if it is worth the trouble.

Anyway think about how many variables come into play when you let LS
play a complex MIDI file that streams many samplelibs from disk.
The exact disk seek sequence cannot be figured out in advance because 
it depends from the task scheduling, sample pitches (higher pitched samples
must be streamed faster thus need faster buffer refills), background tasks,
characteristics, geometry of the disk etc.
But as long as the filesystem is keeping large files in chunks of 
contiguous blocks of 128KB and more, LS performance will be perfectly fine and
 I guess virtually equal to a totally unfragmented disk.

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





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

Re: SoundFont/DLS2/Gig (was Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity)

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

Scrive Steve Harris <S.W...@ec...>:

> On Wed, Oct 29, 2003 at 12:19:49 +0100, be...@ga... wrote:
> > Ok, it is still monolithic (the recompiler stuff will come later,
> >  for now let's focus on good playback of existing sample formats)
> > but we will have no problems to accomodate
> > new loaders and engines because the Voice:: classes can be subclassed
> > to implement the characteristics of the engine associated to a certain
> > sample format.
> 
> I'm starting to doubt that the recompiling stuff is neccesary, the
> Gig/DLS2/SF2 formats seem to be quite expressive, yet efficiently
> implementatble, not even counting the XML+WAV formats used by newer
> things. I dont think that there would be much/any performance gain in
> using dynamic compilation, and how many peopel would want to design thier
> own instruments, when they could use standard formats have have greater
> compatibility?

Yes you are right and that's why Christian and others convinced me to
leave the recompiler stuff for now.
But since to quote Linus, our goal is total world domination :-) ,
we should never stop innovating or thinking about new ways to generate
and manipulate audio.
Let's produce a rock solid standalone version of LS and wait for
the user's reactions. As we know from other open soruce projects 
the feedback from the community will help us to improve LS to become
 a truly professional product that can play in the same league as
the proprietary samplers.

> 
> Its still a nice idea though, but maybe more suited to a softsynth.

Perhaps in future LS will evolve in something where the S stays for
both Sampler and for Synth ? Who knows.
Let's first working on build strong the fundamentals.

PS: let us know when you make progress with the filters.

cheers,
Benno


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

Re: SoundFont/DLS2/Gig (was Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity)

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

On Wed, 2003-10-29 at 03:19, be...@ga... wrote:

> Yes, but I think the future lies in formats like Halion and Kontakt use:
> XML for patch/program data plus a bunch of WAV files.
> Monolithic files are a mess to deal with while single WAV files allow
> for much more finegrained editing.
> Ok .... for relatively small files like soundfonts a single file makes sense
> but not for multi GByte sample libraries.
> >From a performance point of view if you stream from a single file or a bunch
> of WAV files it makes virtually no difference (even if you open and close
> the file at each triggering of the sample, it's very fast I did some benchmarks
> and my conclusion is that the performance is exactly the same).

I know nothing, well, less than nothing if possible, about disk
fragmentation on Linux, but wouldn't a collection of files be less
likely to be guaranteed to be collected together on the drive in a
group?

If this is true, then wouldn't individual wave files be more likely to
have playback problems due to disk seek latencies for a single library?

I completely get that if the drive is slow, *some* library will be
placed in the slow position, and that library would have problems, but
for debugging hardware problems and making your system work well, after
adding and deleting libraries for a year, wouldn't it be better to
somehow guarantee that all samples are collected together in a
contiguous disk area?

- Mark

Re: SoundFont/DLS2/Gig (was Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity)

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

On Wed, 2003-10-29 at 03:37, Steve Harris wrote:
> On Wed, Oct 29, 2003 at 12:19:49 +0100, be...@ga... wrote:
> > Ok, it is still monolithic (the recompiler stuff will come later,
> >  for now let's focus on good playback of existing sample formats)
> > but we will have no problems to accomodate
> > new loaders and engines because the Voice:: classes can be subclassed
> > to implement the characteristics of the engine associated to a certain
> > sample format.
> 
> I'm starting to doubt that the recompiling stuff is neccesary, the
> Gig/DLS2/SF2 formats seem to be quite expressive, yet efficiently
> implementatble, not even counting the XML+WAV formats used by newer
> things. I dont think that there would be much/any performance gain in
> using dynamic compilation, and how many peopel would want to design thier
> own instruments, when they could use standard formats have have greater
> compatibility?
> 
> Its still a nice idea though, but maybe more suited to a softsynth.
> 
> - Steve

Hi,
   In a private email to Benno earlier, I had asked the question "What
sort of sampler do you want LS to be?" (I have no opinion formed today) 

   I see GSt and Kontakt as the two leaders today, and they really are
different sorts of animals. GSt is pretty much a playback engine. You do
all the editing in GigaEdit to set up samples, filters, envelopes, etc.,
to do what you want, but primarily the wave files just get played in
digital bit order. Nothing much happens in GSt. The *current* version of
GSt doesn't do a lot to modify sounds.

   Kontakt seems more oriented toward allowing you to mangle the sounds
in strange and interesting ways. It will chop samples, play parts out of
order, play them in reverse, etc., so you can get more wild stuff.

   What does this team want LS to be? I expect that LS will *need* to
have some wild capabilities or users of GST, Kontakt and others will
find it sort of boring. GSt 3.0 will be out some day. It will likely go
beyond where Kontakt is today. By that measure, LS would seem boring wo
many without some interesting ways to twist the sounds around.

   Personally, I agree with you. I'll probably just use the standard
model where LS looks like GSt most of the time. However, like the
difference between Reaktor and Reaktor Session, should some interesting
person take LS and mangle it into an interesting new configuration, I'll
probably use the compiled version of that also.

   I somehow doubt I will ever wire together pieces and compile them
myself, but it would be fun to see what others dream up.

Mark

Re: SoundFont/DLS2/Gig (was Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity)

[Steve H. <S.W...@ec...>]

On Wed, Oct 29, 2003 at 12:19:49 +0100, be...@ga... wrote:
> Ok, it is still monolithic (the recompiler stuff will come later,
>  for now let's focus on good playback of existing sample formats)
> but we will have no problems to accomodate
> new loaders and engines because the Voice:: classes can be subclassed
> to implement the characteristics of the engine associated to a certain
> sample format.

I'm starting to doubt that the recompiling stuff is neccesary, the
Gig/DLS2/SF2 formats seem to be quite expressive, yet efficiently
implementatble, not even counting the XML+WAV formats used by newer
things. I dont think that there would be much/any performance gain in
using dynamic compilation, and how many peopel would want to design thier
own instruments, when they could use standard formats have have greater
compatibility?

Its still a nice idea though, but maybe more suited to a softsynth.

- Steve

Re: SoundFont/DLS2/Gig (was Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity)

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

Scrive Josh Green <jg...@us...>:

> Yep, I'm here :) 

Hi Josh !
Pressure is mounting on you, we will have soon a fully working
streaming capable sampler and I guess it will not take much time
for user begin asking for an editor that can edit and create
 GIG file and other streamable sampling libraries.
Be prepared :-)

> When comparing GigaSampler versus SoundFont versus
> DLS2, I don't think there is anything in particular that would make
> GigaSampler more professional than these other formats, except for a few
> key points: streaming of samples and > 16 bit audio.

I would say only streaming and the articulation via MIDI controller that permits
to and espressive playing of these instruments.
Perhaps DLS2 supports >16bit but currently the .GIG format does not, or at least
the gigastudio does not support it.
This is one of the reasons why both sample library producers and users are
looking at the competition (Steinberg Halion and NI Kontakt) because they
support 24bit. Those samplers, AFAIK use a sample format that is easier to
 deal with (especially when editing the single waves): AFAIK it's basically
an XML file that contains the program/patch data and a bunch of .WAV files.
Such a format is certainly easier to handle in swami too because you have
not to diassemble and reassemble those giant monolithic files.
At a later stage we will try to add support for those sample formats too in
LS. While not being yet fully modular, LS is modular enough to allow
one single engine deal with multiple formats thanks to C++ which permits
you to derive subclasses, eg Voice:: be Voice::gig or Voice::akai.
When loading foreign sample formats we do not "convert" them to a new, 
one-size-fits-all format but load and play them using native loading and
playback routines. This ensures faithful playback of those formats.


> There is no reason
> why streaming of samples couldn't be implemented with these other
> formats, though. 

Indeed SF2 could be streamed too, but keep in mind that some weird
 stuff like backwards looping etc make this task very hard or unviable.
The loader decide whether streaming or not the sample on a case to case basis
(eg if no problematic SF2 stuff like backwards looping etc is used then stream,
 otherwise keep it in RAM).

I've heard that fluidsynth has a good SF2 engine so if you folks want
future SF2 support in LS then try to persuade Peter Hanappe to port
the SF2 engine to LS (I would say it would be too early now since the
basic architecture of LS has not stabilized yet, perhaps in a few months).


> In the case of DLS2, its a really flexible format
> (heck, GigaSampler used it, or rather trashed it in my opinion, would
> have been nice if they had some sort of signature in the header). I
> think DLS2/SF2 has more flexibility in some areas than GigaSampler
> (particularly in the area of modulation, and extent of control values,
> GigaSampler has rather restricted parameter ranges, at least from what I
> have seen).

yes the giga did not want to complicate their lives too much so they
left out many stuff from originally contained in DLS2.
But even with this limitations GIG libraries sound great thanks to
the streaming that allows very large sample capacity and expressive playing
 through midi controller articulation.

> DLS2 could theoretically contain any audio format that WAV
> files can store, since the audio is stored as embedded WAV files. Its
> just that the spec says that only 8bit or 16bit audio is defined as
> being part of the standard.

Yes, but I think the future lies in formats like Halion and Kontakt use:
XML for patch/program data plus a bunch of WAV files.
Monolithic files are a mess to deal with while single WAV files allow
for much more finegrained editing.
Ok .... for relatively small files like soundfonts a single file makes sense
but not for multi GByte sample libraries.
From a performance point of view if you stream from a single file or a bunch
of WAV files it makes virtually no difference (even if you open and close
the file at each triggering of the sample, it's very fast I did some benchmarks
and my conclusion is that the performance is exactly the same).

> 
> Thinking of converting SoundFont or DLS2 files to GigaSampler gives me
> the creeps. Doing it for your own purposes might make sense, but
> distributing those GigaSampler files, means that less people can now use
> that instrument patch, since its not an open standard.

Fully agree but being able to read GIG files is very important if you
want that your sampler can make use of a vast pool of professional, 
high quality sample libraries.
GIG is only one among many formats that LS will support.
We can use our own format (probably XML + WAV files) if we want an open,
extensible sample library format. 
But for LS, being able to read GIG files is as important as for OpenOffice 
reading .DOC files.
The keyword is interoperability.
In that sense Christian's libgig is really well done and once he 
gets his articulation stuff in place GIG playback will be excellent.

> Maybe this will
> change in the future, but I haven't quite come to like the GigaSampler
> format yet. Maybe I just haven't worked with it enough. It would be nice
> to see LinuxSampler built in a way that makes it modular enough to use
> other formats easily.

It already is.
Ok, it is still monolithic (the recompiler stuff will come later,
 for now let's focus on good playback of existing sample formats)
but we will have no problems to accomodate
new loaders and engines because the Voice:: classes can be subclassed
to implement the characteristics of the engine associated to a certain
sample format.

> 
> I still envision my own project libInstPatch being usable for supporting
> other formats for GigaSampler. It supports DLS2 and SF2 at this point
> and GigaSampler to some extent and has a Python binding which I just
> added. I've been working a lot lately though, so I haven't had a lot of
> time to put toward these projects. But I hope that changes in the near
> future. It would be nice to collaborate more on some of this stuff. The
> C/C++ issue is probably going to come up again I'm sure, I'll look into
> how hard it would be to add a C++ wrapper to libInstPatch, if that would
> make it more appealing.

Well certainly you and Christian should collaborate more in order to avoid
wheel reinvention etc. Christian's libgig is made for loading GIG files and
exports methods (functions) for both reading patch/program data, articulation
layers etc plus it has functions to cache and read data from disk into
 memory buffers.
The question is, if Christian has already done this excellent lib wouldn't it
be beneficial to use that lib in swami too ?
Yes I know there are the C/C++ issues but I'm more and more convinced
 that C++ is the ideal language for handling sample related data because
samples are made up of many objects and subobjects.

Josh you could probably argue that LS should use libInstPatch.
Well I haven't looked to your stuff you I cannot judge what can be done,
what would be beneficial etc.
But what's for sure is that libgig is 100% optimized for playback it uses
no mutexing and all routines that are called from within the audio thread
are carefully optimized and have guaranteed execution times and being
the lib shipped directly with LS it will ease the dependency problem too.
(at least during the beginning phase, perhaps later it will be better to
make separate libs for each sample format).
I'm noth the author of libgig so I cannot say anything about 
which kind of collaboration could be beneficial between swami and LS.
But even if you Josh make a totally separate GIG editor in swami it would
still be very useful since you can edit GIGs and then load them into LS
for playing. Since only the sample heads are loaded, the loading is 
pretty fast even for very large sample libs.

> 
> Nice to see some activity on this list. Cheers.

I'm looking forward for the day that swami will go hand in hand with
LS and will be able to edit many sample formats that can be played using LS.

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


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