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

Re: [Linuxsampler-devel] AKAI samplelibrary loader is online

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

Josh Green wrote:

> 
> Okay, I just had a look at the code for libakai. The following are some
> of my thoughts and findings concerning the Akai formats, libakai and
> libInstPatch. I would like to invite Sebastien to correct me and perhaps
> clairify what the scope of libakai is. It would be really nice to
> collaborate on this stuff :)
> 

Sure. But as I already explained to Benno I will not be able to help on 
the linuxsampler because of legal reasons (i'm part of the Team that 
develops MachFive, MOTU's sampler, and my employer would be concerned 
about comflict of interests).

> It seems like libakai is currently based on the S1000 format. I just
> realized by looking at the document at:
> http://www.abel.co.uk/~maxim/akai/akaiinfo.htm which the libakai library
> appears to have used as a reference (from the look of the comments) that
> the S3000 sample format appears to be identical to the S1000 format (I
> don't believe the program data is the same though). That makes things a
> little easier when thinking of supporting multiple akai formats. The
> later formats appear to use WAVE files which should also ease things.
> 

Yep, i used this document as a basis for the informations but it only 
concerns the floppy version of the format and is incomplete concerning 
the CD format. I got few informations from Bernard Chavonnet (the author 
of CDXtract) just to get me started.
The S3000 mainly differs in the patch format. I think one can read a 
S3000 sample disc as a S1000 sample disc and only loose the S3000 
specific stuff.


> 
> Are you sure Akai patches are distributed as files? I'd like to find
> this out, because I'm thinking that filesystem and lowlevel device
> access code really does not belong in libInstPatch. It seems somewhat
> like a portability nightmare and I wan't to try and keep libInstPatch as
> portable as possible.
> 

I have never seen akai files and i'm pretty sure commercial sample banks 
are distributed on Akai formated CDRoms. I resolved the device access 
quite simply in libakai: there is a very small class dedicated to device 
access and it is implemented for each platform.

> The way I'd like to see things, is that an external utility is used to
> rip the instruments off of different medias and convert them to files
> that can then be imported using libInstPatch. Can one find Akai patches
> on the internet for example? What format would they most likely be in?
> 

You may find akai CDRoms rip off on edonkey/gnutella/kazaa... I never 
saw other akai format sample lib downloadable anywhere.



> 
> 
> Looking at some of the disk access code, libakai appears to support only
> MAC OS X and win32 systems currently. The code doesn't seem that complex
> though, so I'm sure it could be easily ported to Linux.
> 

I think you can reuse 95% of the OSX code for linux. The missing 5% will 
be the code needed to find a CDRom reader (this is a pain in OSX, quite 
easy in Win32 and I beleive straitforward in linux). Libakai can also 
read directly from a standard file so accessing /dev/cdrom directly may 
work.

> What revisions of the Akai formats are most desirable to support? Here
> is what I currently have:
> 
> S900/S950
> S1000
> S3000
> MPC-2000
> S5000/S6000
> 

I work at Ultimate Sound Bank (www.usbsounds.com) and here we produce 
only S1000/S3000 formats for Akai.


>>From what I have heard on this list S1000 is the most popular?
> 
> I think it would be wisest to implement Akai support directly in
> libInstPatch for cleanliness and to reduce dependencies. I think the
> libakai source as well as the akaiinfo web page will prove quite useful
> in doing this. It would be nice to collaborate with the libakai author,
> Sebastien, and perhaps see about getting libInstPatch to use the files
> ripped from a libakai based ripper utility.
> 
> 

I don't plan to remove the ngl dependency on libakai, mainly because i 
truly think ngl is a far better framework than any other I allready 
tried (for what I do anyway). But removing the dependency seems quite 
doable. I think the only used ngl classes are nglString (encoding aware 
multipurpose string class) and nglIStream (encoding/endianness aware 
streaming class that unifies the IO API nicely).

The actual loading code is really simple and is just a matter of knowing 
  what to look for and where to look for it.

What is missing from libakai is the actual interpretation of each 
parameter (what is linear, what is lorarythmic, etc...). There is a lot 
of work left about this and you will have to do it if you want a unified 
API in the patch library. You will face a lot of diferences between all 
the diferent patch formats available and interpreting them right often 
proves to be a pain as Bernard Chavonnet discovered some years ago :).


Sebastien

Re: [Linuxsampler-devel] AKAI samplelibrary loader is online

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

On Tue, Mar 25, 2003 at 10:28:31PM -0800, Josh Green wrote:
> What revisions of the Akai formats are most desirable to support? Here
> is what I currently have:
> 
> S900/S950
> S1000
> S3000
> MPC-2000
> S5000/S6000

I have some S2000 format zip disks sitting in my desk draw. From what I
remeber its very similar to S3000 format, but I dont know if its identical.

- Steve 

Re: [Linuxsampler-devel] AKAI samplelibrary loader is online

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

On Tue, 2003-03-25 at 14:51, Christian Schoenebeck wrote:
> On Tue, 25 Mar 2003 12:20:37 +0100
> Benno Senoner <be...@ga...> wrote:
> 
> > Hi, I'm forwarding a mail from Sebastien, he has put online
> > his AKAI samplelibrary loader which will be useful for AKAI import
> > in LinuxSampler. 
> 

Okay, I just had a look at the code for libakai. The following are some
of my thoughts and findings concerning the Akai formats, libakai and
libInstPatch. I would like to invite Sebastien to correct me and perhaps
clairify what the scope of libakai is. It would be really nice to
collaborate on this stuff :)

It seems like libakai is currently based on the S1000 format. I just
realized by looking at the document at:
http://www.abel.co.uk/~maxim/akai/akaiinfo.htm which the libakai library
appears to have used as a reference (from the look of the comments) that
the S3000 sample format appears to be identical to the S1000 format (I
don't believe the program data is the same though). That makes things a
little easier when thinking of supporting multiple akai formats. The
later formats appear to use WAVE files which should also ease things.

> 
> > AKAI S1000/2000 does not use files  but reads the samples directly
> > from CD. Alternatively one can dump the CD's image to a file 
> > (cat /dev/cdrom >file.img :-) ) and then work on that image.
> 
> Actually it has files, though very primitive and Akai uses *of course*
> it's own file system. As some Akai CDs do also contain demo audio
> tracks, I was thinking about extracting only the first track instead of
> reading the whole CD image.
> 

Are you sure Akai patches are distributed as files? I'd like to find
this out, because I'm thinking that filesystem and lowlevel device
access code really does not belong in libInstPatch. It seems somewhat
like a portability nightmare and I wan't to try and keep libInstPatch as
portable as possible.

The way I'd like to see things, is that an external utility is used to
rip the instruments off of different medias and convert them to files
that can then be imported using libInstPatch. Can one find Akai patches
on the internet for example? What format would they most likely be in?

> > Anyway being CD image based, it is not easy to write 
> > manipulated data to HD (one would need to create a whole image) but I
> 
> As Akai tracks also consist of files, I think that should not be a
> problem. So I think manipulation of Akai patches, writing to HD,
> creating Akai ISOs and burning them back on CDs should be possible.
> 
> I'm just curious if he solved the Teledisk problem. As some Akai
> libraries seem to use this odd "Teledisk" format and I was not able to
> find any information about it.
> 

Looking at some of the disk access code, libakai appears to support only
MAC OS X and win32 systems currently. The code doesn't seem that complex
though, so I'm sure it could be easily ported to Linux.

What revisions of the Akai formats are most desirable to support? Here
is what I currently have:

S900/S950
S1000
S3000
MPC-2000
S5000/S6000

From what I have heard on this list S1000 is the most popular?

I think it would be wisest to implement Akai support directly in
libInstPatch for cleanliness and to reduce dependencies. I think the
libakai source as well as the akaiinfo web page will prove quite useful
in doing this. It would be nice to collaborate with the libakai author,
Sebastien, and perhaps see about getting libInstPatch to use the files
ripped from a libakai based ripper utility.

> CU
> 

Cheers.
	Josh Green

Re: [Linuxsampler-devel] AKAI samplelibrary loader is online

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

On Tue, 25 Mar 2003 12:20:37 +0100
Benno Senoner <be...@ga...> wrote:

> Hi, I'm forwarding a mail from Sebastien, he has put online
> his AKAI samplelibrary loader which will be useful for AKAI import
> in LinuxSampler. 

:) Ok, that means I can stop my work then. I was already working on some
experimental code for that.

> AKAI S1000/2000 does not use files  but reads the samples directly
> from CD. Alternatively one can dump the CD's image to a file 
> (cat /dev/cdrom >file.img :-) ) and then work on that image.

Actually it has files, though very primitive and Akai uses *of course*
it's own file system. As some Akai CDs do also contain demo audio
tracks, I was thinking about extracting only the first track instead of
reading the whole CD image.

> Anyway being CD image based, it is not easy to write 
> manipulated data to HD (one would need to create a whole image) but I

As Akai tracks also consist of files, I think that should not be a
problem. So I think manipulation of Akai patches, writing to HD,
creating Akai ISOs and burning them back on CDs should be possible.

I'm just curious if he solved the Teledisk problem. As some Akai
libraries seem to use this odd "Teledisk" format and I was not able to
find any information about it.

CU

Re: [Linuxsampler-devel] status update for LinuxSampler -- GUI and native format

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

On Tue, 2003-03-25 at 03:41, Marek Peteraj wrote:
> On Tue, 2003-03-25 at 05:34, Josh Green wrote:
> > 
> > I myself can see many nice eye candy widgets being written for GTK or QT
> > and integrated with other apps. In this sense I don't see it as really
> > writing the GUI from scratch but more extending existing ones. 
> 
> But we really should derive from the look&feel of other pro samplers in
> this regard.
> 

Sure, why not. But from my perspective the GUI interface is secondary,
and one can have multiple looks & feels :)

> > Its nice to have things like menus, 
> > trees, lists, etc and not have to implement
> > them all by hand :) 
> 
> My guess is that in the main app window the lists and trees won't be
> needed at all.
> 

We're probably talking about different uses here. I'm talking about
Swami in particular which the current scope is as a patch editor. I find
things like trees, etc very useful when it comes to editing patches :) I
forsee the scope of Swami going more into the realm of what you are
talking about, which is a tool for doing real time instrument
manipulation. The current architecture, I believe, lends itself to many
uses. In the future I can see applications developed off of libswami
that won't resemble the Swami GUI at all. One example of this is a
Python driven instrument database for the web and possibly to manage
ones local library as well. libswami has plugin support, so extra
functionality could also be implemented via plugins.

> > I'm looking into using the GnomeCanvas widget for
> > all waveform displays (ardour uses the GTK+ version of this canvas) as
> > well as all envelope, LFO and other graph based GUI widgets. 
> 
> GnomeCanvas 2 was reported to be buggy, and smowhat deprecated now that
> people use a foo-canvas module which takes use of gtk2 built-in stuff.
> But Paul Davis is considering the port of gtk-canvas to gtk2 so maybe we
> could use, ulilise, help improving, bug-fixing, porting as well. :) 
> 

I'm not particularly attached to which canvas it is, they all have
relatively the same API (actually I'm not real familiar with foo-canvas'
API). I did have reservations about using libgnomecanvas2, but when I
was informed that it does not actually depend on gnome (by the guy who
ported the GTK1.2 canvas), I felt more comfortable using it. If
foo-canvas is robust enough (I heard it doesn't have anti aliasing
support, which seems nice for those who have the CPU/graphics cards to
do it) then I probably would use that. Any particulars on what kind of
bugs gnomecanvas has?

> 
> Marek
> 

Cheers.
	Josh Green

Re: [Linuxsampler-devel] AKAI samplelibrary loader is online

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

On Tue, 2003-03-25 at 03:20, Benno Senoner wrote:
> Hi, I'm forwarding a mail from Sebastien, he has put online
> his AKAI samplelibrary loader which will be useful for AKAI import
> in LinuxSampler. 
> Josh, is the import and of AKAI in Swami fleasible ?
> AKAI S1000/2000 does not use files  but reads the samples directly from
> CD. Alternatively one can dump the CD's image to a file 
> (cat /dev/cdrom >file.img :-) ) and then work on that image.
> Anyway being CD image based, it is not easy to write 
> manipulated data to HD (one would need to create a whole image) but I
> think read-only support for AKAI is enough since it allows you to
> reuse old AKAI CDs. If you need to edit them I guess it would be better
> to convert the sample to a newer format (like GIG) and do the editing
> on that format.
> 
> cheers,
> Benno
> http://linuxsampler.sourceforge.net
>  

Yeah I think it is feasible :) Of course it might make sense to use this
library directly instead of implementing it in libInstPatch, depending
on how flexible its API is. Then again it might be more convenient if
the code was part of libInstPatch. I'll take a look at it. Import only
support sounds like a good idea to me, probably not too many people will
be looking to author Akai format files. Cheers.
	Josh

> 
> Scrive Sebastien Metrot <me...@me...>:
> 
> > Hi Benno!
> > 
> > As promissed I have uploaded my akai loading lib hack to 
> > sourceforge.net. You can get the code by cvs at cvs.libakai.sf.net 
> > (module libakai). How ever I used my own multiplatform application 
> > framework to do it, ngl, which can be retreived by cvs at cvs.ngl.sf.net 
> > module ngl. The lib currently runs allright on MacOSX and Win32. I 
> > mostly used only posix calls for the macosx version so it will probably 
> > be really easy to port to linux. The licence is LGPL.
> > 
> > Sebastien (MeeLoo) Metrot
> > 

[Linuxsampler-devel] AKAI samplelibrary loader is online

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

Hi, I'm forwarding a mail from Sebastien, he has put online
his AKAI samplelibrary loader which will be useful for AKAI import
in LinuxSampler. 
Josh, is the import and of AKAI in Swami fleasible ?
AKAI S1000/2000 does not use files  but reads the samples directly from
CD. Alternatively one can dump the CD's image to a file 
(cat /dev/cdrom >file.img :-) ) and then work on that image.
Anyway being CD image based, it is not easy to write 
manipulated data to HD (one would need to create a whole image) but I
think read-only support for AKAI is enough since it allows you to
reuse old AKAI CDs. If you need to edit them I guess it would be better
to convert the sample to a newer format (like GIG) and do the editing
on that format.

cheers,
Benno
http://linuxsampler.sourceforge.net
 

Scrive Sebastien Metrot <me...@me...>:

> Hi Benno!
> 
> As promissed I have uploaded my akai loading lib hack to 
> sourceforge.net. You can get the code by cvs at cvs.libakai.sf.net 
> (module libakai). How ever I used my own multiplatform application 
> framework to do it, ngl, which can be retreived by cvs at cvs.ngl.sf.net 
> module ngl. The lib currently runs allright on MacOSX and Win32. I 
> mostly used only posix calls for the macosx version so it will probably 
> be really easy to port to linux. The licence is LGPL.
> 
> Sebastien (MeeLoo) Metrot
> 
> 
> 
> Benno Senoner wrote:
> 
> >Hello LinuxSampler guys :-)
> >
> 


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

Re: [Linuxsampler-devel] status update for LinuxSampler -- GUI and native format

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

On Tue, 2003-03-25 at 05:34, Josh Green wrote:
> On Mon, 2003-03-24 at 15:57, Marek Peteraj wrote:
> > 
> > My personal feeling is that the GUI itself could be done from scratch
> > according to the needs of 2)
> > The reason why i'm proposing this is, that a good sampler needs real
> > eye-candy too ;) and i would like to do something about it either by
> > doing some artwork in blender and gimp and/or by chasing some people on
> > deviantart.com or similar. But it's not just pure eye-candy, this adds a
> > whole lot of functionality as well, Halion and Mach5 being the best
> > examples. The overall design of the GUI is very important and plain QT
> > or GTK just isn't enough for it IMO. What i want/need here is to have a
> > nice rendered keyboard(which isn't that difficult since it's sufficient
> > to render just a few white and black pressed/released keys to build the
> > whole keyboard) a few types of knobs(which isn't difficult either except
> > for some moog knobs) and an efficient way to display waveforms of
> > samples and scroll them without artefacts(power of 2 should do). If you
> > look at Native Instruments Kontakt you can see that the GUI is very
> > simple in terms of eye-candy but very efficient as well.
> > 
> 
> I myself can see many nice eye candy widgets being written for GTK or QT
> and integrated with other apps. In this sense I don't see it as really
> writing the GUI from scratch but more extending existing ones. 

But we really should derive from the look&feel of other pro samplers in
this regard.

> Its nice to have things like menus, 
> trees, lists, etc and not have to implement
> them all by hand :) 

My guess is that in the main app window the lists and trees won't be
needed at all.

> I'm looking into using the GnomeCanvas widget for
> all waveform displays (ardour uses the GTK+ version of this canvas) as
> well as all envelope, LFO and other graph based GUI widgets. 

GnomeCanvas 2 was reported to be buggy, and smowhat deprecated now that
people use a foo-canvas module which takes use of gtk2 built-in stuff.
But Paul Davis is considering the port of gtk-canvas to gtk2 so maybe we
could use, ulilise, help improving, bug-fixing, porting as well. :) 


Marek

Re: [Linuxsampler-devel] status update for LinuxSampler -- GUI and native format

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

On Mon, 2003-03-24 at 15:57, Marek Peteraj wrote:
> 
> My personal feeling is that the GUI itself could be done from scratch
> according to the needs of 2)
> The reason why i'm proposing this is, that a good sampler needs real
> eye-candy too ;) and i would like to do something about it either by
> doing some artwork in blender and gimp and/or by chasing some people on
> deviantart.com or similar. But it's not just pure eye-candy, this adds a
> whole lot of functionality as well, Halion and Mach5 being the best
> examples. The overall design of the GUI is very important and plain QT
> or GTK just isn't enough for it IMO. What i want/need here is to have a
> nice rendered keyboard(which isn't that difficult since it's sufficient
> to render just a few white and black pressed/released keys to build the
> whole keyboard) a few types of knobs(which isn't difficult either except
> for some moog knobs) and an efficient way to display waveforms of
> samples and scroll them without artefacts(power of 2 should do). If you
> look at Native Instruments Kontakt you can see that the GUI is very
> simple in terms of eye-candy but very efficient as well.
> 

I myself can see many nice eye candy widgets being written for GTK or QT
and integrated with other apps. In this sense I don't see it as really
writing the GUI from scratch but more extending existing ones. Its nice
to have things like menus, trees, lists, etc and not have to implement
them all by hand :) I'm looking into using the GnomeCanvas widget for
all waveform displays (ardour uses the GTK+ version of this canvas) as
well as all envelope, LFO and other graph based GUI widgets. This will
allow these other controls to be overlayed ontop of a waveform display
so one can set parameters in relation to the timing of the waveform.
Ideally eye candy and other such controls could be written as plugins in
Swami.

> I would also like to add some thoughts about linuxsamplers native
> format, which linuxsampler should have IMO.
> I was thinking of something like:
> - XML data - descriptions and settings -- bzipped
> - FLAC compressed sample data
> - peakfiles(?)
> - all packed up in tar
> Notice that this would be the first time for a package to be bz2.tar and
> not tar.bz2 :))
> The only problem with FLAC(and other lossless compressions currently) is
> that it doesn't handle floats yet. I'm not sure whether you guys
> considered to use floats as well, probably yes. 
> 

Thats actually not such a bad idea. If linuxsampler becomes truely
modular it might find static patch formats not flexible enough for its
full capacity.

> Marek
>   

Cheers.
	Josh Green

Re: [Linuxsampler-devel] status update for LinuxSampler

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

On Mon, 2003-03-24 at 12:41, Benno Senoner wrote:
> 
> As far as I can see it, the sampler consists of several sub-projects
> which are related:
> 
> 1) instrument loading library
> 
> 2) sample playback engine for each kind of sample library format
>   which permits real time / sequenced playback and real time modulation
>   of parameters (LFO, filters, ecc)
> 
> 3) a graphical editor that permits loading (through 1) ),creation and
> manipulation of instrument libraries.
> 
> 
> Personally  I will focus on 2) since it involves
> real time stuff, optimized data flow mechanisms, streaming etc.
> 
> I think swami could solve 1) and 3) as long as it is flexible in providing
> support for various sample formats.
> 

Yes, I could see Swami/libInstPatch fitting nicely with 1 and 3.
libInstPatch and Swami aim to be as flexible as possible with patch file
formats. In other words, I haven't tried to integrate all patch formats
(an insane task), so each important format will be supported natively
(all details of the format for load/manipulate/store). Many old or not
so important formats will probably just have import support. Much of the
API is integrated in the use of GObject though (all objects have "name"
based properties with a fairly extensive type and parameter system).

libInstPatch does have in mind multi-threading capability. There is
still a bit that should be done in the area of performance versus
multi-threading though, particularly relating to item lists.

I'd like to get a better idea of how linuxsampler will be accessing
patch objects. I remember this was discussed a little. It seems like the
synthesis process should be constructed when an instrument is selected
(MIDI bank:program change, whatever). So it might go something like
this:

- instrument selection (MIDI bank:program change)
- linuxsampler patch type specific synthesis constructor called
- synthesis network setup and populated from libInstPatch objects
- wait for input events (MIDI note on/off, real time effect control
requests, etc)

In this scenario the performance requirements of libInstPatch are
minimized as the parameters are fetched at instrument select time. Real
time sensitive parameter changes could be sent via linuxsampler API
calls while other changes could be monitored via property change signal
callbacks.

> Regarding the engine:
> 
> some said they do not like C++ and want do to everything in C etc:
> 

I'm a C coder myself, but I also like OO stuff. GObject is what I have
decided to use for libInstPatch/Swami. Its taken me a while to
understand GObject fully and a lot of things seem kind of hackish (and I
guess kind of are since C wasn't designed for OO stuff), but I'm
beginning to like it. I'm not real sure of the performance implications,
but I know GStreamer uses this same platform. glib (what GObject is now
part of) is a nice utility library that has lots of things like hash
tables, linked lists, binary trees, memory chunks, cross platform
threading and variable types (guint32, gint16, etc).
I'm not opposed to C++ though. I am curious how well GObject related
stuff would mesh with C++ code.

> 
> Regarding the audio rendering:
> 
> My idea was to make sort of modular sampler where you assemble the basic
> building blocks with the most important module being the sampleplayback module
> (a RAM and a disk-streaming version).
> The idea was to assemble modules at source code level so that the compiler
> can create a very efficient engine which is almost as fast as a handcoded one
> but provides the flexibility of permitting the creation of instruments in a
> modular fashion though a GUI, similar as Native Instruments Reaktor and others do.
> 

<cut>

> 
> Do you agree of going down that road or should we take other paths ?
> 

I think the modular design fits with what linuxsampler is supposed to
be. So yes, I agree with that path. I like the idea of a system that
builds custom code though (I was looking into a similar thing a while
back where each module was an assembler macro and then a master routine
would be auto-generated with the calls to the macros). Even just
starting out with each module being a subroutine would give us the basis
of a modular synth and optimization tricks to remove subroutine
overhead, etc could be implemented later (self building code). I think
thought should first be put into the different types of modules, how
they will route their inputs and outputs and the range of patch formats
that we are looking to support. Wavetable interpolators, envelopes,
LFOs, filters, LADSPA plugins, reverb, and chorus O MY!

> 
> Josh: I added you to the project admins (full access to everything) on the
> project page of LinuxSampler since I assume you will be the main contributor to
> the sample library handling for linux sampler.
> 

Hmm. For right now I think I will be using Swami/libInstPatch project
site/CVS/etc as the source of information. Perhaps we could try and
cross link the two sites more in this regard though. I can see
linuxsampler and libInstPatch/Swami being a nice marriage of programs,
but they will probably also be useful separately as well. This is the
design that has been followed with FluidSynth. Our projects don't depend
on each other, they just work well together :) I'd be more than happy to
help with stuff on the linuxsampler site, but I kind of feel like my
effort is best concentrated on libInstPatch and Swami right now (which
I'm sure will help linuxsampler in the end).

> Regarding the GIG format docs (I assume Paul Kellett sent you Ruben's header
> files), how about posting them on the LinuxSampler site (you can now upload
> stuff yourself) so that others can see the structure of the chunks too ?
> 

Yes, I got the GIG format docs. They will come in real handy :) I'm not
quite at the stage where I will be adding .gig support yet though (still
adding DLS2 support). If there are requests for these docs (anyone?), I
will certainly put them up. I just hesitate to do non-coding stuff when
it won't be that useful, he he.

> waiting for your feedback guys.
>  
> cheers,
> Benno
> 
> http://linuxsampler.sourceforge.net
> 

Its nice to feel like a part of a community here. I'm constantly working
on libInstPatch and Swami and much of the work that I have been doing
has not yet seen the light of day. API work is very time consuming and
sometimes frustrating when one doesn't get the rewards of seeing it in
action. The time to see this work in action is close at hand, I can feel
it. There is still a bit more that I need to do to get the patch
pluggable architecture of Swami in order (mostly GUI stuff). The
addition of DLS2 will pave the way for this and things should go
smoother afterwards. When this starts to come together I will start
looking into how to interface it with linuxsampler. Cheers.
	Josh Green

Re: [Linuxsampler-devel] status update for LinuxSampler -- GUI and native format

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

> 
> 3) a graphical editor that permits loading (through 1) ),creation and
> manipulation of instrument libraries.
> 
> 
> Personally  I will focus on 2) since it involves
> real time stuff, optimized data flow mechanisms, streaming etc.
> 
> I think swami could solve 1) and 3) as long as it is flexible in providing
> support for various sample formats.


My personal feeling is that the GUI itself could be done from scratch
according to the needs of 2)
The reason why i'm proposing this is, that a good sampler needs real
eye-candy too ;) and i would like to do something about it either by
doing some artwork in blender and gimp and/or by chasing some people on
deviantart.com or similar. But it's not just pure eye-candy, this adds a
whole lot of functionality as well, Halion and Mach5 being the best
examples. The overall design of the GUI is very important and plain QT
or GTK just isn't enough for it IMO. What i want/need here is to have a
nice rendered keyboard(which isn't that difficult since it's sufficient
to render just a few white and black pressed/released keys to build the
whole keyboard) a few types of knobs(which isn't difficult either except
for some moog knobs) and an efficient way to display waveforms of
samples and scroll them without artefacts(power of 2 should do). If you
look at Native Instruments Kontakt you can see that the GUI is very
simple in terms of eye-candy but very efficient as well.

I would also like to add some thoughts about linuxsamplers native
format, which linuxsampler should have IMO.
I was thinking of something like:
- XML data - descriptions and settings -- bzipped
- FLAC compressed sample data
- peakfiles(?)
- all packed up in tar
Notice that this would be the first time for a package to be bz2.tar and
not tar.bz2 :))
The only problem with FLAC(and other lossless compressions currently) is
that it doesn't handle floats yet. I'm not sure whether you guys
considered to use floats as well, probably yes. 

Marek
  

[Linuxsampler-devel] status update for LinuxSampler

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

Hello LinuxSampler guys :-)

sorry for being that quiet but was a bit overloaded again during
the last two few months.

I've read all pending mails and I will try to summarize my thoughts about
the project and its future and the current status and how we can collaborate
in order to maximize parallelism.

As far as I can see it, the sampler consists of several sub-projects
which are related:

1) instrument loading library

2) sample playback engine for each kind of sample library format
  which permits real time / sequenced playback and real time modulation
  of parameters (LFO, filters, ecc)

3) a graphical editor that permits loading (through 1) ),creation and
manipulation of instrument libraries.


Personally  I will focus on 2) since it involves
real time stuff, optimized data flow mechanisms, streaming etc.

I think swami could solve 1) and 3) as long as it is flexible in providing
support for various sample formats.

Regarding the engine:

some said they do not like C++ and want do to everything in C etc:

My take on this is that we should find some good compromise between performance
and modularity and flexibility of the engine.
My old evo code is written in C++ and IMHO it offered various advantages over
a C implementation without any performance degradation.
I'm not a heavy-duty C++ programmer thus usually I use only basic C++ features
like classes and methods.
In the case of a sample player C++ helps you to bind data structures to certain
 objects (eg voices) without messing around with tons of structures and passing
 around pointers of structures between various functions.
Ringbuffer C++ templates (lock-free FIFOs) proved to work very well in terms of
speed (the resulting assembly code is almost optimal) while helping to 
keep the code clean.
When speaking of code cleaness I do not mean only that it is beauty to read but
 with clean I mean that object oriented design reduces chances that the object
 itself accesses data that is not meant to be accessed by that object possibly
resulting in a program crash or glitch.

Some say they cannot program in C++ so they only contribute if the core is
written in C.
I see this as a bit lame excuse since it is really not that hard to learn what
a class and a method is in C++.
If as a coder, you are able to write good C apps then I do not see why one
should back away from a sample engine written in lightweight C++.

As said, I have nothing in contrary to go plain C, but commonsense says me 
that C++ is the better choice because the sampler project will probably grow
over time and OO design helps you to keep the design of the project/engine cleaner.

Regarding the audio rendering:

My idea was to make sort of modular sampler where you assemble the basic
building blocks with the most important module being the sampleplayback module
(a RAM and a disk-streaming version).
The idea was to assemble modules at source code level so that the compiler
can create a very efficient engine which is almost as fast as a handcoded one
but provides the flexibility of permitting the creation of instruments in a
modular fashion though a GUI, similar as Native Instruments Reaktor and others do.

Some on this list say this is overkill for a sampler and that we should start
with a hardcoded engine and later switch to a moduler one (just-in-time compiled).
I think rather than duplicating the effort it is better to write a very simple
 modular engine and at a later time enhance its capabilities.

My idea was to start with a RAM sampleplayback module that can do only very 
simple stuff:

- it has a pointer to the sample to be played 
- it knows how much samples to play and possibily can access to a simple
 looping list 
- pitch can be modulated
- volume can be modulated

In order to create a very simple MIDI-playable instrument

along with the ram sampleplayer, an instrument loading library is needed.
(loads samples and patches in RAM  and exports pointers to samples and parameters)

another basic module we need to implement is a MIDI input module that maps
incoming MIDI data (MIDI ins or alsa sequencer) to instruments which in turn
point to samples in memory and modulation data that can be used to drive
the RAM sampleplayback module along with some modulators (volume modulator
for creating envelopes and pitch modulator for creating vibratos etc).

I think this would costitute a nice starting point for building a full fledged
 sampler which accepts multiple formats and engines.

I'm not 100% but in my opinion it would be wise to associate a playback engine
o each samplelibrary format.
Eg the GIG engine plays GIG files, the AKAI engine plays AKAI samples.
I do not believe that the "one size fits all" model always work.
As Peter Hanappe pointed out it is better Fluid tries to specialize on playing
 SoundFont samples as good as possible rather than trying to become the 
allround sampler that can play everything.

I think the best way to make LinuxSampler a sampler that can reproduce various
 formats is to make it modular as described above.
Once a handful of basic modules are implemented, I think it will be quite easy
to add new engines since the goal is basically of being able to assemble new
engines using a graphical editor where you wire toghether basic building blocks.
If a new engine needs features that are not covered by the available modules,
fire up your editor, code the module, and then get back to the GUI and complete
the building of the instrument engine you had in mind.

Do you agree of going down that road or should we take other paths ?


I'm currently writing a multichannel sample playback engine (not instruments but
sounds and music) for doing ambient music and noise in a museum room.
I use a Linux PC with two Delta cards (8+8 outs) under ALSA.
This is not a big project but LinuxSampler will profit from this since I will
 get familiar with multichannel audio hardware which should be supported by
professional apps. (as LinuxSampler should be)

Josh: I added you to the project admins (full access to everything) on the
project page of LinuxSampler since I assume you will be the main contributor to
the sample library handling for linux sampler.

Regarding the GIG format docs (I assume Paul Kellett sent you Ruben's header
files), how about posting them on the LinuxSampler site (you can now upload
stuff yourself) so that others can see the structure of the chunks too ?

In the next days I will explain my ideas about volume and pitch modulators
and how to build modulation networks.

To eliminate some confusion: there are currently two codebases for linuxsampler:
one is evo which is basically a proof-of-concept code of a very rudimentary
disk based sampler and the other is the code on CVS uploaded by Juan L. which
is based on the legasynth codebase.
I regard both apps only as proof of concept applications and I suppose 
the real linuxsampler codebase will probably be built from scratch especially
 if we go the modular-recompiler way.
As said the project lacks a bit of organization right now since our goals
are not well defined yet but I think over time things will get better.
Anyway I'd like to discuss with you guys which route to go for building
the sampler's engine.
I know some are getting impatient while other may think this will become another
dead project, but I think there are just too many talented folks on this list
 to let such a cool project die off.
Yes, we all have daytime jobs so sometimes the project's advance will slow down
 a bit but hey, that's life in the open source domain. As long as there will
be interested and enthusiastic people partecipating I do not fear that the
project will die. Linux and powerful GNU software was not built in a day and 
I'm confident too that through collaborative work and discussion linuxsampler
 will some day deliver the funcionality we dreamed of for long time.
(argh too much rethoric, back to code :-) )

PS: Welcome to the ML to the Kurzweil guy too  :-)

waiting for your feedback guys.
 
cheers,
Benno

http://linuxsampler.sourceforge.net




 

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

Re: [Linuxsampler-devel] Updated libInstPatch docs

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

On Sat, 2003-03-22 at 16:16, Juan Linietsky wrote:
> Hi josh! its been a while.
> 

Yeah, it has been a while. How are things?

> I know this may sound weird, but why not ading modules
> as an extra to be loaded as instruments/libraries?
> I'm sure A regular module (it/xm/s3m/mod) can
> be interpreted as a library too.. 
> 
> Cheers!
> 
> Juan Linietsky
> 
> 

Actually that doesn't sound weird. I've thought of it before, but only
for loading instruments from a module. I don't think I would do anything
with the tracker music scores or have save support though as its out of
the scope of libInstPatch. I looked at the API of libmikmod but it seems
geared towards the loading and playing of mods and doesn't give access
to the instrument parameters. I'm sure this library would come in handy
to get source code from though. Having load support for module formats
would allow one to convert them to patch formats, so this does seem like
something useful. Regards.
	Josh Green

Re: [Linuxsampler-devel] Updated libInstPatch docs

[Juan L. <co...@re...>]

On 18 Mar 2003 03:58:55 -0800
Josh Green <jg...@us...> wrote:

> Just updated libInstPatch API docs. They can be found from the
> development page on the Swami web site, heres a direct link:
> 
> http://swami.sourceforge.net/api/libinstpatch/
> 
> Also put directions for checking out swami-1-0 CVS branch on the
> download page. Please note that all development is occuring on the new
> CVS branch and that the current swami-0.9.1 release is hardly related.
> Cheers.
> 	Josh Green

Hi josh! its been a while.

I know this may sound weird, but why not ading modules
as an extra to be loaded as instruments/libraries?
I'm sure A regular module (it/xm/s3m/mod) can
be interpreted as a library too.. 

Cheers!

Juan Linietsky

Re: [Linuxsampler-devel] Patch API

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

On Sat, 2003-03-22 at 05:49, Marc Halbruegge wrote:
> I would like it better if you had a base class that I could derive
> from. Did you define the internal APIs?

IpatchItem is what all patch items are derived from. It provides
refcounting (GObject actually which it is derived from), a recursive
lock, a parenting system (just a pointer really) and some other methods
for duplicating the item, removing it, etc.
IpatchContainer is the other common base class that is for container
objects and is derived from IpatchItem. The container stuff needs a
little more work to make things more backwards compatible friendly to
high performance iteration over the container's children, etc. But for
now it does what its supposed to.
IpatchBase is a base object for toplevel patch files. Its derived from
IpatchContainer and has an IpatchFile object associated with it as well
as a couple flags relating to if the patch has changed and if it has
ever been saved and a few methods for getting an unused MIDI locale,
etc.

If you just get some materials together relating to the format of
Kurzweil and possibly write some loading code I could put it in
libInstPatch and create the objects once I have an understanding of what
the format looks like. So in other words, you don't need to start with
the objects, but the file parser. If it is a RIFF format (probably not)
then there is an IpatchRiffParser object that would come in handy. So
you need not concern yourself with libInstPatch internals if you don't
want to. If you have any ideas about integrating the interface to file
parsers or making them more flexible that could be useful. Right now
libInstPatch is best used for loading/editing/saving from the patch
object system. I'd like to make the file parser/saving code be usable
for doing custom tasks though. Cheers.
	Josh Green

[Linuxsampler-devel] a good sampler needs good samples, right? ;)

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

Hi all,


just to motivate you guys & to show that it's really worth starting this
cool project, check this out:

http://theremin.music.uiowa.edu/MIS.html

well... just in case somebody is interested in 1Gb steinway grand piano
and more... :)

Marek

Re: [Linuxsampler-devel] Patch API

[Marc H. <mha...@un...>]

I would like it better if you had a base class that I could derive
from. Did you define the internal APIs?

Re: [Linuxsampler-devel] Hi

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

On Fri, 2003-03-21 at 05:20, Marc Halbruegge wrote:
> I'd like to implement some code for Kurzweil file import/export for
> your project.
> 
> visit 
> http://kurzfiler.sf.net and
> http://kcdread.sf.net
> 
> to see things I've already done for the machine.
> 
> Greetings
> Marc Halbrügge
> 

Perhaps you would be interested in libInstPatch then? Its part of the
Swami project (http://swami.sourceforge.net). You will find some API
docs on it on the Swami developers page: 
http://swami.sourceforge.net/devel.php

libInstPatch is an object oriented instrument patch library and has
support for SoundFont2 and DLS2 load support was just added. The
programming architecture is C using glib/GObject for object oriented
stuff. Interest has been expressed in using it in LinuxSampler. Let me
know if you are interested and I can help you to add Kurzweil. Do you
know of any docs on the file format? Cheers.
	Josh Green

Re: [Linuxsampler-devel] Initial findings on .gig files

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

On Fri, 2003-03-21 at 02:05, Paul Kellett wrote:
> A long time ago, Benno, me and Ruben van Royen (I think) did some
> investigation.  I've sent the resulting files to Josh in case there is
> information there that isn't buried in the "Evo" source code
somewhere.
>
 
I thank you for that material. Looks like there is some very useful
findings in there, and it will save me a lot of work. I'm curious about
how .gig does regions. From what I can tell it looks like note regions
can't overlap, therefore no layering?
 
> A chunk size of 3 is allowed in RIFF, but the chunk spacing has to be
even
> so  the 4th byte after the "nam0" is just padding.
>
 
Yeah, I know this now. I'm just so accustomed to seeing even byte chunk
sizes and thought that if a block was padded it would be reflected in
the chunk size as well.
 
>
> > rather than file extension. Although the DLS standard is designed to
> > allow custom chunks. I'm curious if these chunks are registered with
the
> > MIDI Manufacturers Association (ones who designed DLS)?
>
> I always assumed they used .GIG instead of .DLS even though it is a
DLS file
> so they didn't have to pay the MMA to register the chunks, or so they
didn't
> have to provide details on what they contained.
>
>
                                                                                
Yeah, I guess they don't consider that the data of a file is a sort of
namespace and they are messing it up :) I'm trying to think of the best
way of handling the loading of .gig files. Since libInstPatch is going
to be supporting multiple formats, I'll have to do some trickery when it
comes to gig files. I guess the DLS parser will be going along doing its
thing and if it runs into a .gig specific chunk, switch to .gig mode or
something. Its really too bad there wasn't some sort of identifier at
the top of the DLS file. A GigaSampler DLS2 conditional DLSID would have
been sufficient.
                                                                                
>
> Paul.
>
                                                                                
Cheers.
        Josh

[Linuxsampler-devel] Hi

[Marc H. <mha...@un...>]

I'd like to implement some code for Kurzweil file import/export for
your project.

visit=20
http://kurzfiler.sf.net and
http://kcdread.sf.net

to see things I've already done for the machine.

Greetings
Marc Halbr=FCgge

Re: [Linuxsampler-devel] Initial findings on .gig files

[Paul K. <pau...@md...>]

Josh Green <jg...@us...> wrote:
> 
> custom chunks that aren't part of the DLS standard. I think it will take
> a little bit of reverse engineering to figure out what they contain. 

A long time ago, Benno, me and Ruben van Royen (I think) did some 
investigation.  I've sent the resulting files to Josh in case there is 
information there that isn't buried in the "Evo" source code somewhere.


> The weirdest thing I saw was a "nam0" chunk in one .gig file that had a
> size of 3. This apparently breaks the RIFF spec I believe, because chunk
> sizes are supposed to be even. Also it appears to be actually 4 bytes in
> length, since the next chunk starts 4 bytes later (maybe its just a
> broken .gig file?).

A chunk size of 3 is allowed in RIFF, but the chunk spacing has to be even 
so  the 4th byte after the "nam0" is just padding.

 
> rather than file extension. Although the DLS standard is designed to
> allow custom chunks. I'm curious if these chunks are registered with the
> MIDI Manufacturers Association (ones who designed DLS)?

I always assumed they used .GIG instead of .DLS even though it is a DLS file
so they didn't have to pay the MMA to register the chunks, or so they didn't
have to provide details on what they contained.



Paul.

_____________________________

  m a x i m | digital audio

    http://mda-vst.com
_____________________________

RE: [Linuxsampler-devel] Initial findings on .gig files

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

>
>
> Some screen shots might be helpful :) If you could put them somewhere
> were I could passively download them, probably not appropriate to post
> to the list (I'm on dialup anyways, so I don't like getting big emails).
> The most important stuff is where effects and parameters are set.
>
> > I think there are two things in GSt to keep in mind. They sort of
> > interact, but we'll have to decide what to focus on:
> >
> > 1) The gig files themselves - what's in them, etc. This is the basic
> > sound. In GSt these have some ADSRs, LFO (I think) and most important,
> > layering of samples across a number of parameters like MIDI velocity..
> >
>
> Okay. Those are the parameters I am talking about. What I am looking for
> are specifics on them. How many ADSRs, LFOs. What effects can be
> modulated by these ADSRs/LFOs (pitch, filter, volume, etc). I need to
> get an idea of what the constraints are to be able to determine whats in
> the files. It may end up that I have to have access to the program to
> try changing parameters and seeing what effect they have on the
> resulting file.
>
> > 2) Performance files. These set up how a user wants to use the gig files
> > in GSt. This sets up the mixer, the effects, and other things. I don't
> > actually do to much with performance files other than make sure I get
> > the right instruments loaded on the right MIDI channel, but they do much
> > more.
> >
>
> Performance files, huh.. That sounds like more to do with how the
> instruments are routed and effects applied on top. Is a peformance file
> something you would setup and use on your own system for multiple gig
> files and not tend to distribute to others?
>

Josh,
   I found a Windows Compiled Help file online at Tascam support for
GigaStudio. Understanding that you may or may not be able to view that
(based on whether you have Windows available) I've printed it's main
sections as PDF files. However, I really recommend using the help file
itself as it's all cross-linked and you'll learn much faster.

   You can find all of this online at

http://www.controlnet.com/~makeMusic/Linux/GigaStudio

Good luck,
Mark

Re: [Linuxsampler-devel] Initial findings on .gig files

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

On Wed, 2003-03-19 at 16:31, Mark Knecht wrote:
> Josh,
>    Exciting news here, or at least for me.
> 
>    PLEASE - use me and my Gig library as a resource. If I can be of help
> somehow, please let me know and I'll try.
> 

I may write a test program to mine the .gig specific stuff so it can be
analyzed to try and figure out whats inside those custom chunks. I'll be
sure to give you a copy to run on a directory of .gig files if it comes
to that.

> On Wed, 2003-03-19 at 15:45, Josh Green wrote:
<cut>
> > would probably help if I'd used GigaStudio before. Can anyone comment on
> > what the synthesis model is? Is it fixed like DLS2/SF2 is (2 LFOs, 2
> > Envelopes, low pass filter, etc) or is it modular?
> 
> I'm not sure I understand this question exactly, but I think it's a
> fixed model, or at least relatively fixed. I could post some screen
> shots or something like that if it would be helpful.
> 

Some screen shots might be helpful :) If you could put them somewhere
were I could passively download them, probably not appropriate to post
to the list (I'm on dialup anyways, so I don't like getting big emails).
The most important stuff is where effects and parameters are set.

> I think there are two things in GSt to keep in mind. They sort of
> interact, but we'll have to decide what to focus on:
> 
> 1) The gig files themselves - what's in them, etc. This is the basic
> sound. In GSt these have some ADSRs, LFO (I think) and most important,
> layering of samples across a number of parameters like MIDI velocity..
> 

Okay. Those are the parameters I am talking about. What I am looking for
are specifics on them. How many ADSRs, LFOs. What effects can be
modulated by these ADSRs/LFOs (pitch, filter, volume, etc). I need to
get an idea of what the constraints are to be able to determine whats in
the files. It may end up that I have to have access to the program to
try changing parameters and seeing what effect they have on the
resulting file.

> 2) Performance files. These set up how a user wants to use the gig files
> in GSt. This sets up the mixer, the effects, and other things. I don't
> actually do to much with performance files other than make sure I get
> the right instruments loaded on the right MIDI channel, but they do much
> more.
> 

Performance files, huh.. That sounds like more to do with how the
instruments are routed and effects applied on top. Is a peformance file
something you would setup and use on your own system for multiple gig
files and not tend to distribute to others?

> 
> > 
> > Since I haven't seen any DLS articulation (effect parameter) data in
> > .gig files I'm assuming most of these chunks (especially in regions) is
> > custom .gig effect parameters. The content of many of the chunks seem to
> > be the same across different files, so perhaps some of them can be
> > ignored.
> 
> I don't understand 'DLS'. Sorry. However, I 'think' much of what you are
> thinking about might be in the Performance file and not in the Gig file.

I don't think so, but it would be good to make sure. What kind of
effects are defined in the performance file? Is it mainly for adding
effects on top of audio channels?

> 
> Please understand that I know absolutely nothing about the internals,
> but I hope to be helpful, without being a hinderance I hope.

You've already been a help :) Any info I can get on how GigaSampler
works from the user interface will help me determine the format
internals.

Regards.
	Josh

Re: [Linuxsampler-devel] Initial findings on .gig files

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

Josh,
   Exciting news here, or at least for me.

   PLEASE - use me and my Gig library as a resource. If I can be of help
somehow, please let me know and I'll try.

On Wed, 2003-03-19 at 15:45, Josh Green wrote:
> The DLS parser in libInstPatch is now functioning to the point of
> loading a DLS file (I'm sure there are some bugs still). I threw a
> couple of .gig files at it and they seem to load fine too. To help debug
> things I wrote a test program to output the RIFF chunks and I found many
> custom chunks that aren't part of the DLS standard. I think it will take
> a little bit of reverse engineering to figure out what they contain. It
> would probably help if I'd used GigaStudio before. Can anyone comment on
> what the synthesis model is? Is it fixed like DLS2/SF2 is (2 LFOs, 2
> Envelopes, low pass filter, etc) or is it modular?

I'm not sure I understand this question exactly, but I think it's a
fixed model, or at least relatively fixed. I could post some screen
shots or something like that if it would be helpful.

I think there are two things in GSt to keep in mind. They sort of
interact, but we'll have to decide what to focus on:

1) The gig files themselves - what's in them, etc. This is the basic
sound. In GSt these have some ADSRs, LFO (I think) and most important,
layering of samples across a number of parameters like MIDI velocity..

2) Performance files. These set up how a user wants to use the gig files
in GSt. This sets up the mixer, the effects, and other things. I don't
actually do to much with performance files other than make sure I get
the right instruments loaded on the right MIDI channel, but they do much
more.


> 
> Since I haven't seen any DLS articulation (effect parameter) data in
> .gig files I'm assuming most of these chunks (especially in regions) is
> custom .gig effect parameters. The content of many of the chunks seem to
> be the same across different files, so perhaps some of them can be
> ignored.

I don't understand 'DLS'. Sorry. However, I 'think' much of what you are
thinking about might be in the Performance file and not in the Gig file.
> 
> The weirdest thing I saw was a "nam0" chunk in one .gig file that had a
> size of 3. This apparently breaks the RIFF spec I believe, because chunk
> sizes are supposed to be even. Also it appears to be actually 4 bytes in
> length, since the next chunk starts 4 bytes later (maybe its just a
> broken .gig file?).
> 
> I think its also quite lame that there doesn't seem to be a way to
> identify a .gig file from a DLS file besides its file extension (and
> running across those custom chunks). I think this is kind of stupid and
> makes things difficult when determining the file type from its data
> rather than file extension. Although the DLS standard is designed to
> allow custom chunks. I'm curious if these chunks are registered with the
> MIDI Manufacturers Association (ones who designed DLS)?

Please understand that I know absolutely nothing about the internals,
but I hope to be helpful, without being a hinderance I hope.
> 
> Cheers.
> 	Josh
> 
> P.S. here are some details on the custom chunks that I found.
> Indentation indicates embedded chunks, the toplevel chunk listed for
> each of these blocks is the last standard DLS chunk in the ancestry.
> 
> 'DLS '<LIST> (Standard DLS RIFF chunk)
>   '3gri'<LIST> (size = 88)
>     '3gnl'<LIST> (size = 76)
>       '3gnm' (size = 64) (values seen: "Default Sample Group")
>   'einf' (size = 98)
> 
> 'rgn '<LIST> (Standard DLS region, effect parameters, key splits, etc)
>   '3lnk' (size = 172)
>   '3prg'<LIST> (varies)
>     '3ewl'<LIST> (size = 196)
>       'wsmp' (size = 36) (seems identical to Standard DLS wsmp chunk)
>       '3ewa' (size = 140)
>   '3dnl'<LIST> (varies)
>     'nam0' (size = 3!!!)
>   '3ddp' (size = 10)
> 
> 'lart'<LIST> (DLS articulation data [effect parameters] list)
>   '3ewg' (size = 12)
> 
> 'wave'<LIST> (DLS sample chunk)
>   '3gix' (size = 4)
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Does your code think in ink? 
> You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
> What are you waiting for?
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

[Linuxsampler-devel] Initial findings on .gig files

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

The DLS parser in libInstPatch is now functioning to the point of
loading a DLS file (I'm sure there are some bugs still). I threw a
couple of .gig files at it and they seem to load fine too. To help debug
things I wrote a test program to output the RIFF chunks and I found many
custom chunks that aren't part of the DLS standard. I think it will take
a little bit of reverse engineering to figure out what they contain. It
would probably help if I'd used GigaStudio before. Can anyone comment on
what the synthesis model is? Is it fixed like DLS2/SF2 is (2 LFOs, 2
Envelopes, low pass filter, etc) or is it modular?

Since I haven't seen any DLS articulation (effect parameter) data in
.gig files I'm assuming most of these chunks (especially in regions) is
custom .gig effect parameters. The content of many of the chunks seem to
be the same across different files, so perhaps some of them can be
ignored.

The weirdest thing I saw was a "nam0" chunk in one .gig file that had a
size of 3. This apparently breaks the RIFF spec I believe, because chunk
sizes are supposed to be even. Also it appears to be actually 4 bytes in
length, since the next chunk starts 4 bytes later (maybe its just a
broken .gig file?).

I think its also quite lame that there doesn't seem to be a way to
identify a .gig file from a DLS file besides its file extension (and
running across those custom chunks). I think this is kind of stupid and
makes things difficult when determining the file type from its data
rather than file extension. Although the DLS standard is designed to
allow custom chunks. I'm curious if these chunks are registered with the
MIDI Manufacturers Association (ones who designed DLS)?

Cheers.
	Josh

P.S. here are some details on the custom chunks that I found.
Indentation indicates embedded chunks, the toplevel chunk listed for
each of these blocks is the last standard DLS chunk in the ancestry.

'DLS '<LIST> (Standard DLS RIFF chunk)
  '3gri'<LIST> (size = 88)
    '3gnl'<LIST> (size = 76)
      '3gnm' (size = 64) (values seen: "Default Sample Group")
  'einf' (size = 98)

'rgn '<LIST> (Standard DLS region, effect parameters, key splits, etc)
  '3lnk' (size = 172)
  '3prg'<LIST> (varies)
    '3ewl'<LIST> (size = 196)
      'wsmp' (size = 36) (seems identical to Standard DLS wsmp chunk)
      '3ewa' (size = 140)
  '3dnl'<LIST> (varies)
    'nam0' (size = 3!!!)
  '3ddp' (size = 10)

'lart'<LIST> (DLS articulation data [effect parameters] list)
  '3ewg' (size = 12)

'wave'<LIST> (DLS sample chunk)
  '3gix' (size = 4)