[fluid-dev] [Fwd: RE: More patch support from timidity? (libInstPatch/Swami)]

[Josh Green]

Thought maybe folks here on the FluidSynth list might be interested in
this discussion too since FluidSynth is part of it. Cheers!
        Josh Green


-----Forwarded Message-----
From: Josh Green <address@hidden>
Cc: address@hidden, Swami Devel <address@hidden>
Subject: RE: More patch support from timidity? (libInstPatch/Swami)
Date: Sun, 19 Sep 2004 03:27:34 -0700

On Sat, 2004-09-18 at 08:47, Pieter Penninckx wrote:
> Hi,
> 
> John Richard Moser wrote to the soundtracker-discuss mailing list:
> > I've suggested that the Timidity project work with SoundTracker and
> > others to move sample/patch format support into a common library.  The
> > API should be such that the library will report what formats are
> > supported and convert them on load to a common format.
> > 
> > http://sourceforge.net/forum/forum.php?thread_id=1143428&forum_id=217456
> > 
> > In essence, the library should operate at the Presentation layer of the
> > OSI model.  Data for patches needs to be presented to the Application
> > layer (the program using the API) in a common format.  The library will
> > of course descend into the Session layer-- open the file (create a
> > session), read in the data, close the file.  Beyond that, this is not a
> > networking application, so the lower parts of the OSI model aren't affected.
> > 
> > Timidity++ has support for GUS patches, some soundfont support, and I
> > believe looped wavs.  Support for ITI (Impulse Tracker Instruments) and
> > XI could be added to the library as well (XI support comes from
> > SoundTracker).  Any supported formats from any other libraries available
> > could also be added, by having the library interface with those other
> > libraries.
> > 
> > Timidity has reverb and chorus as well.  Those algorithms should go into
> > the timidity/SoundTracker library as well.  They should probably be
> > plug-in based and again provide a common interface through the library
> > to the plug-ins.
> > 
> > Work together, seriously.  It'll help.  SoundTracker is a nice program,
> > though I'm used to modplug tracker myself :)
> Perhaps it's not a bad thing you can't write such a library
> yourself, John Richard Moser, since that perhaps avoided you from
> writing a library that one doesn't need to start to write, since it
> is allready being warked on!
> 
> The library is called libinstpach and is being developped by Josh
> Green, the author of Swami, a soundfont editer which is the

> successor (is that the word?) of Smurf. It can currently handle

Yes successor is probably the right word.

> soundfont files and other file formats (not including .pat, XI, and
> ITI) are being worked on (see
> <http://swami.sourceforge.net/api/libinstpatch/>). I don't know
> wether it meets your description, but the interesting thing about
> working together is that there are different ideas from which you
> can choose the best. libinstpatch is rather mature I think, so I
> don't know wether there is space left to adopt some of your ideas
> (if needed), but I think it is worth to have a look at it. And
> perhaps, when you (or someone else) has the time to code, .pat, XI
> and ITI support can be added.
> 
> Kind regards, 
> 
> Pieter Penninckx
> 

I really like where this conversation is going!  I've been starting to
also think it would be really nice to network projects together. That
was one reason I wrote libInstPatch as a library. Its been about a 2
year development cycle on the new revision (gee how many times do you
have to re-write a program to get it right :)  I feel confident that
this time I did get something right at least, and I'm starting to see
how close it is to being pretty.. cool. Swami is now also built on top
of it too, and is also written as libraries (libswami and swamigui).

Whats missing is tight integration with sequencers and the desktop
environment. I think there is a lot that could be done in this area to
make Linux THE music composition environment. I have also been thinking
a lot about GStreamer, since it shares the same software platform as
libInstPatch/Swami, that is GObject and C. I think making instrument
patches a core part of the user desktop is one of the most exciting
things I'd like to see happen.

For those of you interested in more of the technical details of
libInstPatch/Swami have a look at the web site.

http://swami.sourceforge.net

Developers page with API for libInstPatch, libswami and swamigui.
http://swami.sourceforge.net/devel.php

There is also a format called CRAM (Compress hybRid Audio Media) which
is part of libInstPatch. It is based on EBML and uses FLAC and gzip
(lossy vorbis also planned) to compress files that contain binary and
audio data (a key target being instrument patches, currently SF2, DLS
and GigaSampler are supported). You can find the spec for the CRAM
format by clicking on the CRAM mini banner on the swami homepage (I'm
pretty sure that specification is set in stone, unless anyone has some
good ideas for changes :)

Swami/libInstPatch still needs a lot of development so if anyone is
interested in helping out directly with the project, please post to the
Swami developers list I could use the company :)  I'm also really
interested in coming up with cool standards for being able to network
our projects.


--------------------------
Swami/libInstPatch details

Just because I've been so quiet about the new Swami/libInstPatch for so
long, I just have to give it justice by writing about some of its
features. Feel free to read on, as you please (this email is getting
big).

- Object oriented architecture built on GObject and C with bindings for
Python (C++ planned), same architecture as GStreamer/Gnome/Gimp etc.

Swami is built on 3 parts (listed in least dependent to most dependent
order):

libInstPatch: Library for loading/saving patch files into object trees
for editing/converting/etc in a multi-threaded fashion, a sample manager
that leverages on sample libraries like audiofile and libsndfile and
other sources. Provides a common API to differing patch files, without
having a one size fits all mentality. DLS is likely going to be one of
the native formats (at least as a middle man for conversion), but
XML/sample files seems quite appealing, especially when thinking how
easy it would be to implement and could export any format (anything
properly GObjectified really).

libswami: All things swami that aren't tied to the GUI or more patch
file specific. This includes plugin system, MIDI and Wavetable devices
(example: FluidSynth plugin), a model/view/controller value independent
event network, based on GValues, for routing control values and MIDI,
and other shhtuff.

swamigui: Object oriented GTK2 GUI instrument editor. Many widgets based
on GnomeCanvas (no dependence on Gnome actually). Basically the GUI
bits. Drag and drop interface elements and views, split/delete view
panes, Python shell, model/view/controller controls (tweak a value or
add/delete an object and see it change in the GUI).

Areas for networking to other applications:
- Soft synthesizers (such as FluidSynth, LinuxSampler, etc)
- Sample editors (embedded or tmp file loading/syncing)
- Sequencers (to bust out the beats - SoundTracker comes to mind)
- Desktop integration (GStreamer)


.. Wow, I'll stop there. Really excited every time I think about Linux
(free software really) and how close it is to becoming one of the best
music composition environments. It also comes to my attention that this
is largely dependent on how well free software projects network
together. I'm looking forward to joining this effort with my own
projects and willingness to see it happen. Cheers! With some of the
finest brew of your choosing :)
        Josh Green

signature.asc
Description: This is a digitally signed message part