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

Re: [Linuxsampler-devel] giga velocity setting algorithm

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

Es geschah am Dienstag, 2. Dezember 2003 06:45 als Mark Knecht schrieb:
> Groovy! Should I be downloading a new version and enjoying both velocity
> and envelopes soon? ;-)

First off I'm not sure if it got around here, so just a little hint: we have a 
CVS log running on http://www.linuxsampler.org showing the latest commits to 
the CVS repository, means whenever somebody commits something it will 
immediately show up on the website.

Regarding the velocity: I've already commited an initial version supporting it 
last saturday.

CU
Christian

Re: [Linuxsampler-devel] giga velocity setting algorithm

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

Groovy! Should I be downloading a new version and enjoying both velocity
and envelopes soon? ;-)

- Mark

On Mon, 2003-12-01 at 15:03, Christian Schoenebeck wrote:
> Hi Kenneth,
> 
> not really sure what you actually want to hear, but these are the velocity 
> algorithms that are currently used in LinuxSampler (/src/gig.h):
> 
> #define GIG_VELOCITY_TRANSFORM_NONLINEAR(x,dynamic,scale)	((1.0-1.0/pow(x,1.0/
> (129.0-x))) * (1.0+scale/20.0) + (5.0-dynamic)*pow(x/300.0* (1.0
> +2.0*scale/128.0),2))
> 
> #define GIG_VELOCITY_TRANSFORM_LINEAR(x,dynamic,scale)		((1.0
> +scale*3.0/128.0)/110.0*x+(5.0-dynamic)/5.0+(5.0-dynamic)*scale)
> 
> #define GIG_VELOCITY_TRANSFORM_SPECIAL(x,dynamic,scale)		((1.0
> +9.0*scale/129.0)*(1.0-1.0/pow(x,1.0/(129.0-x))+pow(3.0*x/pow(129,2),2)
> +pow((5.0-dynamic)*x/500.0,2)))
> 
> These are only approximations to the ones from Gigasampler. 'x' is the MIDI 
> velocity value, 'dynamic' is the dynamic range parameter and 'scale' the 
> curve scale parameter from the gig format. Not sure if that helps...
> 
> CU
> Christian
> 
> Es geschah am Montag, 1. Dezember 2003 08:40 als Kenneth Lee schrieb:
> > Mark,
> >
> > i mean using Linux tools. i am using Lilypond to
> > produce piano music sheet. pmidi to play midi files
> > which are generated from Lilypind throught timidity++
> > (now LinuxSampler). The midi files produced by
> > Lilypond is good enought to proof-hearing but not
> > adequate for listening. Therefore, some touchup is
> > required for each file. What i am trying to do is to
> > write a simple pre-lilypond processor which could be
> > used to produce lilypond file for generating piano
> > music sheet. Also, the processor should be able to
> > produce midi file with specific attributes per note.
> > Based on the above mentioned, i am tring to play
> > around with the duration and velocity of the midi
> > file. At this stage, it seems to me that the result of
> > different velocity setting is not obvious to me,
> > therefore, i am asking for advice.
> >
> > Highly likely that there are some Linux tools already
> > available for the above mentioned, please kindly let
> > me know.
> >
> >
> > Many thanks!
> >
> > kenneth
> 
> 
> 
> -------------------------------------------------------
> 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] giga velocity setting algorithm

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

Hi Kenneth,

not really sure what you actually want to hear, but these are the velocity 
algorithms that are currently used in LinuxSampler (/src/gig.h):

#define GIG_VELOCITY_TRANSFORM_NONLINEAR(x,dynamic,scale)	((1.0-1.0/pow(x,1.0/
(129.0-x))) * (1.0+scale/20.0) + (5.0-dynamic)*pow(x/300.0* (1.0
+2.0*scale/128.0),2))

#define GIG_VELOCITY_TRANSFORM_LINEAR(x,dynamic,scale)		((1.0
+scale*3.0/128.0)/110.0*x+(5.0-dynamic)/5.0+(5.0-dynamic)*scale)

#define GIG_VELOCITY_TRANSFORM_SPECIAL(x,dynamic,scale)		((1.0
+9.0*scale/129.0)*(1.0-1.0/pow(x,1.0/(129.0-x))+pow(3.0*x/pow(129,2),2)
+pow((5.0-dynamic)*x/500.0,2)))

These are only approximations to the ones from Gigasampler. 'x' is the MIDI 
velocity value, 'dynamic' is the dynamic range parameter and 'scale' the 
curve scale parameter from the gig format. Not sure if that helps...

CU
Christian

Es geschah am Montag, 1. Dezember 2003 08:40 als Kenneth Lee schrieb:
> Mark,
>
> i mean using Linux tools. i am using Lilypond to
> produce piano music sheet. pmidi to play midi files
> which are generated from Lilypind throught timidity++
> (now LinuxSampler). The midi files produced by
> Lilypond is good enought to proof-hearing but not
> adequate for listening. Therefore, some touchup is
> required for each file. What i am trying to do is to
> write a simple pre-lilypond processor which could be
> used to produce lilypond file for generating piano
> music sheet. Also, the processor should be able to
> produce midi file with specific attributes per note.
> Based on the above mentioned, i am tring to play
> around with the duration and velocity of the midi
> file. At this stage, it seems to me that the result of
> different velocity setting is not obvious to me,
> therefore, i am asking for advice.
>
> Highly likely that there are some Linux tools already
> available for the above mentioned, please kindly let
> me know.
>
>
> Many thanks!
>
> kenneth

Re: [Linuxsampler-devel] giga velocity setting algorithm

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

I have not heard of anything like this. Sorry.

On Sun, 2003-11-30 at 23:40, Kenneth Lee wrote:
> Mark,
> 
> i mean using Linux tools. i am using Lilypond to
> produce piano music sheet. pmidi to play midi files
> which are generated from Lilypind throught timidity++
> (now LinuxSampler). The midi files produced by
> Lilypond is good enought to proof-hearing but not
> adequate for listening. Therefore, some touchup is
> required for each file. What i am trying to do is to
> write a simple pre-lilypond processor which could be
> used to produce lilypond file for generating piano
> music sheet. Also, the processor should be able to
> produce midi file with specific attributes per note.
> Based on the above mentioned, i am tring to play
> around with the duration and velocity of the midi
> file. At this stage, it seems to me that the result of
> different velocity setting is not obvious to me,
> therefore, i am asking for advice.
> 
> Highly likely that there are some Linux tools already
> available for the above mentioned, please kindly let
> me know.
> 
> 
> Many thanks!
> 
> kenneth
> 
> 
>  --- Mark Knecht <mar...@co...> wrote: > On
> Sun, 2003-11-30 at 18:45, Kenneth Lee wrote:
> > > hi,
> > > 
> > > i am not sure whether here is the right place to
> > ask
> > > but your help would be deeply appreciated.
> > > 
> > > if i try to set the velocity per midi note
> > manually,
> > > the output is not obvious to me. is there any
> > > reference about the giga velocity setting
> > algorithm?
> > > so that i can use sensibly velocity setting.
> > > 
> > > Many thanks and best regards,
> > > kenneth lee
> > > 
> > 
> > Kenneth,
> >    Are you talking about setting the velocity
> > mapping in GigaSampler? Or
> > in some Linux tool?
> > 
> >    I just did some mapping work on GSt.
> > 
> > Mark
> >  
> 
> _______________________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com.hk address at http://mail.english.yahoo.com.hk
> 
> 
> -------------------------------------------------------
> 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] FlacPak - Free lossless instrument compression

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

In the past few weeks I've been working on defining a new standard
called FlacPak for compressing MIDI instrument patch files. This format
uses FLAC (Free Lossless Audio Codec) and zlib to compress audio and
binary data respectively. By using FLAC for audio and exploiting other
characteristics of instrument files (stereo samples, differing bit
widths, etc) much better compression can be achieved then if just using
a binary compressor.

Currently SoundFont, Downloadable Sounds (DLS) and GigaSampler files are
supported. Adding support for a particular instrument format means
creating a specific file handler for that format. The decoder on the
other hand is generic and sees the resulting file as interleaved binary
and audio data. This means other instrument formats can be added in a
backwards compatible manner. This also means that FlacPak isn't limited
to just instrument patch formats, pretty much any binary/audio combined
data format might benefit from FlacPak (provided the audio is
mono/stereo 8/16/24 bit).

The current reference FlacPak implementation is part of the libInstPatch
library that is in active development. A CVS tarball of libInstPatch was
made to help in getting feedback from users on the current design of
FlacPak so that the format can be finalized.
To read more about FlacPak:
http://swami.sourceforge.net/flacpak.php

To get right to the download (libinstpatch-cvs_20031201.tar.bz2):
http://sourceforge.net/project/showfiles.php?group_id=47510

I welcome any feedback on this format and the results obtained. The
Swami development list can be found here:
http://sourceforge.net/mail/?group_id=47510

I still haven't tested it a whole lot so don't trust your data with it
yet. There is also a lot more tuning that can be done to get the
compression higher :) Cheers.
	Josh Green

Re: [Linuxsampler-devel] giga velocity setting algorithm

[<ken...@ya...>]

Mark,

i mean using Linux tools. i am using Lilypond to
produce piano music sheet. pmidi to play midi files
which are generated from Lilypind throught timidity++
(now LinuxSampler). The midi files produced by
Lilypond is good enought to proof-hearing but not
adequate for listening. Therefore, some touchup is
required for each file. What i am trying to do is to
write a simple pre-lilypond processor which could be
used to produce lilypond file for generating piano
music sheet. Also, the processor should be able to
produce midi file with specific attributes per note.
Based on the above mentioned, i am tring to play
around with the duration and velocity of the midi
file. At this stage, it seems to me that the result of
different velocity setting is not obvious to me,
therefore, i am asking for advice.

Highly likely that there are some Linux tools already
available for the above mentioned, please kindly let
me know.


Many thanks!

kenneth


 --- Mark Knecht <mar...@co...> wrote: > On
Sun, 2003-11-30 at 18:45, Kenneth Lee wrote:
> > hi,
> > 
> > i am not sure whether here is the right place to
> ask
> > but your help would be deeply appreciated.
> > 
> > if i try to set the velocity per midi note
> manually,
> > the output is not obvious to me. is there any
> > reference about the giga velocity setting
> algorithm?
> > so that i can use sensibly velocity setting.
> > 
> > Many thanks and best regards,
> > kenneth lee
> > 
> 
> Kenneth,
>    Are you talking about setting the velocity
> mapping in GigaSampler? Or
> in some Linux tool?
> 
>    I just did some mapping work on GSt.
> 
> Mark
>  

_______________________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com.hk address at http://mail.english.yahoo.com.hk

Re: [Linuxsampler-devel] giga velocity setting algorithm

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

On Sun, 2003-11-30 at 18:45, Kenneth Lee wrote:
> hi,
> 
> i am not sure whether here is the right place to ask
> but your help would be deeply appreciated.
> 
> if i try to set the velocity per midi note manually,
> the output is not obvious to me. is there any
> reference about the giga velocity setting algorithm?
> so that i can use sensibly velocity setting.
> 
> Many thanks and best regards,
> kenneth lee
> 

Kenneth,
   Are you talking about setting the velocity mapping in GigaSampler? Or
in some Linux tool?

   I just did some mapping work on GSt.

Mark

[Linuxsampler-devel] giga velocity setting algorithm

[<ken...@ya...>]

hi,

i am not sure whether here is the right place to ask
but your help would be deeply appreciated.

if i try to set the velocity per midi note manually,
the output is not obvious to me. is there any
reference about the giga velocity setting algorithm?
so that i can use sensibly velocity setting.

Many thanks and best regards,
kenneth lee




_______________________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com.hk address at http://mail.english.yahoo.com.hk

Re: [Linuxsampler-devel] LS bug report - no region defined for MIDI key

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

On Sun, 2003-11-30 at 16:45, Mark Knecht wrote:

> Can someone tell me how to
> direct LS audio to the Alsa outputs I want to use?
> 

BTW - All I mean with this request is:

1) What code can I change to use playback_9/10 instead of playback1/2

or

2) If possible, some specific .asoundrc settings that would route
plughw:0,0 to playback_9/10

I hope that makes sense.

Cheers,
Mark

[Linuxsampler-devel] LS bug report - no region defined for MIDI key

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

Hi,
   I had some time this afternoon to set up my GSt machine's dual boot a
bit better and now have it running an up to date PlanetCCRMA setup. My
thought is that this will eventually be of value as a direct comparison
between GSt and LS when the time comes to do that.

   Unfortunately, the default set up of this machine uses the second
ADAT output on the Hammerfall Light, not the first. This seems to mean
that with the way I have the cables set up right now I cannot actually
listen to the audio coming from LS right now. Can someone tell me how to
direct LS audio to the Alsa outputs I want to use?

   Along the way I started loading different gig files and just looking
at what happened. I came across the following (apparent) bug, having
something to do with 'No region defined for MIDI key'. This happens
once, then a second time, and then LS dies. It was repeatable.

   The Gig is one I bought from Wizoo some time ago. It works fine (or
did) in GSt. I loaded the Bardstown Piano to make sure there was no
global problem. There doesn't seem to be.

- Mark


[root@localhost root]# linuxsampler --numfragments 2 --gig 
/mnt/samples/Gigs/Loops/096\ BPM-Lofi\ Junkiez1.gig
Initializing audio output...Warning: your soundcard doesn't support
chosen hardware parameters; trying to compensate support lack with
plughw...OK
Loading gig file...OK
Caching initial samples...OK
Starting disk thread...OK
Starting MIDI in thread...OK
Starting audio thread...OK
LinuxSampler initialization completed.
Audio Thread: No Region defined for MIDI key 85Unused: 100)
Audio Thread: No Region defined for MIDI key 85
Segmentation fault000) Streams: 000 (Max: 000, Unused: 100)
[root@localhost root]# linuxsampler --numfragments 2 --gig 
/mnt/samples/Gigs/Loops/096\ BPM-Lofi\ Junkiez1.gig
Initializing audio output...Warning: your soundcard doesn't support
chosen hardware parameters; trying to compensate support lack with
plughw...OK
Loading gig file...OK
Caching initial samples...OK
Starting disk thread...OK
Starting MIDI in thread...OK
Starting audio thread...OK
LinuxSampler initialization completed.
Audio Thread: No Region defined for MIDI key 60Unused: 100)
Audio Thread: No Region defined for MIDI key 60
Segmentation fault000) Streams: 000 (Max: 000, Unused: 100)
[root@localhost root]# linuxsampler --numfragments 2 --gig 
/mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\
Grand\ 
Version\ 2.2.gig
Initializing audio output...Warning: your soundcard doesn't support
chosen 
hardware parameters; trying to compensate support lack with plughw...OK
Loading gig file...OK
Caching initial samples...OK
Starting disk thread...OK
Starting MIDI in thread...OK
Starting audio thread...OK
LinuxSampler initialization completed.
No free voice!ax: 062) Streams: 064 (Max: 064, Unused: 036)

Re: [Linuxsampler-devel] Work Great !

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

Es geschah am Freitag, 28. November 2003 11:35 als Mark Constable schrieb:
> On Fri, 28 Nov 2003 06:41 pm, Kenneth Lee wrote:
> > the 1g grand piano gig file work great!
> > for the time being, is it possible to load more than
> > one instrument?

Sorry, no channel support yet, although it needs only very few changes. But 
you know, there's still soooooooooo much to do and haven't even sighted the 
end of the todo list... ;)

> Apologies for not answerring your question but I'd like to
> extend the same question a bit by asking...
>
> . any such thing as a GM-equiv "patchset" for gigasamples ?

I think there are free GM gigs somewhere, but not sure. Maybe we should 
provide a couple of links to some free gigs on the LS website. Marek?

> . where is the canonical reference for the gigasampler format ?
>   (or, has it been solely reverse engineered ?)

It's a proprietary format, so you won't find an official 'reference'. So the 
answer to your last question is 'yes'. I started to write a documentation for 
the Gigasampler format, but it's only a basis so far:

	http://stud.fh-heilbronn.de/~cschoene/projects/libgig/

> . would it be possible/feasible to convert the, say, gigasample
>   FreePiano.gig to sf2/DLS2 format ?

Of course, that's no problem to make a DLS2 file out of it. DLS2 will probably 
be the next format I will add to LinuxSampler right after Gig support is 
completely finished. Regarding SF, I'm in no way interested in that primitive 
format. IMHO the time for SFs is almost over.

> . any ETA on when LinuxSampler will handle sf2 ?

As said, I will not waste my time with that and I think Benno has the same 
opinion. So there won't be SF support until somebody else has the will to 
implement it.

Best regards
Christian

Re: [Linuxsampler-devel] Work Great !

[Mark C. <ma...@re...>]

On Fri, 28 Nov 2003 06:41 pm, Kenneth Lee wrote:
> the 1g grand piano gig file work great!
> for the time being, is it possible to load more than
> one instrument?

Apologies for not answerring your question but I'd like to
extend the same question a bit by asking...

. any such thing as a GM-equiv "patchset" for gigasamples ?

. where is the canonical reference for the gigasampler format ?
  (or, has it been solely reverse engineered ?)

. would it be possible/feasible to convert the, say, gigasample
  FreePiano.gig to sf2/DLS2 format ?

. any ETA on when LinuxSampler will handle sf2 ?

Thanks.

--markc

[Linuxsampler-devel] Work Great !

[<ken...@ya...>]

hi,

the 1g grand piano gig file work great!

for the time being, is it possible to load more than
one instrument?

Many thanks

regards,
kenneth lee

_______________________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com.hk address at http://mail.english.yahoo.com.hk

Re: [Linuxsampler-devel] giga format

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

Es geschah am Donnerstag, 27. November 2003 09:35 als Kenneth Lee schrieb:
> Hi,
>
> I am interested to trying out the LinuxSampler with
> the giga format. Could you please kindly point me to
> the starting point.

You need to have a CVS client installed to download the current source code.
If you've installed it, run the following command on the console:

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

This will download the LS source code into the current directory. Compile
right after:

	cd linuxsampler
	./configure && make

You can then run linuxsampler and load a gig file by:

	src/linuxsampler --gig your.gig

Does your question mean the 'download' page on the LinuxSampler website is
not self-explanatory enough or have you just not read it? Please be honest!
:)

Best regards
Chrisian

[Linuxsampler-devel] giga format

[<ken...@ya...>]

Hi,

I am interested to trying out the LinuxSampler with
the giga format. Could you please kindly point me to
the starting point.

Many thanks.
Kenneth Lee


_______________________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com.hk address at http://mail.english.yahoo.com.hk

Re: [Linuxsampler-devel] Very Impressive

[Frank N. <bea...@we...>]

Hi list,
Mark Constable <ma...@re...> wrote:

> Just want to say that I tried CVS from about 48 hours ago,
> and also downloaded the the FreePiano.gig soundfont(?), and
> my running instance has been going ever since without any
> crashes. There's something not quite right about the attack
> of the notes but maybe I'm not used to hearing such basically
> good piano sounds (except for being stuck on the same volume).
> 
> I'd like to thank all the people involved, excellent work :)

I'd like to chime in on that here. I was not able to build current CVS versions for 
a while because I needed to update my Debian's automake, but now I could
just build it again, tried it, and it has worked very flawlessly so far. Oh, and yes -
that FreePiano is really nice! On a 1 GHz Athlon with both arms pressing as 
many keys as I could (around 38 voices),
I never managed to go beyond 9 % CPU consumption (according to gkrellm). 
Cool! :-) Putting some string sound from a synth below the piano already gives 
a very nice orchestra-like touch.

However, did anyone besides me notice that in that FreePiano gig file the C2
and C3 samples are having some "cracks" in them? That disturbed me
immediately when I began to play. I tried to locate the exact position in Sweep, 
but couldn't yet find it.. Maybe another sound editor gives better ways to
approximate and correct those bad spots. At first I thought that's bad pitch-shifting/
dithering code, but it appears in the original sample as well, when played at the
original pitch.

Now if the release part of the envelope would be a little softer.. :-)

Good work!
Frank

[Linuxsampler-devel] Making LinuxSampler generic (was: velocity)

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

On Tue, 2003-11-25 at 18:36, Marek Peteraj wrote:

<cut>

> So what i'm suggesting in general is - if .gig offers a certain model or
> system, can we extend upon that? how far can we go? is the model
> limited? is an unlimited model possible?
> If yes, let's implement that instead of the limited gig one, becasue the
> unlimited one will provide the same functionality. 
> 

The GigaSampler format seems like its very specific in its parameters
and the ranges of those parameters aren't really that much compared to
other formats. SoundFont uses 16 bit integers to describe all parameters
and DLS uses 32 bit. Don't get me wrong, GigaSampler does seem to offer
some nice features but I also agree that basing a synth just on that
format is probably short sited and its also a proprietary format. I
don't really see any problem with starting a synth with that format, but
it may be good to start adding some generic functionality from the
beginning.

GigaSampler does have some nice features like the dimension abstraction,
velocity cross fading and disk streaming. Disk streaming could be done
with DLS2 or SoundFont as well, nothing preventing that. The dimension
abstraction can be represented linearly by a list of regions that
trigger on certain criteria (velocity level, MIDI note, etc). The
velocity abstraction can also be implemented in SoundFont and DLS2 using
modulators/connection blocks respectively (although its not quite as
clean). Of note is that SoundFont/DLS2 can also have overlapping regions
(I haven't seen a way to do that in GigaSampler, but it wouldn't
surprise me if I'm wrong).

Providing a generic interface to GigaSampler for interfacing other
instrument formats would be really nice. FluidSynth has something like
this in place right now, although the parameters are SoundFont oriented
(not really that big of a problem really). Perhaps using DLS2 parameters
would be even more powerful in describing different formats.

Borrowing from the FluidSynth voice creation API:

LinuxSampler provides a noteon callback which passes a LinuxSampler
"voice" instance, the MIDI channel, note number and velocity to the
handler (or alternatively store these as fields in the LinuxSampler
instance). The handler is then responsible for creating voices in the
manner it sees fit (most of the voice data could be "cached", for speed,
from a "program" change handler that gets called when the MIDI
bank/program changes).

The handler routine would do something like this (very sudo code):

int
noteon_handler (LinuxSampler *ls)
{
  foreach custom_voice
  {
    voice = ls.new_voice (<voice template ID>);
    voice.set_param (DST_LFO_FREQ, custom_voice_val);
    voice.set_param (DST_FILTER_CUTOFF, custom_voice_val);
    voice.set_modulator (CONN_SRC_PITCHWHEEL, CONN_SRC_NONE,
                         CONN_DST_FILTER_CUTOFF, CONN_TRN_CONCAVE,
			 2400);
    voice.set_sample_read_func (custom_sample_stream_callback);
  }

  ls.commit ()
}

Anyways, much is missing from that, but I hope someone gets the idea. By
using DLS2 parameters to form the base set of synthesis modules and then
allowing additional modules to be added (perhaps have "voice templates"
that would allow one to define a default voice state which a voice gets
initialized to with new_voice(template_id). I'm sure there are probably
a lot of tricks that would need to be done in order to not allocate any
memory or lock anything, etc. A lot of this type of stuff could be done
when the MIDI program changes, since whatever custom format is being
synthesized might have some calculation overhead to convert to this
format. The addition of modulators (connection blocks in DLS terms)
would allow for modulating capabilities. I hope that meant something to
someone. Cheers.
	Josh Green

P.S. If you have read this far, perhaps you might be interested in a new
format I'm creating called FlacPak for losslessly compressing many
instrument formats (including GigaSampler). The web site for it is at:
http://swami.sourceforge.net/flacpak.php

Re: [Linuxsampler-devel] velocity (was: LinuxSampler BUGS to fix (Christian & others))

[Marek P. <ma...@na...>]

On Tue, 2003-11-25 at 03:43, Mark Knecht wrote:
> On Mon, 2003-11-24 at 19:17, Marek Peteraj wrote:
> > What i was talking about was - it has to sound like Gst if you want it
> > to sound like Gst. But it can sound like anything else, or custom. My
> > point was - flexibility.
> > 
> > What we're aiming at AFAIK is to provide 100% .gig support, not Gst
> > support. We just want to take full advantage of the .gig format,
> > anything beyond that could be considered as reverse-engineering Gst(or
> > any other app) which is forbidden.
> > 
> > what i was trying to propose was to make the velocity system as flexible
> > as possible from the start, so that it would handle virtually any kind
> > of situation, custom settings, or that it could be used in conjunction
> > with virtually any sampler velocity emulation, not just Gst. 
> 
> I have no problem with anything you wrote.
> 
> > 
> > > 
> > > If LS doesn't play gig files so that they sound substantially the same
> > > as GSt then $$$$$ of dollars of gig files are useless to people that use
> > > GSt today.
> > 
> > You forgot the akai users, the exs24 users, halion users, kontakt users,
> > nnxt(not sure about that name, the reason sampler), and roland users(old
> > hw samplers s-7xx). :)
> 
> No, I didn't really. I just fundamentally don't want things to get
> overly complicated supporting all this stuff before GSt support works
> very well. 100% audio compatibility with GSt, then do whatever else you
> want as we grab lots of new users.

You'd grab a lot more users with akai support. What i don't like is to
prefer one format over another and compromising designs in favor of one
format if a general solution can be found or at least worked out in a
reasonable way. 

I see linuxsampler as a project that aims to provide all features that
another sampler would provide and more, a project that is innovative and
unique, comfortable and userfriendly, efficient.

*That's* what's going to get us tons of users. A fully fledged sampler,
not a simple gig playback engine with a simple gui although 100%
comatible and faithfully playing any .gig.

I don't want LS end up being called as a Gst clone just because its name
is similar to Gst and that it provides 100% compatibility, even if only
for the beginning.

So what i'm suggesting in general is - if .gig offers a certain model or
system, can we extend upon that? how far can we go? is the model
limited? is an unlimited model possible?
If yes, let's implement that instead of the limited gig one, becasue the
unlimited one will provide the same functionality. 

Will it take longer to develop? Certainly. But in the end we'll all have
something better. And the development process could speed up
considerably later on if the current code allows to easily implement
other models/systems just because it was designed to be as flexible as
possible, not just limited to one format. 

Marek

Re: [Linuxsampler-devel] velocity (was: LinuxSampler BUGS to fix (Christian & others))

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

On Mon, 2003-11-24 at 19:17, Marek Peteraj wrote:
> What i was talking about was - it has to sound like Gst if you want it
> to sound like Gst. But it can sound like anything else, or custom. My
> point was - flexibility.
> 
> What we're aiming at AFAIK is to provide 100% .gig support, not Gst
> support. We just want to take full advantage of the .gig format,
> anything beyond that could be considered as reverse-engineering Gst(or
> any other app) which is forbidden.
> 
> what i was trying to propose was to make the velocity system as flexible
> as possible from the start, so that it would handle virtually any kind
> of situation, custom settings, or that it could be used in conjunction
> with virtually any sampler velocity emulation, not just Gst. 

I have no problem with anything you wrote.

> 
> > 
> > If LS doesn't play gig files so that they sound substantially the same
> > as GSt then $$$$$ of dollars of gig files are useless to people that use
> > GSt today.
> 
> You forgot the akai users, the exs24 users, halion users, kontakt users,
> nnxt(not sure about that name, the reason sampler), and roland users(old
> hw samplers s-7xx). :)

No, I didn't really. I just fundamentally don't want things to get
overly complicated supporting all this stuff before GSt support works
very well. 100% audio compatibility with GSt, then do whatever else you
want as we grab lots of new users.

- Mark

Re: [Linuxsampler-devel] velocity (was: LinuxSampler BUGS to fix (Christian & others))

[Marek P. <ma...@na...>]

On Mon, 2003-11-24 at 15:42, Mark Knecht wrote:
> On Mon, 2003-11-24 at 07:01, Marek Peteraj wrote:
> > On Mon, 2003-11-24 at 04:53, Mark Knecht wrote:
> > > On Sun, 2003-11-23 at 19:46, Marek Peteraj wrote:
> > > > > Ok, the latter might be a bug, I will check that. Regarding the 
> > > > > velocity<->volume mapping this is not yet implemented, but I will add that 
> > > > > next.
> > > > 
> > > > I wondered what would be the best way to implement it... how do other
> > > > samplers handle this issue?
> > > 
> > > This, I think, is pretty key. If people are using a library under GSt,
> > > and bring that library to LS, then they have a right to expect that it
> > > will sound substantially the same, and I think that if it doesn't, they
> > > won't continue to use LS.
> > 
> > Ok but the goal of linuxsampler isn't to clone gigasampler, it's just to
> > provide full gig support. :)
> > If the proposal i mentioned is ok and goes beyond Gst, that's only a
> > good thing(tm).
> > 
> > Marek
> 
> Right, not a clone. It doesn't have to look anything like GSt. It does
> have to *Sound* like GSt.

What i was talking about was - it has to sound like Gst if you want it
to sound like Gst. But it can sound like anything else, or custom. My
point was - flexibility.

What we're aiming at AFAIK is to provide 100% .gig support, not Gst
support. We just want to take full advantage of the .gig format,
anything beyond that could be considered as reverse-engineering Gst(or
any other app) which is forbidden.

what i was trying to propose was to make the velocity system as flexible
as possible from the start, so that it would handle virtually any kind
of situation, custom settings, or that it could be used in conjunction
with virtually any sampler velocity emulation, not just Gst. 

> 
> If LS doesn't play gig files so that they sound substantially the same
> as GSt then $$$$$ of dollars of gig files are useless to people that use
> GSt today.

You forgot the akai users, the exs24 users, halion users, kontakt users,
nnxt(not sure about that name, the reason sampler), and roland users(old
hw samplers s-7xx). :)

Marek

Re: [Linuxsampler-devel] velocity (was: LinuxSampler BUGS to fix (Christian & others))

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

On Mon, 2003-11-24 at 07:01, Marek Peteraj wrote:
> On Mon, 2003-11-24 at 04:53, Mark Knecht wrote:
> > On Sun, 2003-11-23 at 19:46, Marek Peteraj wrote:
> > > > Ok, the latter might be a bug, I will check that. Regarding the 
> > > > velocity<->volume mapping this is not yet implemented, but I will add that 
> > > > next.
> > > 
> > > I wondered what would be the best way to implement it... how do other
> > > samplers handle this issue?
> > 
> > This, I think, is pretty key. If people are using a library under GSt,
> > and bring that library to LS, then they have a right to expect that it
> > will sound substantially the same, and I think that if it doesn't, they
> > won't continue to use LS.
> 
> Ok but the goal of linuxsampler isn't to clone gigasampler, it's just to
> provide full gig support. :)
> If the proposal i mentioned is ok and goes beyond Gst, that's only a
> good thing(tm).
> 
> Marek

Right, not a clone. It doesn't have to look anything like GSt. It does
have to *Sound* like GSt.

If LS doesn't play gig files so that they sound substantially the same
as GSt then $$$$$ of dollars of gig files are useless to people that use
GSt today. People write music based on what it sounds like. If they are
using GSt and try this tool, they expect it to do everything GSt does in
the audio realm. They are naturally going to compare how the Garritan
library sounds, or how their favorite piano sounds, etc. If they don't
sound the same I predict 98% of the potential users will just go away.

Don't underestimate the importance of this. Not only are we asking GSt
users to get a completely new computer to run this program, but we are
asking them to load it with an operating system 99% of them have never
used, and then run this program and listen to the results. The results
had better be *really* good or it will be quite a disappointment.

- my 4 cents...

Mark

Re: [Linuxsampler-devel] velocity (was: LinuxSampler BUGS to fix (Christian & others))

[Marek P. <ma...@na...>]

On Mon, 2003-11-24 at 04:53, Mark Knecht wrote:
> On Sun, 2003-11-23 at 19:46, Marek Peteraj wrote:
> > > Ok, the latter might be a bug, I will check that. Regarding the 
> > > velocity<->volume mapping this is not yet implemented, but I will add that 
> > > next.
> > 
> > I wondered what would be the best way to implement it... how do other
> > samplers handle this issue?
> 
> This, I think, is pretty key. If people are using a library under GSt,
> and bring that library to LS, then they have a right to expect that it
> will sound substantially the same, and I think that if it doesn't, they
> won't continue to use LS.

Ok but the goal of linuxsampler isn't to clone gigasampler, it's just to
provide full gig support. :)
If the proposal i mentioned is ok and goes beyond Gst, that's only a
good thing(tm).

Marek

Re: [Linuxsampler-devel] velocity (was: LinuxSampler BUGS to fix (Christian & others))

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

On Sun, 2003-11-23 at 19:46, Marek Peteraj wrote:
> > Ok, the latter might be a bug, I will check that. Regarding the 
> > velocity<->volume mapping this is not yet implemented, but I will add that 
> > next.
> 
> I wondered what would be the best way to implement it... how do other
> samplers handle this issue?

This, I think, is pretty key. If people are using a library under GSt,
and bring that library to LS, then they have a right to expect that it
will sound substantially the same, and I think that if it doesn't, they
won't continue to use LS.

- Mark

[Linuxsampler-devel] Very Impressive

[Mark C. <ma...@re...>]

Just want to say that I tried CVS from about 48 hours ago,
and also downloaded the the FreePiano.gig soundfont(?), and
my running instance has been going ever since without any
crashes. There's something not quite right about the attack
of the notes but maybe I'm not used to hearing such basically
good piano sounds (except for being stuck on the same volume).

I'd like to thank all the people involved, excellent work :)

And FWIW I made this page http://alsa.opensrc.org/?LinuxSampler

--markc

Re: [Linuxsampler-devel] velocity (was: LinuxSampler BUGS to fix (Christian & others))

[Marek P. <ma...@na...>]

> Ok, the latter might be a bug, I will check that. Regarding the 
> velocity<->volume mapping this is not yet implemented, but I will add that 
> next.

I wondered what would be the best way to implement it... how do other
samplers handle this issue?

I believe that both volume mapping and crossfading should be implemented
at the same time since they seem to correpsond to each other, consider
following situations:

layer1 is pp layer2 is mf layer3 is ff

+--layer1--+--layer2--+--layer3--+
+>>volume>>|>>volume>>|>>volume>>+

only volume is used.

+--layer1--+--layer2--+--layer3--+
+>>>>x-fade>>>>>|>>>>>x-fade>>>>>+

only x-fading is used, no volume changes

+--layer1---+---layer2---+--layer3--+
+>vol>|>x-fade>|>vol>|>x-fade>|>vol>|

both are used

So it seems that it would be very useful to have the possibility to
adjust the ranges of volumes/x-fades with respect to each other or to
turn off volumes or xfades. I think that they depend on each other. 

Marek