iiwusynth-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [iiwusynth-devel] FluidSynth release


From: Josh Green
Subject: Re: [iiwusynth-devel] FluidSynth release
Date: 23 Feb 2003 13:02:52 -0800

On Sun, 2003-02-23 at 04:15, Peter Hanappe wrote:
> 
> I started working with doxygen for the documentation, made a Doxyfile
> for the configuration. I'd like doxygen to only analyse the public
> header files but I don't seem to be able to get it running correctly.
> doxygen ignores nearly everything in the headers. Any hint is welcome.
> 

Hmm, it worked fine for me. I just changed to the doc directory and ran
"doxygen". It created an "html" folder with the docs in it. Loading up
index.html, going to "File List" and then clicking on "synth.h" shows
all the routines, with documentation, that are contained in that header.

> 
> > Also I remember one other todo item.. Peter mentioned
> > that the sfloader API could be changed to define the callbacks on a per
> > type basis rather than for each item. That would seem a bit cleaner,
> > although perhaps not absolutely necessary for this release.
> 
> I think that API change should be kept for the development version
> after we released the first version. That changes are to big for the
> current version.
> 
> There are other things I would like to fix (like replace the use of
> iiwu_midi_event_t with the more generic iiwu_event_t). But again, the
> changes are too important for the first release. Oh well.
> 

Yeah, those changes aren't really critical, more cleanup type stuff.
Saving for development version sounds good. I'm starting to think maybe
I should fork off a separate CVS branch for Swami plugins. Otherwise I'm
going to keep running into synchronization problems between FluidSynth
and Swami release schedules (once I change Swami CVS to use new features
in FluidSynth I'm committed to it).

> 
> Bug fixes that don't change the API are no problem. API changes are
> delicate. New features should be avoided.
> 

Sounds good to me.

> Did you get a chance to test the sample and preset callbacks? I'd
> like to now if it's sufficient for you to get started with the sample
> management. It's currently no ideal solution, I know.
> 

I just had a look over it now and started to implement some sample
caching mechanism in Swami. Unfortunately I realized that the older
Swami GTK1.2 branch (the one currently functioning but that I have
ceased development on) is lacking in ref counting for sample store
objects. So I will be adding this functionality to the swami-1-0
development branch instead (I don't like working on the older branch
anymore).

It looks like I will be able to do what I wanted with the additional API
callbacks. I did have a few questions about it though:

1. I'm assuming it is my responsibility to free the iiwu_sample_t
structure after receiving a notify? (with the option of caching it for
future voices).

2. Also I was curious as to what happens after a iiwu_sample_t notify is
received. Is it guaranteed that the synth won't use the same
iiwu_sample_t again (unless I hand it back for another voice) ?  I'm
pretty sure thats the case, just wanted to see if I got it right.

> 
> Cheers,
> Peter
> 

Do let me know if there is something I can help with in getting
FluidSynth ready for release. I have pleanty of free time. Cheers.
        Josh





reply via email to

[Prev in Thread] Current Thread [Next in Thread]