fluid-dev
[Top][All Lists]
Advanced

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

Re: [fluid-dev] 1.1.0 release TODO and commit status


From: josh
Subject: Re: [fluid-dev] 1.1.0 release TODO and commit status
Date: Mon, 19 Oct 2009 14:20:55 -0700
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

Hey David,

Quoting David Henningsson <address@hidden>:
address@hidden wrote:
Here is my current FluidSynth TODO list for 1.1.0:
- Fix documentation issues (private files in files list, missing docs)
- Add new functions in fluid_synth.c to public headers.
- fluid_sequencer_process() relative time?
- Revert to incremental instrument selection per channel
- Update FluidSynth man page
- Change yes/no settings to boolean options with yes/no string compatibility code.
- Have shell "help" command default to "help help" to list help topics.

Let me know if there is anything I have missed.

Before I once again forget to say it; I think config.h.in should be
removed and ignored from svn, we keep checking it in just because we
have different toolchain versions.



Sounds good.  I'll do that.


David: What do you think about converting fluid_sequencer_process() to use relative time instead of absolute? Would there be any reason to move backwards in time?

No, not really, it's made that way out of simplicity. If you change it
I assume you're going to need to keep an extra variable somehow - it is
called both from seq.c and seqbind.c, from both sample and system
timers, which work the same way.



Ahh, on closer look, I see what you mean (timer callbacks are passed total time since start).


And a lot of other things will probably stop working after 49 days (e g
fluid_timer) so I don't really think it is important (but if we want to
fix it in the future, an easy way out is to make it a long long).



I don't know of anyone using FluidSynth where it would need to run for 48+ days, but.. Lets just leave it the way it is now, we can always add a new function in the future which takes a 64 bit long long, as you suggested. We could then run FluidSynth for ~585 million years ;)


Ebrahim mentioned that he preferred the previous default instrument assignment, which was incremental program numbers for each channel.

It annoyed me, so I changed it. Besides being more GM compliant, there
are several piano midi files out there that lack program change
messages, and they now sound correct.

This is nice for just testing out different instruments at high speed, by just switching channels.

Hmm...why would it be easier to switch channels than to switch programs?

When we add real GM support, the instruments can be reset to Piano for all channels when GM mode is entered. It might be good to keep backwards compatibility with previous versions of FluidSynth in this regard.

It's a point in having backwards compatibility, but I think it is more
important to have it consistent with the GM standard in this case.



Sounds good to me.  Lets just leave it then as it is now.


Most boolean setting options in FluidSynth are currently string values with yes/no options. This seems semi inconsistent and messy, since there is at least 1 boolean parameter which is an integer 0/1 with a TOGGLE hint. I'm tempted to turn all boolean options into integer ones, but still allow for string assignment of yes/no (maybe even true/false). This would likely be transparent to most programs.

I have also been thinking about something similar.



Ok, I'll fix this. Seems like now is a good time to do this, it being a new 1.x point release.


// David


Josh





reply via email to

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