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