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

Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity

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

Tuesday 28 October 2003 14.22 skrev be...@ga...:
...
>
> > - it segfaults when ctrl-c:ing out of the app.
>
> probably due to the incorrect stopping of threads when the CTRL-C handler
> is called, not a serious issue and probably very easy to fix.
> As said it would be more serious if linuxsampler segfaulted during playing.
> :-)

yeah, it's no big deal ;)

>
> > - on my system i get mlockall failures all the time, regardless of the
> > size of
> > the gig file and such... how much mem does LS allocate? (I've got 512mb
> > so it
> >
> > should work rather well I think. I can run debug compiled-muse together
> > with
> >
> > jack with no problems, which both do mlockall and occupy lots of
> > memory...)
>
> see diskthread.h:
> #define STREAM_BUFFER_SIZE 131072
> #define MAX_INPUT_STREAMS 64
>
> this means we can have max 64 disk streams (each voice if streamed from
> disk exactly needs one stream).
> We are talking about 16bit samples (2bytes) thus
> the streams occupy
> MAX_INPUT_STREAMS*STREAM_BUFFER_SIZE*2
>
> this is not an extremely high amount, in the above case 16MB

Definately not alot.... it may be that my machine has severely fragmented 
memory, I'll try rebooting it tonight..


<lots of interesting stuff shamelessly deleted>

> Even if there are already relatively cheap 64bit x86 boxes around, most
> notably the AMD Opteron / Athlon 64, Windows cannot use its full
> capabilities because the 64bit support is not it yet.
> Read this and you will see that Windows XP on AMD 64bit CPUs will take long
> long time to become a viable option: (a very bumby road I would say)
> http://www.pcworld.com/news/article/0,aid,112749,pg,6,00.asp
>
> On the other hand Linux already runs on AMD 64bit CPUs and linuxsampler is
> 64bit compatible too.
> This means we can beat the windows sampler at their own game: linuxsampler
> already runs on performant 64bit boxes and what's more important we can
> handle much bigger amounts of RAM which is crucial for those wanting to
> load many samples at the same time.
> I guess once linuxsampler's engine is production ready and can play
> preexisting libraries correctly it will turn up on the windows people
> radarscreens, I assume even those using the windows samplers professionally
> because those are the people that need these monster installations with
> dozen, even hundreds of GBs worth of samples.

This could become a real killer feature! :)

> And I don't even touched the fact that linuxsampler could be clustred to
> provide sampler farms that can render thousand of voices and pipe them
> back in real time over ethernet without requiring expensive audio cards,
> midi interfaces etc for each cluster slave.

Hehe, okay, but I think you should save that for version 2 ;).

> > The things I miss are (probably mostly on the todo already)
> >
> > - gui (not strictly necessary)
>
> I have half finished a simple load&play GUI (load samples, assign them
> to midi channels and start playing, plus the GUI permits you to set
> basic settings like number of voices, RAM preload sizes etc, shows you
> activity and real time voice count etc).
> As I stated before linuxsampler is remotely controllable via TCP/IP which
> means the GUI can run on a different box and even on a different platform.
> What I am working on now is the remote control protocol which is a simple
> API that can be used by anone so anyone can build their favorite kind of
> remote control application.
> It can be a GUI, a text based application, a script, hardware buttons etc.
> The default GUI I will provide is written using the Qt library because of
> its portability. This will allow to run the GUI frontend on Windows and
> Mac too.
> This is because I'm assuming sooner or later we will see those linuxsampler
> clusters remote controlled by Windows PCs or Macs :-).
> Plus do not forget separating the frontend from the engine forces you
> to follow certain rules during coding which leads to a better quality
> of the code and helps to isolate errors and performance problems.

sounds great!
>
> > - jack output
>
> Of course. We will go as far that linuxsampler will not only export
> the main output (where all vocies will be mixed too) but single
> midi channel mix buffers which you can send to jack unprocessed
> and process the channels with your own FXes or record the tracks
> into eg ardour for further editing.
> But for now we only support direct ALSA out because we must first
> iron out potential latency problems.
> (if you put jack into the game then you cannot easily figure out
> if it's linuxsampler's or jack's fault).
> Divide et impera is the keyword here :-)
>
> > - soundfont support, for now I'm perfectly happy with gig support, I
> > wonder how hard it would be to add soundfont support though..?
>
> Well soundfont offers quite some modulation possibilities
> (Peter Hanappe and Josh Green know this better than anyone).
> I guess for now if you want SF2 it is better to use fluidsynth.
> SF2 is IMHO a bit limited and linuxsampler aims at the professional
> sampling domain so our priority is to make .GIG working. (at a later stage
> we will try to add 24bit sample in Halion / Kontakt formats too).

yeah, soundfonts may not have the same professional feel, there are lots of 
tome though, and some of the new ones allocate quite a lot of memory.
>
> Or alternatively when our GIG engine will be complete you can try to
> convert your SF2 files using a conversion program like cdxtract
> http://www.cdxtract.com (but relatively expensive $150).
> Or better, integrate the fluid engine to linuxsampler :-)

yeah, I was thinking along those lines :) but I have no idea if it would be 
feasible. 
Josh are you here somewhere? Enlighten me :)

>
> > - hmmm I think I ran it as an ordinary user (with pretty good results),
> > it occurs to me that SCHED_FIFO should not be available then. LS uses
> > SCHED_FIFO
> >
> > right? Should it complain if it can't set it? (this may be a
> > misconception of
> >
> > mine though)
>
> In theory it should complain:
>     if (sched_setscheduler(0, SCHED_FIFO, &schp) != 0) {
>         perror("sched_setscheduler");
>         return -1;
>     }
>
> anyway sched_setscheduler() is deprecated because for threads one should
> use pthread_attr_init() to set priorities.
> I heard rumors that sched_setscheduler() does not work correctly on
> recent threading libraries but I cannot confirm it.

It may be all my fault, I may just as well have run as root out of habit, I 
run most audio stuff as root...

>
> > ----
> > And finally, a wish. I think this mailinglist is too quiet, it's hard to
> > know
> >
> > if there is any activity at all.
> >
> > May I propose that you guys start announcing cvs checkins on this list?
>
> We will certainly announce new (relevant) CVS checkins on the list
> (manually).
> Regarding myself I'm working on the GUI/remote control protocol and it will
> take some time to make it work well, document etc so I guess I will not
> check in new stuff before 1-2 weeks. Perhaps Christian will add some stuff
> meanwhile and I'm sure he will announce it on this mailing list.

Release early, release often :) repeat the mantra.  Though I'm happy if it 
atleast compiles ;)

/Robert

Re: [Linuxsampler-devel] CVS

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

On Tue, 2003-10-28 at 05:07, Robert Jonsson wrote:
> Hi Mark,
> 
> it sounds as if you got the version from sourceforge.net (as I did)
> 
> the real version is at:
> 
> cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler 
> co linuxsampler
> 
> just typeing make after it downloaded worked for me.
> 
> /Robert
> 

Robert,
   Thanks. That downloaded and built fine, but it's not running:


bash-2.05b$ cd LSt/linuxsampler/

bash-2.05b$ ./linuxsampler --gig ../Gigs/Mellotron\ 8Voice.gig 
Initializing audio output...Error snd_pcm_hw_params_set_access: Invalid
argument.
bash-2.05b$ 

This machine is using the infamous HDSP 9652. I can try it on my GSt
machine later this afternoon. That machine uses a Hammerfall Light and
has lots of gig files.

- Mark

Re: [Linuxsampler-devel] Correct sustain pedal emulation (midi hold controller) ?

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

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

> On Tue, 2003-10-28 at 02:12, be...@ga... wrote:
> > Giga seems to have a velocity dynamics problem too.
> 
> Keep in mind that Warren's data here is 3 years old. There have been
> numerous upgrades to GSt. We should take his MIDI file and process out
> the same data, both with GSt and LinuxSampler for verification. Sometime
> this week I will try and do that.
> 
> (I have the Trachtman piano BTW)

ok, if the data is obsoleted the ignore that.
But yes, that you will be able to do A/B tests with the Trachtman piano 
will be very valuable. As always thanks for your contributions Mark.
Keep in mind that volume control is not supported yet in Christian's
articulation stuff so I guess it does not make sense yet to perform 
extensive A/B tests.
Christian what are your plans with the volume articulation ?
Or are there other issues to solve first ?

> 
> > See the very useful comments (with .MID and .GIG test files that show the
> issue)
> > from Warren Trachtman, the maker of the Trachtman Piano for Giga.
> > He talks about the sustain polyphony problem and the piano release mode
> that
> >  does not seem to work.
> 
> But he does give a clue as to what the 'piano release mode' is supposed
> to do, in his mind anyway. That's helpful.

yes.

> 
> > 
> > http://www.wstco.net/gigaissues/
> > 
> > Christian take these velocity issues into account when adding
> > volume support to linuxsampler.
> > 
> > Returning to the pedal polyphony problem: we could provide both
> >  the unlimited voices mode and a limited one, eg you say max 4
> >  voices per key this means if you keep hitting the same key you
> >  if there are more than 4 voices active the older notes will quickly 
> > fade out keeping the polyphony within limits.
> 
> Stay open and have ideas. I think the right answers will likely come
> down to how the sampler plays and what it sounds like. Finding the best
> solutions may come only when we get more musicians involved.

I agree, first make it simple (eg. no limits about the voices
that can be played on a single key) and then extend it.
What were these famous Microsoft tactics again ?
Embrace and extend ? :-)

> Hi,
>   I downloaded (I think) the CVS code. How do I build it? No INSTALL
> instruction file, so I tried:
>
> make -f Makefile.am

We moved away from sourceforge (many are still trying to check out
from sf.net :-) ):

this is the correct command to fetch the CVS:

cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler co
linuxsampler

cheers,
Benno

> 
> - Mark
> 
> 
> 




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

Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity

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

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

> Hi guys,
> 
> I tried linuxsampler yesterday with the aid of benno, looks great! 
> 
> cpu load was low and it seemed pretty stable.
> 
> I encountered a few irks that according to benno are known issues, i'll list
> 
> them just for the record:
> 
> - clicks when doing note_off

this is because the sample is cutoff hard without any release envelope because
the enveloping stuff is still missing. So it is not an error.

> - trying the original gigapiano it sounded very strange when playing hard. To
> 
> me it sounded as if it the samples where played from the wrong key (one 
> octave up), benno told me there where issues with the midimapping which may 
> explain this.

yes exactly, Christian will add the complete articulation implementation
 soon so these strange effects will go away.
(actually libgig supports full articulation, it's linuxsampler that does not
yet honor all the values).

> - it segfaults when ctrl-c:ing out of the app.

probably due to the incorrect stopping of threads when the CTRL-C handler
is called, not a serious issue and probably very easy to fix.
As said it would be more serious if linuxsampler segfaulted during playing. :-)

> - on my system i get mlockall failures all the time, regardless of the size
> of 
> the gig file and such... how much mem does LS allocate? (I've got 512mb so it
> 
> should work rather well I think. I can run debug compiled-muse together with
> 
> jack with no problems, which both do mlockall and occupy lots of memory...)

see diskthread.h:
#define STREAM_BUFFER_SIZE 131072
#define MAX_INPUT_STREAMS 64

this means we can have max 64 disk streams (each voice if streamed from
disk exactly needs one stream).
We are talking about 16bit samples (2bytes) thus
the streams occupy
MAX_INPUT_STREAMS*STREAM_BUFFER_SIZE*2

this is not an extremely high amount, in the above case 16MB

most of the memory is consumed by the pre-cached initial parts of the samples.

see audiothread:
#define NUM_RAM_PRELOAD_SAMPLES

normally we set this value to 65536, which means for mono 16bit samples
we preload 65536*2=128KB of memory for each sample.
If the .GIG contains 1000 samples we use 128KB*1000= about 128MB of memory.
For stereo samples you must multiply the number by 2.
(in the above case 256KB of memory per stereo sample).
Preloading 65536 samples means 1.48secs of samples at 44.1kHz.
This is needed to overcome the delay that occurs for the disk thread
filling up the ringbuffers where the remaining part of the sample will
be streamed from.
The most critical case occurs when you start lots of notes at the same
time. Eg assume we have 50 samples (all different) and start them all
at the same time. This means that within 1.48secs (the RAM part of the sample),
the disk thread has to fill at least some samples in ALL 50 ringbuffers
associated to the voices. This means that in the above case the disk thread
might fail to meet the deadlines and you would risk that the audio thread
wants to fetch the audio data from the diskstream ringbuffers but the data
has not been loaded yet, leading to an error condition (we opted for note cutoff
and report the error).
The solution to this is tuning the disk streaming (there is room for improvement
by cutting read() sizes in critical situations but I will add this stuff at a
later stage), installing faster disks or increase the size of the part of sample
we preload in RAM. 
All disk based samples like giga,kontakt,halion have this problem when
many voices are triggered simultaneously and often the only solution is to
increase the RAM preload size which has the disadvantage that you can load
fewer sample libraries at the same time.
People that make extensive use of disk based sampler often have machines
with 1-2GB RAM to load as much sample libraries as possible.
There are sample libraries that require a minimum of 0.5-1GB to be loaded.
(the size of these libs is often 2-4GB).
For example NI Kontakt while having more features and offering better sample
 manipulation tools than Giga, is not that performant when it comes to streaming
like Giga (giga uses kernel based streaming, special low latency GSIF drivers
etc). This means in Kontakt you have often to increase preload sizes to up to
600KB which greatly reduces the size and number of sample libraries you can
load at the same time.
You know ... 32bit x86 boxes hit the wall at 1-2GB RAM because of the limited
 addressing space but many users using a disk based sampler would like to
install more ram, perhaps 8,16GB and more.
Even if there are already relatively cheap 64bit x86 boxes around, most notably
 the AMD Opteron / Athlon 64, Windows cannot use its full capabilities because
 the 64bit support is not it yet. 
Read this and you will see that Windows XP on AMD 64bit CPUs will take long long
time to become a viable option: (a very bumby road I would say)
http://www.pcworld.com/news/article/0,aid,112749,pg,6,00.asp

On the other hand Linux already runs on AMD 64bit CPUs and linuxsampler is
64bit compatible too.
This means we can beat the windows sampler at their own game: linuxsampler
already runs on performant 64bit boxes and what's more important we can handle
much bigger amounts of RAM which is crucial for those wanting to load many
samples at the same time.
I guess once linuxsampler's engine is production ready and can play
preexisting libraries correctly it will turn up on the windows people 
radarscreens, I assume even those using the windows samplers professionally
because those are the people that need these monster installations with
dozen, even hundreds of GBs worth of samples.
And I don't even touched the fact that linuxsampler could be clustred to
provide sampler farms that can render thousand of voices and pipe them
back in real time over ethernet without requiring expensive audio cards,
midi interfaces etc for each cluster slave.

Only time will tell we we will remain a niche product or we will get 
high visibility. For now let's make work the basic engine perfectly.


Returning to you mlockall problem:
try to lower the NUM_RAM_PRELOAD_SAMPLES eg to 16384 (do a make clean
because there are some dependencies missing in the Makefile).

This could help but keep in mind if you preload fewer samples from disk
you risk to run into the problem described above where the disk thread
is unable to fill the ringbuffer in time, leading to note cut-offs.

> 
> All in all, this looks set to be a real killer app! :)

We're all working hard to make it happen.
As said every contribution count, not only code contributions.
Ideas, testing, debugging, advices from musicians, sampler/samplelibrary
 experts all count.

> 
> The things I miss are (probably mostly on the todo already)
> 
> - gui (not strictly necessary)

I have half finished a simple load&play GUI (load samples, assign them
to midi channels and start playing, plus the GUI permits you to set
basic settings like number of voices, RAM preload sizes etc, shows you
activity and real time voice count etc).
As I stated before linuxsampler is remotely controllable via TCP/IP which
means the GUI can run on a different box and even on a different platform.
What I am working on now is the remote control protocol which is a simple
API that can be used by anone so anyone can build their favorite kind of 
remote control application.
It can be a GUI, a text based application, a script, hardware buttons etc.
The default GUI I will provide is written using the Qt library because of
its portability. This will allow to run the GUI frontend on Windows and 
Mac too.
This is because I'm assuming sooner or later we will see those linuxsampler
clusters remote controlled by Windows PCs or Macs :-).
Plus do not forget separating the frontend from the engine forces you
to follow certain rules during coding which leads to a better quality
of the code and helps to isolate errors and performance problems.


> - jack output

Of course. We will go as far that linuxsampler will not only export
the main output (where all vocies will be mixed too) but single
midi channel mix buffers which you can send to jack unprocessed
and process the channels with your own FXes or record the tracks
into eg ardour for further editing.
But for now we only support direct ALSA out because we must first
iron out potential latency problems.
(if you put jack into the game then you cannot easily figure out
if it's linuxsampler's or jack's fault).
Divide et impera is the keyword here :-)

> - soundfont support, for now I'm perfectly happy with gig support, I wonder 
> how hard it would be to add soundfont support though..?

Well soundfont offers quite some modulation possibilities 
(Peter Hanappe and Josh Green know this better than anyone).
I guess for now if you want SF2 it is better to use fluidsynth.
SF2 is IMHO a bit limited and linuxsampler aims at the professional sampling
 domain so our priority is to make .GIG working. (at a later stage we will
try to add 24bit sample in Halion / Kontakt formats too).

Or alternatively when our GIG engine will be complete you can try to
convert your SF2 files using a conversion program like cdxtract
http://www.cdxtract.com (but relatively expensive $150).
Or better, integrate the fluid engine to linuxsampler :-)

> 
> - hmmm I think I ran it as an ordinary user (with pretty good results), it 
> occurs to me that SCHED_FIFO should not be available then. LS uses SCHED_FIFO
> 
> right? Should it complain if it can't set it? (this may be a misconception of
> 
> mine though)

In theory it should complain:
    if (sched_setscheduler(0, SCHED_FIFO, &schp) != 0) {
        perror("sched_setscheduler");
        return -1;
    }

anyway sched_setscheduler() is deprecated because for threads one should
use pthread_attr_init() to set priorities.
I heard rumors that sched_setscheduler() does not work correctly on
recent threading libraries but I cannot confirm it.


> 
> ----
> And finally, a wish. I think this mailinglist is too quiet, it's hard to know
> 
> if there is any activity at all.
> 
> May I propose that you guys start announcing cvs checkins on this list?

We will certainly announce new (relevant) CVS checkins on the list 
(manually).
Regarding myself I'm working on the GUI/remote control protocol and it will
take some time to make it work well, document etc so I guess I will not
check in new stuff before 1-2 weeks. Perhaps Christian will add some stuff
meanwhile and I'm sure he will announce it on this mailing list.

BTW: for those that wantet to check out the CVS source and did not
find the exact location here is how to get the sources:

cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler co
linuxsampler

cheers,
Benno


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

Re: [Linuxsampler-devel] CVS

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

Hi Mark,

it sounds as if you got the version from sourceforge.net (as I did)

the real version is at:

cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler 
co linuxsampler

just typeing make after it downloaded worked for me.

/Robert


Tuesday 28 October 2003 14.03 skrev Mark Knecht:
> Hi,
>    I downloaded (I think) the CVS code. How do I build it? No INSTALL
> instruction file, so I tried:
>
> make -f Makefile.am
>
> which produced a executable configure file, but then attempting to run
> that configure file failed:
>
> bash-2.05b$ ./configure
> creating cache ./config.cache
> ./configure: line 541: syntax error near unexpected token
> `LinuxSampler,0.0.1'
> ./configure: line 541: `AM_INIT_AUTOMAKE(LinuxSampler,0.0.1)'
> bash-2.05b$
>
>
> This is on Gentoo. The system is very up to date.
>
> - Mark
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

[Linuxsampler-devel] CVS

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

Hi,
   I downloaded (I think) the CVS code. How do I build it? No INSTALL
instruction file, so I tried:

make -f Makefile.am

which produced a executable configure file, but then attempting to run
that configure file failed:

bash-2.05b$ ./configure 
creating cache ./config.cache
./configure: line 541: syntax error near unexpected token
`LinuxSampler,0.0.1'
./configure: line 541: `AM_INIT_AUTOMAKE(LinuxSampler,0.0.1)'
bash-2.05b$ 


This is on Gentoo. The system is very up to date.

- Mark

Re: [Linuxsampler-devel] Correct sustain pedal emulation (midi hold controller) ?

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

On Tue, 2003-10-28 at 02:12, be...@ga... wrote:
> Giga seems to have a velocity dynamics problem too.

Keep in mind that Warren's data here is 3 years old. There have been
numerous upgrades to GSt. We should take his MIDI file and process out
the same data, both with GSt and LinuxSampler for verification. Sometime
this week I will try and do that.

(I have the Trachtman piano BTW)

> See the very useful comments (with .MID and .GIG test files that show the issue)
> from Warren Trachtman, the maker of the Trachtman Piano for Giga.
> He talks about the sustain polyphony problem and the piano release mode that
>  does not seem to work.

But he does give a clue as to what the 'piano release mode' is supposed
to do, in his mind anyway. That's helpful.

> 
> http://www.wstco.net/gigaissues/
> 
> Christian take these velocity issues into account when adding
> volume support to linuxsampler.
> 
> Returning to the pedal polyphony problem: we could provide both
>  the unlimited voices mode and a limited one, eg you say max 4
>  voices per key this means if you keep hitting the same key you
>  if there are more than 4 voices active the older notes will quickly 
> fade out keeping the polyphony within limits.

Stay open and have ideas. I think the right answers will likely come
down to how the sampler plays and what it sounds like. Finding the best
solutions may come only when we get more musicians involved.

- Mark

[Linuxsampler-devel] testing of linuxsampler and cvs activity

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

Hi guys,

I tried linuxsampler yesterday with the aid of benno, looks great! 

cpu load was low and it seemed pretty stable.

I encountered a few irks that according to benno are known issues, i'll list 
them just for the record:

- clicks when doing note_off
- trying the original gigapiano it sounded very strange when playing hard. To 
me it sounded as if it the samples where played from the wrong key (one 
octave up), benno told me there where issues with the midimapping which may 
explain this.
- it segfaults when ctrl-c:ing out of the app.
- on my system i get mlockall failures all the time, regardless of the size of 
the gig file and such... how much mem does LS allocate? (I've got 512mb so it 
should work rather well I think. I can run debug compiled-muse together with 
jack with no problems, which both do mlockall and occupy lots of memory...)

All in all, this looks set to be a real killer app! :)

The things I miss are (probably mostly on the todo already)

- gui (not strictly necessary)
- jack output
- soundfont support, for now I'm perfectly happy with gig support, I wonder 
how hard it would be to add soundfont support though..?

- hmmm I think I ran it as an ordinary user (with pretty good results), it 
occurs to me that SCHED_FIFO should not be available then. LS uses SCHED_FIFO 
right? Should it complain if it can't set it? (this may be a misconception of 
mine though)

----
And finally, a wish. I think this mailinglist is too quiet, it's hard to know 
if there is any activity at all.

May I propose that you guys start announcing cvs checkins on this list?

Regards,
Robert

Re: [Linuxsampler-devel] Correct sustain pedal emulation (midi hold controller) ?

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

Mark as always thanks for your explanations.
The voice buildup when hitting the same key with sustain down
is ok we can easily do that.
But as you (and others, see below) said it leads to high polyphony
consumption which might cause CPU overload or cutting of notes.

Giga seems to have a velocity dynamics problem too.
See the very useful comments (with .MID and .GIG test files that show the issue)
from Warren Trachtman, the maker of the Trachtman Piano for Giga.
He talks about the sustain polyphony problem and the piano release mode that
 does not seem to work.

http://www.wstco.net/gigaissues/

Christian take these velocity issues into account when adding
volume support to linuxsampler.

Returning to the pedal polyphony problem: we could provide both
 the unlimited voices mode and a limited one, eg you say max 4
 voices per key this means if you keep hitting the same key you
 if there are more than 4 voices active the older notes will quickly 
fade out keeping the polyphony within limits.

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


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

> On Mon, 2003-10-27 at 13:05, Christian Schoenebeck wrote:
> > Maybe that is what the "Piano Release Mode" in the gig format is for.
> That's 
> > one of the few things I'm not sure about. Perhaps somebody having access to
> a 
> > Gigasampler can check it? As far as i can remember this is an instrument 
> > global parameter check box somewhere in the instrument editor. So switching
> 
> > on and off this parameter and seeing, ehm sorry, hearing it's actual output
> 
> > influence would be interesting.
> > 
> Christian,
>    The Piano Release Mode choice shows up in the same gig file
> properties screen that has the Drum check box. It is global to the whole
> gig file.
> 
>    Interestingly, it is not being used on my best piano library, the
> Bardstown Bosendorfer.
> 
>    The GigaEdit help file doesn't seem to have any information about it.
> I'll continue to look around tomorrow, either on the machine or maybe at
> Northern Sounds.
> 
> Cheers,
> Mark
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 




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

Re: [Linuxsampler-devel] Correct sustain pedal emulation (midi hold controller) ?

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

On Mon, 2003-10-27 at 13:05, Christian Schoenebeck wrote:
> Maybe that is what the "Piano Release Mode" in the gig format is for. That's 
> one of the few things I'm not sure about. Perhaps somebody having access to a 
> Gigasampler can check it? As far as i can remember this is an instrument 
> global parameter check box somewhere in the instrument editor. So switching 
> on and off this parameter and seeing, ehm sorry, hearing it's actual output 
> influence would be interesting.
> 
Christian,
   The Piano Release Mode choice shows up in the same gig file
properties screen that has the Drum check box. It is global to the whole
gig file.

   Interestingly, it is not being used on my best piano library, the
Bardstown Bosendorfer.

   The GigaEdit help file doesn't seem to have any information about it.
I'll continue to look around tomorrow, either on the machine or maybe at
Northern Sounds.

Cheers,
Mark

Re: [Linuxsampler-devel] Correct sustain pedal emulation (midi hold controller) ?

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

Es geschah am Montag, 27. Oktober 2003 22:19 als Mark Knecht schrieb:
>    Another interesting one I noticed the other day was a single check
> box in the overall properties for a gig file simply called 'drum'.

That's already defined in DLS. It will cause not to pitch sample(s) if 
triggered by a key not equal it's root note.

> BTW - I sent Steve the impulse data that I took. Would you like a copy
> of that, or even a copy of the gig files I built to acquire it? If so,
> let me know.

At the moment I'm quite busy. Some of the basic functions are still not 
finished yet (e.g. looping, sustain, etc.), so I hope Steve will find the 
time to pick up the right VCF algorithms in the meantime. If not I will pleas 
you for your result samples (maybe in a week or so).

Thanks Mark!

Christian

Re: [Linuxsampler-devel] Correct sustain pedal emulation (midi hold controller) ?

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

On Mon, 2003-10-27 at 13:05, Christian Schoenebeck wrote:
> Es geschah am Montag, 27. Oktober 2003 16:31 als Mark Knecht schrieb:
> > > While I am not a piano player,common sense says me thatpiano has only one
> > > string per key so IMHO it would sound unnatural to play two
> > > notes on the same key.
> >
> > Yes, for a piano it would see unnatural. However, the keyboard you are
> > pressing has to work for all instruments, not just piano...
> 
> Maybe that is what the "Piano Release Mode" in the gig format is for. That's 
> one of the few things I'm not sure about. Perhaps somebody having access to a 
> Gigasampler can check it? As far as i can remember this is an instrument 
> global parameter check box somewhere in the instrument editor. So switching 
> on and off this parameter and seeing, ehm sorry, hearing it's actual output 
> influence would be interesting.
> 
> CU
> Christian

Christian,
   I'd be happy to take a look. 

   Another interesting one I noticed the other day was a single check
box in the overall properties for a gig file simply called 'drum'.

BTW - I sent Steve the impulse data that I took. Would you like a copy
of that, or even a copy of the gig files I built to acquire it? If so,
let me know.

Mark

Re: [Linuxsampler-devel] Correct sustain pedal emulation (midi hold controller) ?

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

Es geschah am Montag, 27. Oktober 2003 16:31 als Mark Knecht schrieb:
> > While I am not a piano player,common sense says me thatpiano has only one
> > string per key so IMHO it would sound unnatural to play two
> > notes on the same key.
>
> Yes, for a piano it would see unnatural. However, the keyboard you are
> pressing has to work for all instruments, not just piano...

Maybe that is what the "Piano Release Mode" in the gig format is for. That's 
one of the few things I'm not sure about. Perhaps somebody having access to a 
Gigasampler can check it? As far as i can remember this is an instrument 
global parameter check box somewhere in the instrument editor. So switching 
on and off this parameter and seeing, ehm sorry, hearing it's actual output 
influence would be interesting.

CU
Christian

Re: [Linuxsampler-devel] Correct sustain pedal emulation (midi hold controller) ?

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

On Mon, 2003-10-27 at 02:52, be...@ga... wrote:
> Hi,
> I was wondering what's the correct way to handle the sustain pedal when
> implementing a MIDI sound generating module.

In my experience it is implementation dependent. There is no 'right' or
'wrong' way to handle it. Different synths do this differently, and it
depends on what you are going to use them for. See below...

I think the term to use in this discussion is 'retrigger'.

> 
> from the MIDI specs:
> -----------
> Hold Pedal, controller number: 64:
> When on, this holds (ie, sustains) notes that are playing, even if the musician
> releases the notes. (ie, The Note Off effect is postponed until the musician
> switches the Hold Pedal off). If a MultiTimbral device, then each Part usually
> has its own Hold Pedal setting.
> Note: When on, this also postpones any All Notes Off controller message on the
> same channel.
> Value Range: 0 (to 63) is off. 127 (to 64) is on.
> --------------
> 
> My question is about ".... holds (ie, sustains) notes that are playing, even if
> the musician releases the notes."
> 
> Assume I play a chord, press the hold pedal, which causes the notes to be
> sustained. When I play new notes those are sustained too.
> So far so good.
> The question arises when I press the same key two times.
> Assume no sustain pedal for now.
> When I press C2 I hear the note. When I release it the sound does not vanish
> immediately but takes a small amout of time to decay due to the release
> envelope. If after releasing C2 I immediately press C2 again I hear two C2 notes
> for a brief time.
> 
> Now same situation as above but with the sustain pedal pressed.
> You hear the first C2, release it (the corresponding note-off is postponed) and
> then press C2 again.
> In that case is it correct that you must hear two sustained C2 notes.
> Or must the first C2 be forced to get faded out  / muted ?
> If not (eg you hear two sustained C2 notes), how far can this go ?
> Can there be 3, 4 etc sustained notes on the same key too ?

In GSt there are multiple sustained notes using the same sample. You can
see it in the voice usage info. Hit the first C2 (with sustain pedal
down) and voice count goes to 2.(Stereo library)  Let go and wait the
FULL length of the sample with the sustain pedal down and *eventually*
the voice count goes back to 0. (After the sample length of 30 seconds
on the Bardstown piano.)

Now, push sustain, hit C2, voice count = 2, release, voice count still =
2, push C2 again, voice count = 4, release, still = 4, push C2 again,
voice count = 6, release, still 6.

This can go as far as you let it. In GSt96 it can go to 96 voices. (And
it can crash GSt too!) ;-)

This will build up for roughly 30 seconds. At that point the sample from
the very first key press runs out, and voice count reduces by 2, then 2
again, then 2 again as each key press runs out.

> 
> While I am not a piano player,common sense says me thatpiano has only one string
> per key so IMHO it would sound unnatural to play two
> notes on the same key.

Yes, for a piano it would see unnatural. However, the keyboard you are
pressing has to work for all instruments, not just piano...

Let's consider trumpets. Is the sample library which is mapped to the
keyboard representing one trumpet player? Or is it representing as many
trumpet players as you need. Often I will score 3-5 trumpet (or sax,
trombone, etc.) tracks and send all of them on the same MIDI channel. By
setting the dynamics and timing of each track a bit differently I get
something that sounds more like a real horn section:

MIDI Track 1 - C2-velocity=85
MIDI Track 2 - C2-velocity=65, delay 5mS
MIDI Track 3 - C2-velocity=75, delay 13mS

If you didn't like me doing this (for whatever reason) then I could
place the same library on different MIDI channels in LinuxSampler, but
that would likely require you to load the same samples into memory and
that's a bit of a waste.

The above technique works even better when you use different libraries
for each track, so that the trumpet samples sound even more different,
but works fine with a single library. The orchestral guys use a single
library, like Garritan's string stuff, but score 20-30 tracks of violins
building up the sound of an orchestra. (Or so I'm told!) ;-)

> 
> As you might have guessed I ask this stuff because we want to add
> support of sustain in linuxsampler.

I might have guessed! ;-)

> 
> thanks for your infos.

You're welcome.
> 
> PS: a new CVS repository for linuxsampler is up: cvs.linuxsampler.org
> interested developers and users please check it out and give us feedback
> via mailing list.

Cool! Will do!

- Mark

Re: [Linuxsampler-devel] Correct sustain pedal emulation (midi hold controller) ?

[holborn <ho...@te...>]

Hi .. Benno ..


On Lunes, 27 de Octubre de 2003 10:52, be...@ga... wrote:
> Hi,
> I was wondering what's the correct way to handle the sustain pedal when
> implementing a MIDI sound generating module.
>
> from the MIDI specs:
> -----------
> Hold Pedal, controller number: 64:
> When on, this holds (ie, sustains) notes that are playing, even if the
> musician releases the notes. (ie, The Note Off effect is postponed until
> the musician switches the Hold Pedal off). If a MultiTimbral device, then
> each Part usually has its own Hold Pedal setting.
> Note: When on, this also postpones any All Notes Off controller message on
> the same channel.
> Value Range: 0 (to 63) is off. 127 (to 64) is on.
> --------------

Well ... that's not exactly .. in a real acoustic piano ... if you press the 
sustain pedal ... the release is not infinite ...  sounds goes down even with 
this pedal pressed, in commercial synthesizers for piano like sounds that's 
is emulated ... of course the release is to mutch long than if you dont have 
pressed this pedal.
For a brass sound for example the release if you press this pedal is infinite.

> Now same situation as above but with the sustain pedal pressed.
> You hear the first C2, release it (the corresponding note-off is postponed)
> and then press C2 again.
> In that case is it correct that you must hear two sustained C2 notes.
> Or must the first C2 be forced to get faded out  / muted ?
> If not (eg you hear two sustained C2 notes), how far can this go ?
> Can there be 3, 4 etc sustained notes on the same key too ?

Well i'm no sure how the commercial synthesizers or electronic pianos manage 
this but y supose they maintain the "old" note. In a real acoustic piano .. 
the resonance produced when you press this pedal and you have notes hold 
produces different concomitants harmonics, that varies the timbre of a note 
if you have other notes hold ... that is not emulated by electronic machines, 
some electronic machines generates random harmonics only ... well i'm not 
sure about if the new new models can emulate this.

I think a good police is maintain the old note sound ... almost when the new 
note attack-decay sounds... 


Josep


 

[Linuxsampler-devel] Correct sustain pedal emulation (midi hold controller) ?

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

Hi,
I was wondering what's the correct way to handle the sustain pedal when
implementing a MIDI sound generating module.

from the MIDI specs:
-----------
Hold Pedal, controller number: 64:
When on, this holds (ie, sustains) notes that are playing, even if the musician
releases the notes. (ie, The Note Off effect is postponed until the musician
switches the Hold Pedal off). If a MultiTimbral device, then each Part usually
has its own Hold Pedal setting.
Note: When on, this also postpones any All Notes Off controller message on the
same channel.
Value Range: 0 (to 63) is off. 127 (to 64) is on.
--------------

My question is about ".... holds (ie, sustains) notes that are playing, even if
the musician releases the notes."

Assume I play a chord, press the hold pedal, which causes the notes to be
sustained. When I play new notes those are sustained too.
So far so good.
The question arises when I press the same key two times.
Assume no sustain pedal for now.
When I press C2 I hear the note. When I release it the sound does not vanish
immediately but takes a small amout of time to decay due to the release
envelope. If after releasing C2 I immediately press C2 again I hear two C2 notes
for a brief time.

Now same situation as above but with the sustain pedal pressed.
You hear the first C2, release it (the corresponding note-off is postponed) and
then press C2 again.
In that case is it correct that you must hear two sustained C2 notes.
Or must the first C2 be forced to get faded out  / muted ?
If not (eg you hear two sustained C2 notes), how far can this go ?
Can there be 3, 4 etc sustained notes on the same key too ?

While I am not a piano player,common sense says me thatpiano has only one string
per key so IMHO it would sound unnatural to play two
notes on the same key.

As you might have guessed I ask this stuff because we want to add
support of sustain in linuxsampler.

thanks for your infos.

PS: a new CVS repository for linuxsampler is up: cvs.linuxsampler.org
interested developers and users please check it out and give us feedback
via mailing list.


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



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

[Linuxsampler-devel] GigaStudio24 / Sample Format

[\\\Mr.Freeze\\\ <the...@fr...>]

Heyall!

I don't have a running Windows installation anymore on my machine, hence a
leftover official OEM copy of Nemesys' GigaStudio24 bundled with my Terratec EWX
24/96. To be able to use it again, I would have to afford a Windows license and
provide some exotic brainstorm to install it (this GSIF-compliant soundcard has
only been detected ONCE within Win2k on this piece of software)...
Well, this ain't the interesting part for you.

Eventhough my first and previous question here hasn't really been replied to,
I'd like to grant this CD for free to either one of both LinuxSampler project
leaders (this ain't any sort of giveaway) to contribute to this project on whom
I trust, as I can't afford coding skills due to my momentary immature brain cells...

The GigaEditor doesn't require any GSIF-compliance.
Wine-able (should I keep it then)?

Up to you!

I'll have a second try:
Do you plan to embed a proprietary (but open) LinuxSampler sample extension?
If true, with what specifications?

++
Mr.Freeze

[Linuxsampler-devel] Gigasampler filter reengineering

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

Hey guys!

As you probably know, we finally made big advances in finishing a first engine 
providing gig playback. Benno and I are currently just making final 
optimizations and corrections. It will first only allow simple sample 
playback, but I'm already looking ahead to complete it with full support of 
all articulation data the gig format offers. For that we need somebody with 
access to a running Gigasampler/Gigastudio installation to record some 
samples using Gigasampler's filter, so we can choose VCF algorithms that come 
as close as possible to the original filter characteristics. You don't have 
to be an DSP expert to do this, nor is it a hard task.

This is what you have to do: Take the following samples which Benno already 
prepared for you:

	http://www.linuxsampler.org/peakwavs.tar.gz

These are two samples; one stereo, one mono. You can choose between one of 
them. These samples are short pulse samples, means null samples with one 
hard, straight flank. Create a new gig instrument in Gigasampler's instrument 
editor and import the wave. Create a region in the instrument, so you can 
actually play the sample. Make sure that the sample will be played as is, 
means use a dry, hard amplitude envelope (most important an attack time of 
0.0s), stuff like LFOs and of course effects etc. all turned off, activate 
the filter using fix values for resonance and cutoff frequency, play the 
sample and record the output. Do this for different values of cutoff and 
resonance, where you can do discrete steps of e.g. 16 or 32, choose it 
yourself, but note: it's important that you play the sample by it's original 
sample frequency, so trigger the sample by it's root note (a.k.a. unity note) 
only and be sure there's no fine pitching set or something like that, else 
Gigasampler's interpolator could wash away the hard flank we need. You could 
make samples with following values for example (resonance, cuttoff):

	(0,0),(0,32),(0,64),(0,96),(0,127),
	(32,0),(32,32),(32,64),(32,96),(32,127),
	(64,0),(64,32),(64,64),(64,96),(64,127),
	(96,0),(96,32),(96,64),(96,96),(96,127),
	(127,0),(127,32),(127,64),(127,96),(127,127)

Repeat that for the 5 filter types Gigasampler provides: Lopez, ... no just 
kidding: lowpass, lowpass turbo, bandpass, highpass and band reject.

And finally let us get your samples somehow.

It would be great if somebody could do that!

CU
Christian

[Linuxsampler-devel] DLS, libInstPatch and Python

[Josh G. <jg...@us...>]

Just wanted to mention what I'm up to with Swami/libInstPatch
development branch CVS and also some things about DLS files I'm finding.

libInstPatch is now split off from Swami and stand alone. I just got a
Python binding working with it, which has been real nice for testing
purposes, since creating a script is rather simple, and using
libInstPatch in an interactive Python shell comes in handy too. I've
been holding off on Swami development, till I get libInstPatch in a nice
state (been overhauling a few things to increase performance and the
like).

I finally realized that some P2P networks would be a good place to look
for DLS files, so I found a bunch of them there. Most of them are DLS1,
but I did find a DLS2 file finally. Its nice to throw some of them at
the DLS parser in libInstPatch, since I found some places where things
were being a bit too strict about things. I've also seen lots of weired
custom chunks, which I'm trying to figure out what to do with from an
editing stand point (should libInstPatch try and preserve custom unknown
chunks?)

I just ran into a DLS1 file that stores its audio as MP3!! I've often
thought about this before, but I figured that the looping would be a
problem (hard to ensure that the loop points overlap well after
de-compression). This file was written by Awave Studio
(http://www.fmjsoft.com/awmain.shtml). Anyways, just thought I'd throw
that one out there since it seems interesting that programs are actually
using other than PCM 8/16 bit formats. Ohh, and to correct something I
said before, it kind of sounds like DLS1/2 doesn't officially support
stereo interleaved samples, guess that didn't stop GigaSampler from
doing it though. There are a number of things that seem kind of
confusing with the DLS format though, this might become a nightmare as
more DLS editors have their own spin on how things should be done. The
upside is that the DLS format is rather customizable. I've already seen
a few files being flexible about what kind of sample data is used (MP3
being one example). Cheers.
	Josh Green

P.S. I have yet to commit any of my recent work, since it has been
rather broken up until a few days ago. I'll be creating a new toplevel
libinstpatch directory in the CVS repository soon though.

Re: [Linuxsampler-devel] stereo samples format in DLS2/GIG ?

[Josh G. <jg...@us...>]

On Mon, 2003-09-15 at 05:57, be...@ga... wrote:
> Hi, I was just wondering if Christian, Josh or others
> could enlighten me how stereo stamples are stored in DLS2 / GIG files.
> 
> Are they stored as a single interleaved stereo sample or 
> as two separate mono samples where the first is mapped to the
> left output channel while the second to the right channel ?
> Treating stereo samples as two mono samples has the 
> advantage that you can set different loop points, modulation etc stuff.
> 

I'm going to answer for DLS2 since I'm not real sure what GigaSampler
files allow.

Either way is possible actually. A sample can be stored as stereo
interleaved or as individual synchronized mono samples (or even multiple
synchronized surround sound samples). I think the first sample in an
instrument determines the tuning and loop stuff though. So the samples
have to be synchronized.

> Regarding the sample sizes: I've seen only GIG files with 16bit
> samples in in them so far. Is 24bit possible ? If yes, how
> are they stored ? 24-bit packed ? (which means 3 32 bit words
> store 4 24 bit samples).

The DLS2 specification defines that only 8 bit or 16 bit data should be
found in the sample pool. The format is very flexible though, since it
is essentially just embedded wave files. So in theory if one were to use
conditional chunks (a feature in DLS2 files) you could create a new
24bit DLSID signature (globally unique ID) and then use that in your
program without breaking things too badly. This actually might not even
be necessary though. If one were to just write 24 bit wave samples, I'm
sure loading programs would detect this and balk at it, it just wouldn't
be within the DLS2 specs (not breaking the file format though).

> In order to read these 24bit samples from disk efficiently (in large 
> chunks) probably we would need a temporary buffer because 
> the streaming ringbuffers (which in case of 16bit samples are arrays
> of 16bit quantities (=short datatype)), cannot easily cope
> with 3-bytes long (24bit) quantities.
> Ok they can (the ringbuffer.h template class can handle any kind
> of datatype so just define sample_24bit_t as char[3].
> But I guess in order to not incur into CPU read/write penalties
> because usually the x86 needs 32bit-aligned read/writes to be able
> to work with the maximum efficientcy,
> we whould just fit the 24bit samples into 32bit words.
> 

Well I guess as long as you are out of DLS2 specs you could probably
store any format that wave files support. Looks like 32 bit integer, 32
bit float and 64 bit float are all formats you can store in a wave file.
These wouldn't suffer from the alignment issues, but would cause the
file to be larger of course (hmm, now that I think about it, RIFF files
are only 2 byte aligned, I wonder if there is a way to pad 2 bytes when
writing 4 byte samples, if someone was to say mmap the whole mess). It
seems DLS2/GigaSampler files are probably limited to 4Gigs, since thats
the limit of RIFF files.

> Or am I wrong about the read/write alignement issues ?
> 
> thoughts ?
> 
> Benno
> 

I really like the DLS2 specification when it comes to the file format.
It seems to be very flexible and is fairly extend-able (through the use
of conditional chunks and the like). Unfortunately there is a lot of
stuff that seems to be somewhat undefined in the area of modulator
connection blocks and additional audio data formats. As there really
aren't a lot of DLS2 files out on the net, its hard to get an idea of
whats okay and whats not okay. It would be nice to take advantage of >
16 bit width audio, its just deciding how this should be done, and
checking if maybe there is already a program out there that has done it
so we could keep compatibility with other implementations.
Its kind of funny too, since DLS2 is being implemented in rather
interesting stuff (MPEG4 and MS Media player and Quicktime have soft
synth support for playing back MIDI files with DLS2 instruments), but I
cannot find one DLS2 file on the net! Time for an open source editor :)
Cheers.
	Josh Green

[Linuxsampler-devel] stereo samples format in DLS2/GIG ?

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

Hi, I was just wondering if Christian, Josh or others
could enlighten me how stereo stamples are stored in DLS2 / GIG files.

Are they stored as a single interleaved stereo sample or 
as two separate mono samples where the first is mapped to the
left output channel while the second to the right channel ?
Treating stereo samples as two mono samples has the 
advantage that you can set different loop points, modulation etc stuff.

Regarding the sample sizes: I've seen only GIG files with 16bit
samples in in them so far. Is 24bit possible ? If yes, how
are they stored ? 24-bit packed ? (which means 3 32 bit words
store 4 24 bit samples).
In order to read these 24bit samples from disk efficiently (in large 
chunks) probably we would need a temporary buffer because 
the streaming ringbuffers (which in case of 16bit samples are arrays
of 16bit quantities (=short datatype)), cannot easily cope
with 3-bytes long (24bit) quantities.
Ok they can (the ringbuffer.h template class can handle any kind
of datatype so just define sample_24bit_t as char[3].
But I guess in order to not incur into CPU read/write penalties
because usually the x86 needs 32bit-aligned read/writes to be able
to work with the maximum efficientcy,
we whould just fit the 24bit samples into 32bit words.

Or am I wrong about the read/write alignement issues ?

thoughts ?

Benno


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

Re: [Linuxsampler-devel] libgig - preliminary version finished

[Josh G. <jg...@us...>]

On Sat, 2003-09-13 at 18:33, Benno Senoner wrote:
> > Any interest in making an API that would allow this to be used with
> > other GUIs, such as Swami?
> 
> Of course !
> Since lately I gathered useful experience about the decoupling
> of GUI and engine, I'll add the same concepts to evo thus
> it will have a simple to use API (probably through a socket
> or form of IPC) and driving it from swami will become a breeze.
> Reusability of components anyone ? ;-)
> 

Cool! Looking forward to working on integrating LinuxSampler with Swami
:)

> > Still trying to see if these projects can
> > work together on something. It would be cool to add LinuxSampler as a
> > wavetable soft synth to Swami.
> 
> Yes this be ideal because you are probably becoming the reference
>  sample library editor in the Linux field.
> Josh, Christian: about libgig and swami: I know swami is in C while
> libgig is in C++, but in order to avoid code duplication, would
> it make sense for swami to use libgig via C wrapper or do you think
> it would be easier to read and write GIG/DLS2 using your infrastructure
> that is already in place ?

It doesn't make sense for me to use libgig, because libInstPatch
provides a standard object API to multiple formats and will provide
conversion, multi-thread locking and parameter change tracking and it
fits quite well with the rest of Swami.

It would be interesting to see what kind of API could be created for
LinuxSampler that would be generic enough to allow for different formats
to be synthesized into voices. This is currently how FluidSynth does
things (with the limitation that its SoundFont centric). So basically
when a note on event occurs, my note_on handler gets called which
creates each voice containing the sample and SoundFont parameters. This
makes it easy to synthesize other formats, like my GigaSampler tests. If
a similar voice based API could be realized with GigaSampler it would
mean that libInstPatch/Swami could then easily synthesize different
formats via LinuxSampler. So the issue of having different instrument
libraries wouldn't be such a big deal, except that it is duplication of
effort of course.

> As said I'd like swami to become a fully fledged GIG/DLS2 editor
> that permit the creation of, access and edit that kind of sample libraries,
> without trying to fit them in a SF2 model.
> 

Right, Swami 1.0 (development branch) is already non-SF2 centric. Just
got to get the damn thing working :)

> > I hope I can make it to the LAD ZKM 2004
> 
> Yes that will be cool, I'll be there too if LinuxSampler gets ready for 
> that time (probably yes).
> 
> Benno
> 

I'd really like to make it myself, even if I don't have my own projects
in a stable state :) A lot of it comes down to my financial situation,
though. Cheers.
	Josh Green

Re: [Linuxsampler-devel] libgig - preliminary version finished

[Josh G. <jg...@us...>]

On Sun, 2003-09-14 at 17:58, Christian Schoenebeck wrote:
> And Josh, btw. i found out that the options field in
> LIST(3prg)->LIST(3ewl)-><wsmp> is abused for the crossfading points, so 
> instead of
> 
> 	DWORD options;
> 
> there is
> 
> 	BYTE crossfade_in_start;   // Start position of fade in
>         BYTE crossfade_in_end;     // End position of fade in
>         BYTE crossfade_out_start;  // Start position of fade out
>         BYTE crossfade_out_end;    // End postition of fade out
> 

I was wondering where the cross fading stuff was being put. Good to know
:) I've been looking into how to emulate cross fading with SoundFont
modulators or DLS2 connection blocks, if one were to convert to those
formats. As you probably know, the DLS2 parameter model is essentially
SoundFont modulators (a fixed parameter has constant inputs, rather than
a controller), but I'm still a little unsure whats allowed. There is a
defined list of "connection blocks" (modulators), but I'm curious if it
breaks the format to put ones own custom ones in there. It would be sad
if custom modulators weren't allowed, because that would mean that DLS2
would be weaker than SF2 in that regard.

> CU
> Christian
> 

Cheers.
	Josh Green

Re: [Linuxsampler-devel] libgig - preliminary version finished

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

Es geschah am Samstag, 13. September 2003 21:43 als Josh Green schrieb:
> Isn't the <3ewg> chunk like so? (from Ruben's findings)
Man I'm blind, haven't seen that, but you're right.

>
>   guint32 attenuate;
signed (in dB)

>   guint16 effect_send;
only interesting for the gigastudio routing not for us

>   guint16 fine_tune;
signed, in cents

>   guint16 pitch_bend_range;
unsigned, number of semitones pitchbend controller should be able to pitch

>   guint8 dim_key_start;
lowest bit here is PianoReleaseMode flag (whatever that means),
the bits above (dim_key_start >> 1;) is the key position of dim start (0-127 
or C1 - G9)

>   guint8 dim_key_end;
that one hasn't to be bitshifted, it's already the key number of dim end 
(0-127, C1 - G9)

But I'm not really sure about the sense of the last two parameters yet.

And Josh, btw. i found out that the options field in
LIST(3prg)->LIST(3ewl)-><wsmp> is abused for the crossfading points, so 
instead of

	DWORD options;

there is

	BYTE crossfade_in_start;   // Start position of fade in
        BYTE crossfade_in_end;     // End position of fade in
        BYTE crossfade_out_start;  // Start position of fade out
        BYTE crossfade_out_end;    // End postition of fade out

CU
Christian

Re: [Linuxsampler-devel] libgig - preliminary version finished

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

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


> > As for the GUI, evo is currently GUI-less but we will probably
> > add a minimalistic load&play GUI (no sample editing), which
> > permits you to load samples, assign them to various MIDI channels,
> > perhaps storing performance data (you load a set of samples,
> > assign them to midi channels, set volumes and some other basic
> > parameters and save the setup, so that next time you can load
> > the whole performance with a single command).
> > 
> 
> Any interest in making an API that would allow this to be used with
> other GUIs, such as Swami?

Of course !
Since lately I gathered useful experience about the decoupling
of GUI and engine, I'll add the same concepts to evo thus
it will have a simple to use API (probably through a socket
or form of IPC) and driving it from swami will become a breeze.
Reusability of components anyone ? ;-)

> Still trying to see if these projects can
> work together on something. It would be cool to add LinuxSampler as a
> wavetable soft synth to Swami.

Yes this be ideal because you are probably becoming the reference
 sample library editor in the Linux field.
Josh, Christian: about libgig and swami: I know swami is in C while
libgig is in C++, but in order to avoid code duplication, would
it make sense for swami to use libgig via C wrapper or do you think
it would be easier to read and write GIG/DLS2 using your infrastructure
that is already in place ?
As said I'd like swami to become a fully fledged GIG/DLS2 editor
that permit the creation of, access and edit that kind of sample libraries,
without trying to fit them in a SF2 model.

> I hope I can make it to the LAD ZKM 2004

Yes that will be cool, I'll be there too if LinuxSampler gets ready for 
that time (probably yes).

Benno


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