Subject: Re: [linux-audio-dev] Sample conversion tools
From: Josh Green (jgreen_AT_users.sourceforge.net)
Date: Tue Jun 04 2002 - 09:43:53 EEST
On Mon, 2002-06-03 at 15:43, rm wrote:
> On Mon, Jun 03, 2002 at 03:00:48AM -0600, Josh Green wrote:
> > [...]
> > planned to not try to provide a standard API to all formats (seems
> > completely insane to try :) but instead provide a base object (currently
> > called SFItem in libsoundfont) that provides a linked tree structure,
> > ref counting, and type information.
> > I currently have another library called libswami that wraps
> > libsoundfont. It contains property set/get functions, etc. I've been
> > contemplating as to whether this stuff should be put in libinstpatch or
> > not. I would really like to work with others on this, so I'm eager to
> > hear your answer :) Cheers.
>
> you're architecture looks nice.
Thank you, that means a lot to me, since it is my first library :)
> my aim is much less ambitious
> though. i would just like to get the data out into a simple and
> documented format that can then be used however one likes (converting
> to another format, using in synths and sample playback engines, etc).
>
> hopefully, this will make it reasonably easy to write plugins while
> making the output data easy to use without further use of the tool.
>
> so i think the two projects are more complementary than strictly
> overlapping. i would like to see the format output from this tool
> supported by your library. i'd also be interested in hearing your
> thoughts on what information and in what format the output should be.
>
> thanks,
> rob
>
I still don't completely understand what your goal is, could you
elaborate more on it? Then I can get a better idea of how these two
projects could be complementary :)
Goals for libInstPatch:
- Provide low level callback based loading/saving routines for various
patch formats (does not use object system)
- an object system that patch files can be loaded into, can be
manipulated, and saved from (a common API would be provided for dealing
with items in the object system, but each format would have its own set
of functions for manipulating it, i.e. I'm not attempting to unify all
patch formats)
- a sample storage method API for allowing different sources of stored
sample data (Patch file, disk swap buffer, RAM, ROM, etc)
- Some form of locking to allow concurrent access to the object system
(multiple threads, clients, etc)
- A protocol for communicating patch editing operations between
computers/programs (CORBA maybe? donno much about it)
To be honest I'm really not interested in supporting every synthesizer
patch format out there. My current goals are to add DLS support
(SoundFonts are already fully supported and used in Swami). So in this
sense I can see how these two projects don't overlap in goals.
BTW if anyone is interested in helping out with libInstPatch I could
really use it. Even just some help with decisions, like whether using
glib is a good/bad idea. Or if I should even use GObject? I'm also
looking for Swami developers :) Cheers!
Josh Green
This archive was generated by hypermail 2b28 : Tue Jun 04 2002 - 09:45:40 EEST