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

Re: [Linuxsampler-devel] Yay a sampler

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

Es geschah am Mittwoch, 24. Dezember 2003 19:04 als Bonilla-Toledo, david 
(DPS_MOLR1.1) schrieb:
> Hi,
> I would like to contribute with some Icons, Graphics, Documentation,
> Translations to spanish, etc.
>
> I do know how to code but I haven't code in a very long time. ( C Ansi
> and C++ )
> Maybe santa will bring me a programming book this x-mas to refresh my
> memory.
[SNIP]
> So anyway,
> Is there a feature development list? We should have one to know what to
> code for ( and later test for )

Hi David!

We have tasks for everybody, even if you're not an experienced coder. For 
example our web page is a bit out of date. It's missing things like our 
development roadmap, list for already implemented and planned features and 
documentation for compilation and usage of LinuxSampler. Also nice would be 
some free gig files or links to some, so users can test LS righ away and some 
demo tracks. Other ideas always appreciated! Marek is mostly maintaining our 
webpage, contact him for work on it.

> Is there anyone doing the design on the GUI ( specifically on how it
> should look )?
> Is there anyone coding it already?

Rui has started work on the GUI. Contact him for the GUI design and artwork.

> What's the current functionality of the code in the CVS?

The only patch format we support at the moment is the Gigasampler format. But 
this will change soon. These are the current features of LS:

	- disk streaming as well as RAM only playback of course
	- low latency operation (<5ms)
	- velocity layer support
	- arbitrary number of simultaneous voices and disk streams (we do have two
	  #defines for the voice and stream limit for efficiency reasons, but these
	  values can be raised on compile time to arbitrary values, so the actual
	  limit of max. simultaneous voices and streams is only constrained by the
	  system / hardware)
	- sustain pedal support
	- velocity -> volume mapping
	- linear and cubic interpolation (resampling)

Audio output only Alsa at the moment, same accounts to the MIDI connection of 
LS. Correct me if I forgot something. I'm sure we find a task you like.

You can also talk to us on irc.freenode.org (#linuxsampler and #lad).

CU
Christian

Re: [Linuxsampler-devel] alsa and jack

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

Es geschah am Mittwoch, 24. Dezember 2003 14:10 als Antonio Willy Malara 
schrieb:
> seems really hackish... if the task is to convert sample format why
> dont do with alsa plug: layer?? i'm using it for getting endianness
> right and it works really good

We're already using plughw, that's not the problem. He just wanted a way to 
record the audio output and as we're currently only supporting Alsa, this 
hack is (beside recording the sound card's output signal of course) the only 
solution to achieve that at the moment.

CU
Christian

[Linuxsampler-devel] Yay a sampler

[Bonilla-Toledo, d. (DPS_MOLR1.1) <bon...@hp...>]

Hi,
I would like to contribute with some Icons, Graphics, Documentation,
Translations to spanish, etc.

I do know how to code but I haven't code in a very long time. ( C Ansi
and C++ )
Maybe santa will bring me a programming book this x-mas to refresh my
memory.

I'm a Software Test Engineer / Electronic music producer.
I'm of course very experienced with hardware samplers, studio and mixing
issues, etc. Cause I deal with them on a daily basis with my studio.

So anyway,
Is there a feature development list? We should have one to know what to
code for ( and later test for )
Is there anyone doing the design on the GUI ( specifically on how it
should look )?
Is there anyone coding it already?
What's the current functionality of the code in the CVS?

Thanks.
I'll be reading the archives in the meantime.

-David-

Re: [Linuxsampler-devel] alsa and jack

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

Many thanks,

Unfortunately i have a hardware problem that i could
not try it out right now. i'll let you know once i get
it done.

Wish you a Merry Christmas and a very happy New Year!


kenneth lee

 --- Christian Schoenebeck
<chr...@ep...> wrote: > Es geschah
am Montag, 22. Dezember 2003 14:59 als
> Kenneth Lee schrieb:
> > Many thanks for great works that has been done!
> > Even only Alsa for the time being is readlly
> wonderful
> > already.
> 
> You're welcome
> 
> >
> > LinuxSampler to become a Jack client would be a
> big
> > project. For short term solution, do you have any
> > suggestion to record audio output from
> LinuxSampler
> > into audio format for the time being?
> 
> There is one dirty hack you could do to approach
> this: edit
> src/audiothread.cpp and drop this in line 87:
> 
> 	int fRawOut = open("/tmp/lsaudio.raw", O_WRONLY);
> 
> so it looks like this:
> 
> ...
> int AudioThread::Main() {
>     dmsg(2,("Audio thread running\n"));
>     int fRawOut = open("/tmp/lsaudio.raw",
> O_WRONLY);
> ...
> 
> and in insert between line 146 and 147 this:
> 
> 
>
write(fRawOut,pAudioIO->pOutputBuffer,pAudioIO->FragmentSize
> * pAudioIO->Channels * sizeof(short));
> 
> so it looks like:
> 
> ...
>         // call audio driver to output sound
>         int res = this->pAudioIO->Output();
>         if (res < 0) exit(EXIT_FAILURE);
>        
>
write(fRawOut,pAudioIO->pOutputBuffer,pAudioIO->FragmentSize
> * pAudioIO->Channels * sizeof(short));
>     }
> ...
> 
> That way LinuxSampler constantly writes the audio
> output to the file
> /tmp/lsaudio.raw (you can adjust path and file name
> of course) while it's
> running and you can load that raw audio file later
> with the sample editor of
> your choice and convert it to a sample format you
> like.
> 
> CU
> Christian
>  

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

Re: [Linuxsampler-devel] alsa and jack

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

Es geschah am Montag, 22. Dezember 2003 14:59 als Kenneth Lee schrieb:
> Many thanks for great works that has been done!
> Even only Alsa for the time being is readlly wonderful
> already.

You're welcome

>
> LinuxSampler to become a Jack client would be a big
> project. For short term solution, do you have any
> suggestion to record audio output from LinuxSampler
> into audio format for the time being?

There is one dirty hack you could do to approach this: edit
src/audiothread.cpp and drop this in line 87:

	int fRawOut = open("/tmp/lsaudio.raw", O_WRONLY);

so it looks like this:

...
int AudioThread::Main() {
    dmsg(2,("Audio thread running\n"));
    int fRawOut = open("/tmp/lsaudio.raw", O_WRONLY);
...

and in insert between line 146 and 147 this:

	write(fRawOut,pAudioIO->pOutputBuffer,pAudioIO->FragmentSize * pAudioIO->Channels * sizeof(short));

so it looks like:

...
        // call audio driver to output sound
        int res = this->pAudioIO->Output();
        if (res < 0) exit(EXIT_FAILURE);
        write(fRawOut,pAudioIO->pOutputBuffer,pAudioIO->FragmentSize * pAudioIO->Channels * sizeof(short));
    }
...

That way LinuxSampler constantly writes the audio output to the file
/tmp/lsaudio.raw (you can adjust path and file name of course) while it's
running and you can load that raw audio file later with the sample editor of
your choice and convert it to a sample format you like.

CU
Christian

Re: [Linuxsampler-devel] Make trouble

[Rui N. C. <rn...@rn...>]

Christian Schoenebeck wrote:
>
> I also removed acconfig.h now from CVS, which really made sense, but I'm
> not sure about removing aclocal.m4, config.h.in and config.sub. If I do
> that it's not possible anymore to make a simple:
>
> 	./configure && make
>
> Although it seems that you Rui have to autoreconf anyway, but most others
> don't have to, so I think it's better to keep them at the moment.
>

Yes, in my case and possible others, the very minimal steps to build
linuxsampler from CVS are just the follwing (from the top of source tree):

    rm -rf autom4te.cache
    autoreconf -f
    ./configure && make

The other files that I suggested removal are due to their overall
obsolescence. If you have to autoreconf you don't need them at all, 'coz
they are regenerated each time you issue the primordial autocrapola
sequence:

    aclocal && autoheader && automake && autoconf

which is what 'make -f Makefile.cvs' exactly does.

>
> Send your patch and we can elaborate a solution that fits everybody. But
> again, I don't think it's good to just remove that files. Best solution
> would be to remove that files by script only if ./configure fails.
>

It wasn't ./configure that was failing but make. See my Makefile.cvs patch
on attachment.

Bye and a merry merry xmas.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Gig format

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

On Mon, 2003-12-22 at 01:22, Mark Constable wrote:
> On Mon, 22 Dec 2003 06:08 pm, Josh Green wrote:
> > ...
> > Personally, I think DLS is probably the best current format to support.
> > Unfortunately the documentation for DLS2 isn't as open as SoundFont
> > (still requires you to pay for it), but I believe the standard is
> > "open".
> 
> . IYO do you think it is feasible at this point in time to develop a 
>   high-end open instrument format ?
> 

Feasible, sure why not. I think for now I'm going to stick with
DLS/SoundFont though, since they are open standards and DLS was adopted
as part of MPEG4 and is supported by M$ Media player (although I don't
know to what extent it is). The format is rather flexible in many
regards, actually GigaSampler is based on it, if you didn't already
know.

> . if paying for the DLS2 spec is a problem I'd be happy to do so if
>   I am confident whoever gets the spec will translate it into C code.
> 

I have a copy of the spec myself (and have already written code for it,
so has the LinuxSampler project for that matter), its around $30 US
dollars or something. Its from the MIDI Manufacturer's Association
(http://www.midi.org). The version 1 DLS spec can be downloaded for
free, but version 2 is unfortunately purchase only, which seems really
stupid to me.

> > I'm also starting to like the idea of instrument data being 
> > stored in an XML file and each sample in its own individual file
> > (something that has been mentioned on this list before).
> 
> Yes please. Individual binary files and meta info as plain text XML
> all in a directory would be very *nix friendly.
> 

It would be kind of cool :)

> --markc
> 

Cheers.
	Josh

[Linuxsampler-devel] For your listening pleasure...

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

Hi,
   I thought it would be sort of fun to keep track of the headway we're
making with LS, so I found a nice jazzy MIDI track we'd used some time
ago in the Northern Sounds forum to compare some pianos in GSt. I've set
up a web server (well, more my excuse for a web server!) and stored the
first two files there for your listening pleasure. ;-)

   If interested, please direct your browsers to:

http://marksmusic.myvnc.com/files/GSt_Bounce-2003-12-21.ogg

http://marksmusic.myvnc.com/files/LS_Bounce-2003-12-21.ogg

   I like this little MIDI track as it has a nice mixture of chordal
playing as well as melody, some staccato, etc. so I think it is pretty
good at showing problems. (Of which we have a few right now.) ;-)

   This is the Bardstown Bosendorfer with just a touch of an unreleased
impulse response reverb added to it, recorded at 44.1K/24-bit in Pro
Tools, bounced as wave and then converted to ogg with oggenc with no
command line options. Each file is a bit less than 3MB. There is no
compression or anything else. There may be a click or pop due to a pesky
clocking issue I'm dealing with recently. Please forgive.

   Anyway, LS is making GREAT headway I think. Have a listen today, and
then more over the future as we improve LS and quickly move toward world
domination.

Cheers,
Mark

P.S. - I apologize for my terrible web server skills. I am so pitiful
that I cannot even get the files directory to just show on my web page
or anything, so I'll need some help one of these days making it better.

Re: [Linuxsampler-devel] LS Testing - low volumes

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

On Mon, 2003-12-22 at 04:22, Christian Schoenebeck wrote:
> Es geschah am Sonntag, 21. Dezember 2003 23:04 als Mark Knecht schrieb:
> >    I hadn't tested LS seriously since MIDI velocity support was added,
> > so I'm starting with that. The good news is that it works. The semi-bad
> > news is that overall volumes are much, much lower. A peak of -6db in GSt
> > will come out about -18db in LS.
> 
> I guess you're speaking about the overall volume of LS, right? If yes, I will 
> add a command line switch for the global volume in LS with my next commit. 
> You're absolutely right, that the volume is a bit low on many machines, we 
> just set it that low, to avoid distortions with some sound cards. With the 
> command line option you will be able to raise the overall level and when Rui 
> finished our initial GUI you will be able to set such things by just doing 
> some clicks.
> 
> CU
> Christian
> 

Christian,
   I think it makes lots of sense right now to keep the volume low. I
you had been planning on adding a command line switch for volume, that's
fine, but I'm not asking for it. Things are fine the way they are. I was
just reporting data, not asking for changes.

   By way of comparison, I spent a lot of time Sunday afternoon playing
with levels in GSt and dealing with some distortions there. I ended up
finding that the level differences between LS and GSt weren't that
different if I wanted GSt to not distort on high polyphony counts, so
maybe things aren't that far off of a good setting right now.

   Far more preferred would be the MIDI hookup command line switch.
That's still a pain as I change gig files... ;-)

Cheers,
Mark

Re: [Linuxsampler-devel] alsa and jack

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

Es geschah am Montag, 22. Dezember 2003 08:38 als Kenneth Lee schrieb:
> Hi Mark,
>
> i think i came across a message from you to the
> LinuxSampler list about alsa and jack.  The message
> mentioned that you started LS and then jack and i
> would assume that LS output could route to another
> jack client as input.  Am i get it right? if it is the
> case, could you give me a pointer? i could not do
> this, i.e. started LS and then jackstart which gave a
> device busy error message.

LinuxSampler only supports Alsa at the moment, sorry! Jack support will follow 
next year or if here's somebody on the list that has the time for it, perhaps 
even earlier.

Anbody?

CU
Christian

Re: [Linuxsampler-devel] Make trouble

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

Es geschah am Sonntag, 21. Dezember 2003 13:34 als Rui Nuno Capela schrieb:
> Mark Constable wrote:
> > Yo Rui, would you mind if I put this on the Wiki at alsa.opensrc.org ?
>
> Be my guest.
>
> However I've refined the previous script a little bit, and now it takes
> the following form:
>
> ---BOF: linuxsampler_cvs_install.sh ---
> #!/bin/sh
> cvs -z3
> -d:pserver:ano...@cv...:/home/schropp/linuxsampler co
> linuxsampler
> cd linuxsampler || exit 1
> find -name "acconfig.h" -exec rm -rvf \{} \;
> find -name "aclocal.m4" -exec rm -rvf \{} \;
> find -name "config.*"   -exec rm -rvf \{} \;
> find -name "*.cache"    -exec rm -rvf \{} \;
> make -f Makefile.cvs
> ./configure --prefix=/usr/local --enable-optimize
> make || exit 2
> su -c "make install"
> ---EOF: linuxsampler_cvs_install.sh ---

I also removed acconfig.h now from CVS, which really made sense, but I'm not 
sure about removing aclocal.m4, config.h.in and config.sub. If I do that it's 
not possible anymore to make a simple:

	./configure && make

Although it seems that you Rui have to autoreconf anyway, but most others 
don't have to, so I think it's better to keep them at the moment.

> As of yesterday on IRC, Chris agreed to remove the "offending" files from
> CVS, so I think the explicit removal above will be soon a non-op. OTOH it
> could be moved apropriately into Makefile.cvs.

Send your patch and we can elaborate a solution that fits everybody. But 
again, I don't think it's good to just remove that files. Best solution would 
be to remove that files by script only if ./configure fails.

CU
Christian

Re: [Linuxsampler-devel] alsa and jack

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

On Sun, 2003-12-21 at 23:38, Kenneth Lee wrote:
> Hi Mark,
> 
> i think i came across a message from you to the
> LinuxSampler list about alsa and jack.  The message
> mentioned that you started LS and then jack and i
> would assume that LS output could route to another
> jack client as input.  Am i get it right? if it is the
> case, could you give me a pointer? i could not do
> this, i.e. started LS and then jackstart which gave a
> device busy error message.
> 
> many thanks!
> kenneth lee
> 

Kenneth,
   If I said that then I misspoke. I don't think this is possible with a
single sound card...

Mark

Re: [Linuxsampler-devel] Gig format

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

On Sun, 2003-12-21 at 22:49, Mark Constable wrote:
> >    It would be fine, and I think even planned, to create a new Linux
> > format to store files in, but I don't think I'll use it to any great
> > extent. I have LS and GSt on the same machine as dual boot. They share
> > about 15GB of gig files. I wouldn't see much value in loading and
> > storing all that data in two formats.
> 
> That depends... an open audio format would begat open gig-like
> samples and in this context it would make sense to use the newer
> open format. For me, your "15GB of gig files" would be totally
> useless if they were not openly sharable with other folks... it's
> not just a technological issue but cultural as well (for me anyway).
> 
> --markc

To those of us just making music the file format doesn't really matter.
I'm nat that political. The story today is that the best library
developers do their work and charge money for the results. If I want to
use their product, then $...$$...$$$.

It's just the way it is....

That said, I use all the free gig files I can find also.

- Mark

Re: [Linuxsampler-devel] LS Testing - low volumes

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

Es geschah am Sonntag, 21. Dezember 2003 23:04 als Mark Knecht schrieb:
>    I hadn't tested LS seriously since MIDI velocity support was added,
> so I'm starting with that. The good news is that it works. The semi-bad
> news is that overall volumes are much, much lower. A peak of -6db in GSt
> will come out about -18db in LS.

I guess you're speaking about the overall volume of LS, right? If yes, I will 
add a command line switch for the global volume in LS with my next commit. 
You're absolutely right, that the volume is a bit low on many machines, we 
just set it that low, to avoid distortions with some sound cards. With the 
command line option you will be able to raise the overall level and when Rui 
finished our initial GUI you will be able to set such things by just doing 
some clicks.

CU
Christian

Re: [Linuxsampler-devel] Gig format

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

Es geschah am Montag, 22. Dezember 2003 10:22 als Mark Constable schrieb:
> On Mon, 22 Dec 2003 06:08 pm, Josh Green wrote:
> > ...
> > Personally, I think DLS is probably the best current format to support.
> > Unfortunately the documentation for DLS2 isn't as open as SoundFont
> > (still requires you to pay for it), but I believe the standard is
> > "open".
>
> . IYO do you think it is feasible at this point in time to develop a
>   high-end open instrument format ?
>
> . if paying for the DLS2 spec is a problem I'd be happy to do so if
>   I am confident whoever gets the spec will translate it into C code.

As already said, we will start to design our own format when all the basic 
features in the engine are done, so maybe mid of january. I have already 
written DLS1 and 2 loader classes (see DLS.cpp, DLS.h), but at the moment 
these are only used for the gig format (gig is based on DLS as you might 
know). Writing a custom engine for DLS won't be much effort.

But at the moment I'm more tending for an XML based format for LinuxSampler's 
own patch format. Although DLS claims to be an "open" format, the specs are 
officially not, so that is IMO a big minus for DLS and I think that opinion 
reflects most of the ones here on the list, doesn't it?

CU
Christian

Re: [Linuxsampler-devel] Gig format

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

Es geschah am Montag, 22. Dezember 2003 01:20 als Levi Burton schrieb:
> Hello,

Hi Levi!

>
> I have not yet had a chance to try and use linuxsampler, but based on some
> of the mail trafic ive seen, i have a couple questions and comments.
>
> 1. Why use gig format?  Isn't the gig format proprietary?  Is reverse
> engineering a proprietary file format the best possible solution to
> represent sampler intstruments in a software synth that aims to be the
> be-all-end-all of linux software samplers?  I don't.

The Gigasampler format is only a starting point for us. We chose it to be the 
first format supported by LinuxSampler because there already a lot of 
interesting, high quality instrument libraries which IMO beat most libraries 
in other formats, at least from my perspective demanding high quality natural 
sounds (piano, guitar, strings,...). I hope I didn't start a new thread with 
this proposition. ;)

When we finished basic features in the sampler engine (which is hopefully done 
with the begin of january), supporting all articulation parameters the gig 
format offers, we will introduce other proprietary formats and definitely 
start to design our own format, which will be mandatory, because we will have 
to store informations that are not covered by any available patch format at 
the moment (e.g. think about the recompilation feature which is planned).

If we get legal issues with one of the proprietary formats then we'll simply 
drop that format. But IMHO I don't expect that to happen.

>
> From a developer and maintenance point of view, this seems like it would be
> an absolute nightmare.  How do you debug a commercial gig file?  How do you
> track changes to the gig format?
>
> What about developing gig file editors?  As I see it, the same problems
> arise here too.

Changes to the gig format occured very rarely in the past and new versions are 
usually backward compatible. But again: gig is only a starting point, when we 
have our own format there will be no need for an gig editor. If somebody 
wants to write one, fine, but we won't be dependant on that.

Simply converting other formats to one and only one format was already 
discussed here a couple of times, but we decided to create custom engines for 
each format. Using OO technics the effort for this is much lower than writing 
an converter and an engine that supports all features for all kind of patch 
formats out there. That would be for me a nightmare!

I hope that answered all your questions and took your fears! ;)

CU
Christian

Re: [Linuxsampler-devel] Gig format

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

On Mon, 22 Dec 2003 06:08 pm, Josh Green wrote:
> ...
> Personally, I think DLS is probably the best current format to support.
> Unfortunately the documentation for DLS2 isn't as open as SoundFont
> (still requires you to pay for it), but I believe the standard is
> "open".

. IYO do you think it is feasible at this point in time to develop a 
  high-end open instrument format ?

. if paying for the DLS2 spec is a problem I'd be happy to do so if
  I am confident whoever gets the spec will translate it into C code.

> I'm also starting to like the idea of instrument data being 
> stored in an XML file and each sample in its own individual file
> (something that has been mentioned on this list before).

Yes please. Individual binary files and meta info as plain text XML
all in a directory would be very *nix friendly.

--markc

Re: [Linuxsampler-devel] Gig format

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

On Sun, 2003-12-21 at 16:20, Levi Burton wrote:
> Hello,
> 
> I have not yet had a chance to try and use linuxsampler, but based on some of the mail trafic ive seen, i have a couple questions and comments.
> 
> 1. Why use gig format?  Isn't the gig format proprietary?  Is reverse engineering a proprietary file format the best possible solution to represent sampler intstruments in a software synth that aims to be the be-all-end-all of linux software samplers?  I don't.
> 
> >From a developer and maintenance point of view, this seems like it would be an absolute nightmare.  How do you debug a commercial gig file?  How do you track changes to the gig format?
> 
> What about developing gig file editors?  As I see it, the same problems arise here too.  
> 
> Which would be more beneficiary: a native linux sampler instrument format or the gig file format.
> 
> Another problem: What if legal issues arise preventing linuxsampler from even using the gig file format? 
> 
> My suggestion is this:  Design a native linuxsampler format, and build tools to convert gig files to it.  Put the tools for converting into a library, which could then be extended to support conversion of other formats.  The advantages would be a single point of maintenance for file format conversion, easing the burdern of developers supporting multiple file formats (they simply recompile their tools when the formats change and the conversion tools are updated).
> 
> 
> Levi
> 

You may be interested in a project I'm working on called libInstPatch
(part of the Swami project, http://swami.sourceforge.net), which aims to
do some of the things you described. It is just starting to become
generally useful, since its been in heavy development for a while now.
Currently SoundFont files are the best supported, and DLS/GigaSampler
loading has been added. The conversion interface is still code in
progress though. Its got a Python binding at the moment which is fairly
functional, although it needs more development as well. The biggest
complaint I have heard, is that its not coded in C++, but it uses
GObject, so like GTK+ it could have a C++ binding added to it.

Personally, I think DLS is probably the best current format to support.
Unfortunately the documentation for DLS2 isn't as open as SoundFont
(still requires you to pay for it), but I believe the standard is
"open". I'm also starting to like the idea of instrument data being
stored in an XML file and each sample in its own individual file
(something that has been mentioned on this list before). Cheers.
	Josh Green

[Linuxsampler-devel] alsa and jack

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

Hi Mark,

i think i came across a message from you to the
LinuxSampler list about alsa and jack.  The message
mentioned that you started LS and then jack and i
would assume that LS output could route to another
jack client as input.  Am i get it right? if it is the
case, could you give me a pointer? i could not do
this, i.e. started LS and then jackstart which gave a
device busy error message.

many thanks!
kenneth lee

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

Re: [Linuxsampler-devel] Gig format

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

On Mon, 22 Dec 2003 11:52 am, Mark Knecht wrote:
> > 1. Why use gig format?  Isn't the gig format proprietary?  Is reverse
> > engineering a proprietary file format the best possible solution to
> > represent sampler intstruments in a software synth that aims to be the
> > be-all-end-all of linux software samplers?  I don't.

If you could convince some capable linux/ALSA audio engineers to
spend the next couple of years working on an alternative then your
point would be totally valid.

>    Because, from my point of view, we need to be able to load
> GigaSampler files. Simple as that. We need high quality sounds from day
> one. Supporting gig files is a requirement to get GSt users to try out
> LS. After that, possibly Halion, Kontakt, etc...

Yes, hopefully. Then eventually the itch that needs scratching to
blend the best of breed from all formats into an advanced killer
open audio format will become more obvious.

>    It would be fine, and I think even planned, to create a new Linux
> format to store files in, but I don't think I'll use it to any great
> extent. I have LS and GSt on the same machine as dual boot. They share
> about 15GB of gig files. I wouldn't see much value in loading and
> storing all that data in two formats.

That depends... an open audio format would begat open gig-like
samples and in this context it would make sense to use the newer
open format. For me, your "15GB of gig files" would be totally
useless if they were not openly sharable with other folks... it's
not just a technological issue but cultural as well (for me anyway).

--markc

Re: [Linuxsampler-devel] LS Testing - low volumes

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

On Sun, 2003-12-21 at 14:04, Mark Knecht wrote:
> Hi,
>    It's been a while since I've done any serious testing of LS, and
> since I'm testing a whole bunch of unreleased Pro Tools plugins this
> weekend anyway (amazing what a person will do to get a years free use of
> $10,000 worth of plugins, isn't it?) ;-)  so I decided to combine the
> work and use LS in the flow.
> 
>    I hadn't tested LS seriously since MIDI velocity support was added,
> so I'm starting with that. The good news is that it works. The semi-bad
> news is that overall volumes are much, much lower. A peak of -6db in GSt
> will come out about -18db in LS.
> 
>    I'm sending a screen shot of the Pro Tools session with PAZ doing a
> frequency response curve to Christian and Benno directly. If anyone else
> needs a copy let me know. It's about 350K.
> 
> Cheers,
> Mark
> 

Hi,
   Part of this is the way my system was set up. Instead of being 12db
off it looks more like it's 6db off. I'm still looking for other things
I might be doing that could be causing this.

Cheers,
Mark

Re: [Linuxsampler-devel] Gig format

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

On Sun, 2003-12-21 at 16:20, Levi Burton wrote:
> Hello,
> 
> I have not yet had a chance to try and use linuxsampler, but based on some of the mail trafic ive seen, i have a couple questions and comments.
> 
> 1. Why use gig format?  Isn't the gig format proprietary?  Is reverse engineering a proprietary file format the best possible solution to represent sampler intstruments in a software synth that aims to be the be-all-end-all of linux software samplers?  I don't.
> 

Hi,
   Because, from my point of view, we need to be able to load
GigaSampler files. Simple as that. We need high quality sounds from day
one. Supporting gig files is a requirement to get GSt users to try out
LS. After that, possibly Halion, Kontakt, etc...

   It would be fine, and I think even planned, to create a new Linux
format to store files in, but I don't think I'll use it to any great
extent. I have LS and GSt on the same machine as dual boot. They share
about 15GB of gig files. I wouldn't see much value in loading and
storing all that data in two formats.

   There has been discussion here representing different thinking than
mine, which is cool too.

Cheers,
Mark

[Linuxsampler-devel] Gig format

[Levi B. <ld...@pu...>]

Hello,

I have not yet had a chance to try and use linuxsampler, but based on some of the mail trafic ive seen, i have a couple questions and comments.

1. Why use gig format?  Isn't the gig format proprietary?  Is reverse engineering a proprietary file format the best possible solution to represent sampler intstruments in a software synth that aims to be the be-all-end-all of linux software samplers?  I don't.

From a developer and maintenance point of view, this seems like it would be an absolute nightmare.  How do you debug a commercial gig file?  How do you track changes to the gig format?

What about developing gig file editors?  As I see it, the same problems arise here too.  

Which would be more beneficiary: a native linux sampler instrument format or the gig file format.

Another problem: What if legal issues arise preventing linuxsampler from even using the gig file format? 

My suggestion is this:  Design a native linuxsampler format, and build tools to convert gig files to it.  Put the tools for converting into a library, which could then be extended to support conversion of other formats.  The advantages would be a single point of maintenance for file format conversion, easing the burdern of developers supporting multiple file formats (they simply recompile their tools when the formats change and the conversion tools are updated).


Levi

--
Levi Burton
http://www.puresimplicity.net/~ldb

[Linuxsampler-devel] Instrument selection?

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

Hi,
   As part of the Scarbee problem described earlier, the file I was
loading has 14 'instruments' in single gig file. Does the LS gig import
understand this aspect of gig files?

   If it does understand this then which one does it load?

Thanks,
Mark

[Linuxsampler-devel] LS Gig problems - noise and tempo

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

Hi,
   I'm testing a number of Gigs today looking for issues in
Linux-Sampler. I've run across two so far. How shall we address these?

1) A commercial bass library that I have called Scarbee J-Fingered Bass
is not working correctly at all. It produces nothing but glitch/noise
sounds in LS. Since it's commercial I cannot give it to anyone. How
shall we handle debugging this? Can someone give me some instructions on
how to get data out of the file so that I can give you data to help
figure out what's going wrong?

http://www.scarbee.com/products/jf/index.php

2) I have a loop sample library called 'Lofi Junkiez1'. It's a
collection of loops at 96BPM. Each key should play at 96BPM, and it does
in GSt, but in LS the tempo is getting scaled wit the keyboard. It's
commercial also, but would not cost someone much to buy it if you wanted
to, but I'm happy to dig into the file if someone can tell me how to do
it.

http://www.primesounds.com/prime2/samples/series.jhtml?seriesId=85

Happy Holidays to everyone out there!

Cheers,
Mark