Re: [fluid-dev] Patch for fast midi file rendering

[Josh Green]

On Sat, 2009-04-25 at 23:04 +0200, David Henningsson wrote:
> Josh Green skrev:
> > On Mon, 2009-04-20 at 22:08 +0200, David Henningsson wrote:
> >>> I like the use of '-' to indicate stdout.  That is common to many
> >>> applications and would save the user from accidentally getting a
> >>> terminal full of seemingly endless junk.
> >> Seems like a good idea. Hopefully noone wants to create a file named "-"?
> > Then they can do:
> > fluidsynth my.sf2 my.mid -F - >'-'
> 
> Would it be confusing to make -F have an optional argument? It seems
> like getopt supports it. (What we don't want is that a person's precious
> midi file gets overwritten, but I don't know if making it optional makes
> any difference in that context.)
> 


I think just using '-' would probably be fine for stdout.  Or perhaps
I'm not understanding what the issue is, that you are trying to resolve.


> > I think some applications have a way around that (an extra switch or
> > something), but who wants a file called -?  Maybe -.wav or -.au ;)
> 
> Are you talking about when we're starting to depend on libsndfile now?
> 


Yeah.  Which would require the ability to specify the format of the
file, etc.  We don't need to think about that immediately though.
libsndfile (or libaudiofile for that matter) could just be an optional
dependency.  Although, I can see how most users would want the audio to
be a .wav or something more friendly like that.


> > One thing I think would be good to add to the renderer API is a public
> > function for calling a callback instead of using a file handle.
> 
> Are you talking about the output from libsndfile? Otherwise that would
> be the same as just calling fluid_synth_write_s16?
> 


That is true.


> // David
> 

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Timing revisited

[Josh Green]

On Sat, 2009-04-25 at 21:30 +0200, David Henningsson wrote:
> About the buffer, first I think it should be an additional component
> between the "producer" and the synth. We don't want to introduce the
> overhead of thread safety when we don't need it, e g when using fast
> midi-file rendering or in some embedded cases.
> 
> Second, I was thinking perhaps this buffer is the sequencer? A sequencer
> is really just a buffer with the additional feature of delaying an event
> (which can come in handy if we want a really stable midi file player in
> combination with low latency).
> 


Indeed that does make sense that the circular buffer is the sequencer.
It starts getting more complex when events are removed in non FIFO
order.  Rather then re-invent something that is already out there,
perhaps we should do some research on how other projects have tackled
this.


> > It would be nice to start using glib for some basic things, like data
> > types, hash tables, etc.  Cleaning up main could also be refreshing :)
> > Perhaps I'll get inspired to tackle some of that.  
> 
> That would be nice. I have not used glib but it seems to come in handy.
> For Linux I assume depending on glib would not be a problem, but will
> there be problems on other ports?
> 


glib is available for just about any Unix system (Linux, BSDs, Mac OS X,
etc), Windows and apparently OS/2.  It does add an additional dependency
of course, which would need to be provided, either packaged with
FluidSynth or otherwise.  For the sake of cleaner and more portable
code, I think it is worth it.

I'm thinking of dropping the Mac OS 9 support in FluidSynth.  If anyone
objects, you better speak up!


> > Hows it coming along with committing your patches?  
> 
> I've committed three patches so far:
> 
> #172 - Fix bank selection logic, as reported by D Bartolec
> 
> #173 - Fixed sample rate warning message. There should have been a
> warning from the compiler about this I think, perhaps we should look
> into that to avoid similar errors in the future?
> 
> #177 - Sample timers and fast MIDI-file rendering (fixes ticket #15)
> I've been hesitating about committing that patch since it breaks
> Bernat's thoughts about FluidSynth's future...? Anyway, it's there now,
> hopefully we can work on "perfecting" it.
> 


I believe Bernat has decided to hold off on 2.x branch for now, at least
that is what I gathered from his communications.  1.1.0 is a chance to
add some new features and API, mark older stuff as deprecated and keep
API compatibility at the same time.


> > How sensitive do you think your patch is to changes?
> 
> Neither my patch or I will take any offense if you change it to the
> better ;-)
> 


Actually I was referring to whether it would be harder to apply your
patch if I started changing other things.  I'm sure your patch is
already perfect ;)


> // David
> 

Regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Timing revisited

[Josh Green]

On Sat, 2009-04-25 at 10:18 +0200, David Henningsson wrote:
> > On Mon, 2009-04-20 at 20:59 +0200, David Henningsson wrote:
> >> But I've recently come to think of a disadvantage as well. If we're 
> >> low-latency, it's important that fluid_synth_one_block finishes as soon as 
> >> possible. If we do more things, we risc a buffer underrun if one of these 
> >> calls take unexpectedly long time (e g when the player loads another midi 
> >> file). This brings me into thinking...
> > Ohh, I get it now.  So the callback in that case would be running 
> > synchronously.  That could indeed be a problem, as you mention.  Any 
> > operating system calls can block for unspecified amounts of time (malloc, 
> > fopen, etc) and should be avoided in the audio synthesis thread.
> 
> We're very far from a hard real-time system. We cannot protect ourselves
> from anyone trying to send one million midi events at the same point in
> time, which will lead to buffer underrun anyway. So this is just about
> lowering the possibility a bit. (And instead of buffer underruns we get
> untimed data, which is not a good either, but perhaps better than an
> underrun.)
> 

If the system is being overloaded from MIDI events, it probably doesn't
matter how those events are arriving to the synthesis process, assuming
the method by which they arrive is efficient, since it means the CPU is
being consumed regardless of how you try to handle it.  If the synthesis
process itself is starving the MIDI thread, that is also a nice side
effect (throttle the MIDI which is causing the excessive CPU usage ;)  I
was referring to the poor latency effects that operating system calls
can have on even high priority threads, though.

> >> > What about using some sort of
> >> > message queue to pass the MIDI events to the synth?
> >> ...well, something like that.
> >> > I imagine it is
> >> > probably good to try and avoid locks if at all possible in the
> >> synthesis
> >> > thread, but perhaps some lock-less mechanism can be used (circular 
> >> > buffer for example) to pass the events.  Does this make sense?  glib
> >> has
> >> > portable atomic integers which could be used for this task.
> >> I don't know if the overhead of using atomic integers (compared to 
> >> ordinary non-thread-safe integers), perhaps we should have a parameter in 
> >> the synth that sets it in either "thread-safe" or "non-thread-safe" mode. 
> >> In the fast-file-rendering case, there is just one thread and a callback 
> >> to the player is done after every FluidBuffer samples. (pasted from 
> >> another thread, I think it belongs here)
> > 
> > On single 32 bit CPU systems I think generally all 32 bit integers are 
> > atomic, when simply reading/writing them.  Its when you have multiple CPUs 
> > that they may not be atomic.  Memory barrier tricks and other assembly 
> > instructions are used for specific architectures to provide additional 
> > atomic operations (add/sub/test, etc).  
> >These instructions are generally very fast, compared to the alternative of 
> >using mutexes, especially in the case where contention occurs.
> 
> That seems reasonable although I'm a bit curious about the overhead
> compared to ordinary non-safe integers. Do atomic operations block other
> CPUs and manipulate their caches, and what performance hit will that be
> for the other processors?
> 

Atomic integer operations can indeed cause additional instruction
cycles, due to memory barriers, etc.  That is likely fairly minimal, but
I admit I'm not sure how bad of a hit caching or other operations might
take, because of it.  I've just generally assumed that atomic integers
are much more efficient to the alternative of mutexes and relieves you
from the possibility of a higher priority thread getting blocked by a
lower priority one, which is one of the most important reasons.

> > If you have a queue with one consumer and one producer, then you can simply 
> > use an atomic integer to atomically add/subtract how many bytes are in the 
> > buffer and the head and tail of the circular buffer are only accessed by 
> > one or the other thread.
> 
> We will probably have more than one producer? If somebody plays MIDI on
> his/her keyboard while another thread is a midi file player.


Yeah, that is true.  I hadn't really considered that.  I wonder if
having multiple circular buffers for each producer would make sense
though.  I imagine there could be better ways to deal with this, but
that could be one of them.


> >> The former. It seems to me that either fluid_synth_one_block should not be 
> >> called at the same time from one thread at the same time as another thread 
> >> calls fluid_synth_handle_midi_event and friends. So either we have 
> >> concurrency issues, or I'm overlooking a smart and undocumented locking 
> >> mechanism. (synth->busy seems to prevent some things but not
> all
> >> of them? And commented out in some places?)
> > I wouldn't be surprised if there are threading issues, so what

Re: [fluid-dev] License trouble for Debian

[Josh Green]

On Wed, 2009-04-22 at 21:30 +0200, David Henningsson wrote:
> Josh Green skrev:
> > Any suggestion on what licenses are most
> > appropriate for documentation?
> 
> That's seems to be a difficult question. I tried to do some research and
> currently it seems like Creative Commons Share-Alike v3.0 is the most
> bright shining star:
> 
> * It's accepted by Debian
> 
> * Wikipedia is planning to change to that license, and FSF has accepted
> that the license will be used as a successor to GFDL (at least for
> wikipedia?).
> 
> But I'm really not an expert on that subject.
> 
> // David
> 

Guess I was repeating the question in that previous email I wrote.  I
should read my email backwards ;)  I think CC SA 3.0 sounds good to me.

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Documentation

[Josh Green]

On Mon, 2009-04-20 at 23:38 +0200, Pedro Lopez-Cabanillas wrote:
> Hi,
> 
> I've committed some changes to the developer documentation:
> http://fluidsynth.resonance.org/trac/changeset/176
> 
> There is a new document source "fluidsynth-v11-devdoc.txt" formatted for 
> Doxygen, and an updated Doxyfile specifications to process this new file 
> along with the library headers and sources. The resulting documentation is a 
> bundle of the function references with a main page based on the old docbook 
> document "fluidsynth-v10-devdoc.xml", with some additions taken from another 
> document found at http://www.toncat.de/fluidsynth/ and some more text by 
> myself.
> 
> I've changed the format from the original docbook XML format, because the 
> source comments are already written for Doxygen, and having the guide with 
> (automatic) links to the functions references is very handy.
> 
> I guess we should change the license. Not sure if going to LGPL, or GFDL. 
> This 
> is possible IMHO, because CC-by is not copyleft/viric, allowing a derivative 
> work (like this) to be relicensed with only a few conditions (retain 
> attribution, remove names upon request)
> 
> This is only a just started work. Fixes, additions and a revision of 
> undocumented/poor documented functions is expected during the 1.1.x 
> development.
> 
> Please, comments?
> 
> Regards,
> Pedro
> 

This all sounds great!  I got an email back from Peter Hanappe
confirming that we can change the license to whatever seems appropriate.
I'm not certain what would be the best though.  Any suggestions?

Best regards,
Josh Green





___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Patch for fast midi file rendering

[Josh Green]

On Mon, 2009-04-20 at 22:08 +0200, David Henningsson wrote:
> Josh Green skrev:
> > I agree that render fits the function of what FluidSynth is doing
> > (rendering SoundFont instruments and MIDI files to audio).  I'd just as
> > well do away with the file writer driver, since I don't see a need for
> > live file writing using FluidSynth directly (since you would likely want
> > to hear it as well, which means something like Jack would be better) and
> > other APIs, such as what you are suggesting, would be better suited for
> > faster than realtime rendering.  I suppose there isn't too much harm
> > done by leaving it around though.
> 
> Perhaps if you have a hardware sequencer which the input comes from, and
> you want to output that to a file?
> 

I would still think you would want to be able to monitor the audio that
FluidSynth is producing.  No big deal though, we can leave it for now
and perhaps someone is specifically using it in their software.

> > Hmm, I'm not sure about this one.  The settings seem like a nice way to
> > group options in one place, a registry of sorts.  Its useful to the user
> > and helps prevent the need to modify API function calls.  I can see in
> > that case how period_size could make sense, as it is already there.  The
> > filename on the other hand, seems more specific to the case where the
> > renderer is writing to a file (rather than say a user callback
> > function).  I could see that as being a parameter to
> > new_fluid_file_renderer().
> 
> But the file name is already a setting as well. And the word "period
> size" might sound like something more universal that "file name", but
> both of them are only used in the audio drivers. Anyway this is not a
> big deal to me, so if it is a big deal to anyone else, I'm willing to
> adjust :-)
> 

I'm also pretty flexible on this one, in the case of the audio renderer.
Using the settings parameters seems to be consistent.

> > I like the use of '-' to indicate stdout.  That is common to many
> > applications and would save the user from accidentally getting a
> > terminal full of seemingly endless junk.
> 
> Seems like a good idea. Hopefully noone wants to create a file named "-"?
> 

Then they can do:
fluidsynth my.sf2 my.mid -F - >'-'

I think some applications have a way around that (an extra switch or
something), but who wants a file called -?  Maybe -.wav or -.au ;)

> // David
> 

One thing I think would be good to add to the renderer API is a public
function for calling a callback instead of using a file handle.

Best regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Timing revisited

[Josh Green]

On Mon, 2009-04-20 at 20:59 +0200, David Henningsson wrote:
> The callback I'm talking about is mainly the same thing as the as the
> sample timer, i e the possibility to receive notification before/after
> fluid_synth_one_block, and from the "audio thread" (or more correctly -
> whatever thread who calls fluid_synth_one_block). This has the advantage
> that the call will be synchronized, so there are no race conditions
> between the "audio thread" and some other thread (simply because there
> is no need for another thread at all).
> 
> But I've recently come to think of a disadvantage as well. If we're
> low-latency, it's important that fluid_synth_one_block finishes as soon
> as possible. If we do more things, we risc a buffer underrun if one of
> these calls take unexpectedly long time (e g when the player loads
> another midi file). This brings me into thinking...
> 


Ohh, I get it now.  So the callback in that case would be running
synchronously.  That could indeed be a problem, as you mention.  Any
operating system calls can block for unspecified amounts of time
(malloc, fopen, etc) and should be avoided in the audio synthesis
thread.


> > What about using some sort of
> > message queue to pass the MIDI events to the synth?  
> 
> ...well, something like that.
> 
> > I imagine it is
> > probably good to try and avoid locks if at all possible in the synthesis
> > thread, but perhaps some lock-less mechanism can be used (circular
> > buffer for example) to pass the events.  Does this make sense?  glib has
> > portable atomic integers which could be used for this task.
> 
> I don't know if the overhead of using atomic integers (compared to
> ordinary non-thread-safe integers), perhaps we should have a parameter
> in the synth that sets it in either "thread-safe" or "non-thread-safe"
> mode. In the fast-file-rendering case, there is just one thread and a
> callback to the player is done after every FluidBuffer samples.
> 
> (pasted from another thread, I think it belongs here)
> 

On single 32 bit CPU systems I think generally all 32 bit integers are
atomic, when simply reading/writing them.  Its when you have multiple
CPUs that they may not be atomic.  Memory barrier tricks and other
assembly instructions are used for specific architectures to provide
additional atomic operations (add/sub/test, etc).  These instructions
are generally very fast, compared to the alternative of using mutexes,
especially in the case where contention occurs.

If you have a queue with one consumer and one producer, then you can
simply use an atomic integer to atomically add/subtract how many bytes
are in the buffer and the head and tail of the circular buffer are only
accessed by one or the other thread.

The advantage of this scheme, is that the synthesis thread would never
get blocked by a lower priority thread, which could be the case when
using a mutex and lock contention occurs.

I'm kind of surprised that glib doesn't already have a lockless circular
queue data type, since it has everything else needed to create such a
thing.  Perhaps that would be something to contribute back to glib!

> >> As stated earlier, we disagree on this. I can see the use for having
> >> other timers than the sample timer (especially after having read
> >> about the ALSA sequencer), but if the wall clock implementation has
> >> concurrency problems, it's broken. To fix that, it would be better to
> >> use the sample timer feature in the synth just to get notification at
> >> the right time, but then try to figure out a better value for the
> >> msec parameter.
> > When you refer to the concurrency issues with the FluidSynth sequencer
> > and synth, are you referring to an existing multi-threading issue
> > which could cause
> > a crash or unexpected behavior due to a lack of a mutex or are you
> > referring to the limitation that MIDI events can only be processed
> > every FluidSynth buffer size?
> 
> The former. It seems to me that either fluid_synth_one_block should not
> be called at the same time from one thread at the same time as another
> thread calls fluid_synth_handle_midi_event and friends. So either we
> have concurrency issues, or I'm overlooking a smart and undocumented
> locking mechanism. (synth->busy seems to prevent some things but not all
> of them? And commented out in some places?)
> 
> // David


I wouldn't be surprised if there are threading issues, so what you have
found is likely a valid issue.  I have also suspected such issues could
exist, since there doesn't seem to be much regard for locking sensitive
data or anything of the sort.  This could lead to synthesis issues (if
multiple synthesis parameters are dependent or on multi-CPU systems) or
worse case would be crashes.

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] midi player issues

[Josh Green]

On Mon, 2009-04-20 at 19:13 +0200, Pedro Lopez-Cabanillas wrote:
> I would create a third bug report. Maybe a request for enhancement, because 
> it 
> seems that the player would need a new function to handle position set/reset. 
> I guess that the notes can be muted by the client program using 
> fluid_synth_system_reset(). This same function call can be added 
> before/inside fluid_player_play().
> 
> I would like to add several more features to the player for:
> - getting the number of queued songs in the play list.
> - set the current song to a given index.
> - delete one song from the play list.
> - loop mode (off, only one song, the whole queue, ... ).
> - add the player functions to the commands interface.
> 
> Comments?
> 
> Regards,
> Pedro
> 

Those sound like good ideas to me!  One thing we need to start getting
in order is the API documentation.  I had started going through all the
public functions and adding Doxygen documentation to them, but never
finished that.  As we add new features, we need to mark the version when
they were added, so users of the API can know what their software will
require.

This shouldn't stop us from coding new stuff of course, but it is
sometimes a lot easier to add documentation as code is added, rather
than doing it later.

I was going to add a ticket for documentation, but see that you beat me
to it!

Regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Timing revisited

[Josh Green]

On Fri, 2009-04-10 at 15:09 +0200, David Henningsson wrote:
> What first was a quick fix that took an hour or two to write, expanded
> to fix ticket #15, and should also be expanded to fix the sequencer. And
> now I'm about to suggest that timing should be a separate
> component/subsystem.
> 
> First some history (from someone who has only been around the project a
> month!). Fluidsynth's was initially designed for live playing only but
> it's real strength - and where it is most used - is as a rendering
> library, you put midi & sf2 in, you get audio out. The synth component
> is working as a rendering library, and with my patches we have a MIDI
> player and a file renderer component that also works in the rendering
> library context.
> 
> As a rendering library, there is almost no use for anything else than
> sample timers. But for live, real-time playing usage, there are needs
> for synchronization with other things, wall clock, midi clock, and
> perhaps other timing sources. Now the existing wall clock timer
> implementation (or its interaction with other components) has at least
> two serious flaws, 1) it has concurrency problems and 2) it works bad
> with large audio period sizes.
> 
> To solve the concurrency issue, we must not input MIDI to the synth
> during fluid_synth_one_block, only between. A callback from the synth to
> the "timing component" before or after fluid_synth_one_block serves two
> purposes, 1) it says that now it's ok to input some more MIDI, 2) it
> says that the sample timer has advanced. The timing component can then
> call registered players/sequencers to tell them to input MIDI.
> If this is a rendering library, nothing else is needed. But for
> real-time playing, the timing component must resynchronize with the wall
> clock (or something else). This can be done rather easily. If the wall
> clock has a triggered event every second, we correct the elapsed time
> every second, but we use the sample timers inbetween for millisecond
> precision.
> 
> Assuming you agree that this is a good idea, should such a timing
> component be scheduled for 1.1.0 or should it be in the 2.0 branch?
> 
> // David
> 

Hello David,

I personally think that the timing issues should be sorted out in the
1.x branch.

As for using a callback for resolving the concurrency issues.  That
sounds to me like you may still end up with race conditions, it would
just make them less likely to happen.  What about using some sort of
message queue to pass the MIDI events to the synth?  I imagine it is
probably good to try and avoid locks if at all possible in the synthesis
thread, but perhaps some lock-less mechanism can be used (circular
buffer for example) to pass the events.  Does this make sense?  glib has
portable atomic integers which could be used for this task.

I'm not sure how to resolve the issue with driver buffer sizes and MIDI
timing precision in the real time case.  It seems like we may just have
to be content with the MIDI events being processed at the audio driver's
buffer size for now.  If the user can get their audio buffer size low
enough though, then the problem goes away, which is what someone would
want anyways for the realtime scenario.  For the non realtime case, the
sequencer API could be used, though it sounds like it needs some work.

I'm still not as informed as I'd like to be with the actual code and
issues involved, so please let me know if there are faults in my
thinking.

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Fluidsynth on 64-bit Linux

[Josh Green]

On Sat, 2009-04-04 at 16:59 -0400, Ebrahim Mayat wrote:
> Hello
> 
> To 64-bit Debian users, I am forwarding this message that I received
> off-list. It would be appreciated if anybody could assist/test on 
> 64-bit Linux.
> 
> The latest svn (r168) has a persistent make error, when
> compiling from source.
> 
> On 64studio 64bit:
> 
> Compiles ok, with Jack recognised as present.
> 
> Make goes wrong with: " /bin/sed: Can't
> read /usr/lib64/libjack.la: No such file or directory."
> "libtool: link: '/usr/lib64/libjack.la' is not a valid libtool
> archive."
> 
> Any clues?
> 
> Alex.
> 
> p.s. I can add fluidsynth 0.8.2 from synaptic for 64studio
> 64bit, so i still have a usable version. I've only D/L and
> compiled from SVN as a test to report back to you Fluidsynth
> devs.
> 
> It would be interesting how fluidsynth could perform with huge
> soundfonts (> 4 GB of RAM).
> 
> E

Did you ever figure out what was going on with this issue?  A lot of
times I find that build issues on the Mac are not isolated to one
project and can find other info on the Internet if I search for the
right error messages.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Preparing for 1.0.9 release

[Josh Green]

I like your idea of turning your SoundFont into a collaborative project.
I've thought about this type of thing before, in regards to creating a
SoundFont patch format, using XML which could be used to pass around
changes and merge them.  libInstPatch already has the begging of
serializing SoundFont objects to XML.  Gotta get some other things done
first though.

Best of luck to you in sorting things out with the divorce!

Josh

On Sun, 2009-04-19 at 23:55 -0500, S. Christian Collins wrote:
> When I get the time, I intend to turn GeneralUser GS into an
> open-source project (never created one before, so we'll see how it
> goes).  Right now I'm going through a divorce, so it might be a bit
> before I get around to it, though.
> 
> -~Chris
> 
> Josh Green wrote: 
> > On Mon, 2009-03-16 at 09:48 -0400, Ebrahim Mayat wrote:
> >   
> > > Josh, Pedro and Bernat
> > > 
> > > As a service to Linux users, I propose that the 'GeneralUser GS
> > > FluidSynth v1.43.rgd" file written by S Christian Collins be made
> > > available as part of the new release distribution. Configuring
> > > rosegarden with this 'studio file' makes rosegarden work seamlessly with
> > > fluidsynth/qsynth when used together with Chris' soundfont:
> > > 'GeneralUser_GS_FluidSynth_v1.43_RC1.sf2 '. 
> > > 
> > > It is also noteworthy to mention that with this setup, MIDI rendering in
> > > rosegarden using fluidsynth worked without any timing errors.
> > > 
> > > Thanks Chris. 
> > > 
> > > E
> > > 
> > > 
> > 
> > Its a little large to be including in the distribution.  Nice GS
> > SoundFont though!  It would be great to put together a separate freely
> > licensed SoundFont package for distributions to use.  That wouldn't
> > necessarily depend on FluidSynth though.
> > 
> > Josh
> > 
> > 
> > 
> > 
> > ___
> > fluid-dev mailing list
> > fluid-dev@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/fluid-dev
> > 
> >   



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Preparing for 1.0.9 release

[Josh Green]

On Mon, 2009-03-16 at 09:48 -0400, Ebrahim Mayat wrote:
> Josh, Pedro and Bernat
> 
> As a service to Linux users, I propose that the 'GeneralUser GS
> FluidSynth v1.43.rgd" file written by S Christian Collins be made
> available as part of the new release distribution. Configuring
> rosegarden with this 'studio file' makes rosegarden work seamlessly with
> fluidsynth/qsynth when used together with Chris' soundfont:
> 'GeneralUser_GS_FluidSynth_v1.43_RC1.sf2 '. 
> 
> It is also noteworthy to mention that with this setup, MIDI rendering in
> rosegarden using fluidsynth worked without any timing errors.
> 
> Thanks Chris. 
> 
> E
> 

Its a little large to be including in the distribution.  Nice GS
SoundFont though!  It would be great to put together a separate freely
licensed SoundFont package for distributions to use.  That wouldn't
necessarily depend on FluidSynth though.

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Patch for fast midi file rendering

[Josh Green]

On Sun, 2009-03-22 at 06:46 +0100, David Henningsson wrote:
> > * fluid_renderer* is another bad name. It is not rendering anything, in the 
> > sense of translation, like the verb used in "rendering SVG into bitmap 
> > graphics". The proposed functions are only audio file helpers, because you 
> > don't include the MIDI player into the scope. 
> 
> It's the synth that renders MIDI into samples, and the file_renderer is
> a wrapper around the synth for doing just that, and then to write it to
> a file. But I'm open for better suggestions.
> 


I agree that render fits the function of what FluidSynth is doing
(rendering SoundFont instruments and MIDI files to audio).  I'd just as
well do away with the file writer driver, since I don't see a need for
live file writing using FluidSynth directly (since you would likely want
to hear it as well, which means something like Jack would be better) and
other APIs, such as what you are suggesting, would be better suited for
faster than realtime rendering.  I suppose there isn't too much harm
done by leaving it around though.


> > * new_fluid_file_renderer() has a parameter "period_size", that is 
> > available 
> > as a setting. Instead, I would prefer to read synth->setting inside this 
> > function. You may have access here to "fluid_synth.h" :-)
> 
> I guess that's a matter of taste. But for the sake of consistency, the
> filename should be read from the settings then as well.
> 


Hmm, I'm not sure about this one.  The settings seem like a nice way to
group options in one place, a registry of sorts.  Its useful to the user
and helps prevent the need to modify API function calls.  I can see in
that case how period_size could make sense, as it is already there.  The
filename on the other hand, seems more specific to the case where the
renderer is writing to a file (rather than say a user callback
function).  I could see that as being a parameter to
new_fluid_file_renderer().


> > * The raw audio format is not very useful by itself, but can be converted 
> > to 
> > anything else, for instance to mp3 with lame. It would be nice to send the 
> > output to stdout if the file name is not specified, so the output of FS can 
> >  
> > be piped to lame.
> 
> I'm not sure if that would work? If you call "fluidsynth -F mybank.sf2
> myfile.mid", it would assume that you want to output to mybank.sf2. So I
> guess we'll have to stick to the somewhat messier "fluidsynth -F
> /dev/stdout mybank.sf2 myfile.mid" if you want to pipe it further.
> 


I like the use of '-' to indicate stdout.  That is common to many
applications and would save the user from accidentally getting a
terminal full of seemingly endless junk.


> We must also make sure that fluidsynth does not make any noise on
> stdout, but I don't know if that is a problem.
> 

>From what I can see in src/fluid_sys.c the FLUID_LOG stuff logs to
stdout on WIN32 systems and stderr on others.  We could consider any
logging to stdout a bug and fix accordingly, if the stdout becomes used
for audio rendering through a pipe (a nice feature!).

> Anyway, if we have any good examples for rendering to wave/mp3/ogg/etc,
> that could be written in the man page.
> 
> > * "fluid_seq.c" should be converted to this timer, as discussed recently.
> 
> Agreed, but I don't have a test environment for the sequencer here.
> Either we leave this up to Antoine or I'll have to install a test
> environment somehow. Anyway I prefer to have it in a separate patch.
> 
> // David
> 

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Cutoff Frequency Effect

[Josh Green]

On Wed, 2009-03-25 at 07:49 +0200, Graham Goode wrote:
> Hi,
> Is there a cutoff frequency effect in Fluidsynth like the TVF Cutoff
> Frequency effect in Creative Cards where you set up the NRPN
> controller with:
>   176,99,1
>   176,98,32
> and then send CC 6 to apply the cutoff filter, like so:
>   176,6,xxx
> where the xxx value ranges from 0-127?
> Regards,
> GrahamG
> 

Hello Graham,

FluidSynth should respond to SoundFont NRPN messages as described in
section "9.6.2 The NRPN Select Values" of the SoundFont 2.4 PDF
specification:
http://freepats.opensrc.org/sf2/sfspec24.pdf

One example shows that by sending NRPN MSB of 120 followed by LSB of 8,
will control the Low Pass filter cutoff.  The data value is passed as a
14 bit offset value, 0x2000 (8192) being the mid point (offset value of
0), 0 being -8192 and 0x3FFF (16383) being +8191.  This value offsets
the current effect value by the native SoundFont units for the selected
parameter.

You could also edit the SoundFont and add a modulator attached to a MIDI
Custom Controller.

Best regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] midi player issues

[Josh Green]

On Thu, 2009-04-02 at 23:07 +0200, Pedro Lopez-Cabanillas wrote:
> Felix Krause wrote:
> > Hi all,
> >
> > I'm using the fluidsynth library (current unstable Mac version from
> > fink) and tested the midi file player. It behaves very strange:
> >
> > - fluid_player_set_loop doesn't seem to have any effect (I tried to
> > set loop to 1, 5, negative values...).
> > - fluid_player_set_bpm seems to set the bpm always to 0, no matter
> > what bpm value I'm calling it with. This results in the first chord of
> > the midi file being played forever. My application hangs if I call
> > delete_fluid_player or fluid_player_join afterwards.
> > - fluid_player_set_midi_tempo shows the same behaviour.
> 
> For reference. The units in fluid_player_set_bpm() are beats per minute. In  
> fluid_player_set_midi_tempo() the argument is given in microseconds per beat. 
> The default values are BPM = 125, MIDI tempo = 48. There may be a bug in 
> the last function, where it calculates the deltatime value in milliseconds 
> per tick, using the player->division value assigned from the loaded SMF 
> header (division field). Can you compile FluidSynth in debug mode, and take a 
> look to the log output?
> 
> > - fludi_player_stop stops the midi player, but doesn't mute the
> > currently playing notes. If I call fluid_player_start afterwards, the
> > player doesn't output anything for exactly the amount of time it had
> > played my file until I called stop. Then, it continues playing the
> > file from the position I stopped it.
> >
> > Is this a bug? Or am I simply doing something awfully wrong?
> 
> As David said, you've found several unimplemented and/or broken functions. 
> Please, can you create tickets into the bug tracker?
> http://fluidsynth.resonance.org/trac/report
> 
> Regards,
> Pedro
> 

Since Felix hasn't responded and tickets haven't yet been added, I went
ahead and added 2 new tickets:
http://fluidsynth.resonance.org/trac/ticket/33
http://fluidsynth.resonance.org/trac/ticket/34

Not sure how to handle the fluid_player_stop issue.

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Fix for problem with CC changes to Bank MSB

[Josh Green]

On Sun, 2009-04-05 at 00:07 +1100, D.Bartolec wrote:
>  
> I've discovered it after playing some MIDI files that would send bank
> LSB:0 for drum channel without sending bank MSB at all.
> This would cause drum tracks to change to MSB:0 LSB:0. 
> Here is the fix:
>  

Its likely those MIDI files are assuming GM which has no concept of
banks to begin with.  As I mentioned in another email, FluidSynth should
probably try and be smarter about what mode it is in, with the ability
for the user to explicitly change it.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Fix for problem with CC changes to Bank MSB

[Josh Green]

On Sun, 2009-04-05 at 08:08 +0200, David Henningsson wrote:
> D.Bartolec skrev:
> > I've discovered it after playing some MIDI files that would send bank LSB:0 
> > for drum channel without sending bank MSB at all.
> > This would cause drum tracks to change to MSB:0 LSB:0. 
> 
> I've taken a quick look at your patch now and I have a question:
> 
> > +  if ( (chan == 9) && (bank_msb == 0))
> > +  {  
> > +   bank_msb = 1; /* Ignore CC value and set the default MSB value for drum 
> > channel */
> > +  }
> 
> Is this part really necessary, and does it disable a previous
> possibility to assign a regular instrument to the drum channel?
> 
> Otherwise I think it makes sense - LSB setting does not affect MSB
> setting, and the other way around.
> 
> A question to the audience: Why do we have variables for banknum and
> prognum in fluid_channel_t, when they can be read from (and written to)
> the CC array?
> 


Not sure if anyone but Peter Hanappe could answer that question.


> // David
> 

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [Fwd: [fluid-dev] Midi standards (was: Fix for problem with CC changes to Bank MSB)]

[Josh Green]

On Sun, 2009-04-05 at 11:14 +0200, David Henningsson wrote:
> David Henningsson skrev:
> > Otherwise I think it makes sense - LSB setting does not affect MSB
> > setting, and the other way around.
> > 
> > A question to the audience: Why do we have variables for banknum and
> > prognum in fluid_channel_t, when they can be read from (and written to)
> > the CC array?
> 
> First; forget about the prognum - it is not a CC. The question is still
> valid for banknum though.
> 
> I've tried to dig a bit deeper here. It is hard to find free standards
> on the net (has anybody bought a copy from midi.org?), but I found the
> XG standard here:
> 
> http://web.archive.org/web/20060926124939/http://www.yamaha.co.uk/xg/reading/pdf/xg_spec.pdf
> 
> The first question is: What do we really support? GM? GM2? GS? XG? For
> XG, the drum kit bank is 127, not 1.
> 
> There is also some information in this document which I think should
> apply to us regardless, especially the default values of controllers. E
> g the default volume for each channel should be 100 by default, not 127
> as set in fluid_channel_init_ctrl.
> 
> // David
> 
> 

I think it would be ideal if FluidSynth could detect what mode it is
supposed to be in via SYSEX data as well as be explicitly put into a
certain mode via API calls.  This was discussed a little before on the
list in response to some of Jimmy's previous posts about bank/program
selection fallback.

The SoundFont standard itself designates bank 128 as the percussion bank
(section 7.2 about the PHDR chunk).  SoundFont files are generally
designed for a specific standard.  But the MIDI mode determines
bank/program selection behavior, controllers etc.  I'm not sure how far
we would want to go in providing the ability for users to use a XG bank
in place of another standard for example.  But many of those standards
build on at least GM.

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] FluidSynth sequencer test

[Josh Green]

Hello David,

On Sat, 2009-04-04 at 20:55 +0200, David Henningsson wrote:
> Pedro Lopez-Cabanillas skrev:
> > David Henningsson wrote:
> >> Pedro Lopez-Cabanillas skrev:
> 
> > It is something that only Josh can 
> > do, and he is not answering mails right now.
> 
> That is a problem.
> 


By all means, commit your patch :)  Let me know if you have any trouble
doing so.  It sounds like the right solution to me and we can iron any
issues out as they come up.


> >>> I also would like to test an
> >>> additional approach, overhauling the current wall clock implementation.
> >> Okay, can you elaborate on what changes that would be and if/how they
> >> will work with faster-than-realtime rendering?
> > 
> > Faster than realtime has no sense for the sequencer. It has sense, though, 
> > if 
> > the sequencer is driven by a slave timer, like the one you have 
> > implemented. 
> > This design is already inside (for instance) the ALSA sequencer, which 
> > allows 
> > several timer sources: slave timers linked to the PCM streams, and wall 
> > clock 
> > timers using the RTC, HPET and System devices. There is some documentation 
> > about that: http://www.alsa-project.org/~frank/alsa-sequencer/node5.html
> > 
> > The user should be able to choose between wall clock and slave timer, the 
> > same 
> > option for the sequencer and the MIDI player.
> 
> As stated earlier, we disagree on this. I can see the use for having
> other timers than the sample timer (especially after having read about
> the ALSA sequencer), but if the wall clock implementation has
> concurrency problems, it's broken. To fix that, it would be better to
> use the sample timer feature in the synth just to get notification at
> the right time, but then try to figure out a better value for the msec
> parameter.
> 


Please excuse my lack of knowledge on the current issues.  When you
refer to the concurrency issues with the FluidSynth sequencer and synth,
are you referring to an existing multi-threading issue which could cause
a crash or unexpected behavior due to a lack of a mutex or are you
referring to the limitation that MIDI events can only be processed every
FluidSynth buffer size?

Best regards,

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] License trouble for Debian

[Josh Green]

Hello David and Bernat,

On Sun, 2009-04-19 at 13:28 +0200, Bernat Arlandis i Mañó wrote:
> David Henningsson escrigué:
> >
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524566
> >
> > To get back on topic, I'm not demanding that fluidsynth should be more
> > Debian-friendly in the future, but if we want, we should consider:
> >
> > 1) Removing the files in the sf2 directory. I don't understand why those
> > files are distributed with fluidsynth at all, and IMO they should be
> > removed.
> >
> > 2) Relicense the documentation under a DFSG-compatible license. (IMO:
> > This one is least important, as the documentation is available online
> > anyway.)
> >
> > 3) Add a proper license notice to doc/example.sf2 so we know who made
> > it, and under what terms we can use it.
> >
> > // David
> >
> >   
> You should post the issue url in your first message so we can have all 
> the information right from the start.
> 
> It's easy to fix for your package:
> - The FS repository doesn't need to be DFSG-compatible.
> - Josh could take away the non-compatible files from the source tarball 
> he's done since they're not needed in general distribution and they 
> might invalidate the LGPL license for the whole package.
> - In case he doesn't remove them, it's really easy for you to remove the 
> files from the source tarball for Debian. Ask Debian developers on how 
> to make others aware that you're changing the source tarball.
> 
> Asking your questions in a Debian developers forum first will help you 
> better solve your packaging doubts. They'll tell you when there's 
> something wrong with upstream that you have to ask fixing.
> 

I'm not particularly attached to VintageDreamsWaves-v2.sf2 and think
removing it is fine.  I'm not sure who originally added it to the
project and hadn't realized that it wasn't a more free license.  The
idea was probably to have something small for users to try out easily.
Perhaps some public domain replacement could be found at some point, but
it probably makes more sense just to have a separate package with some
decent GM SoundFont and a few other small ones.  I'll remove the sf2
folder for now.

Not sure where example.sf2 came from either, but it seems to be
referenced by the example.c source code, so my guess is that it was
Peter Hanappe who created that file and the example.sf2.  Looking at it,
its simply a single preset ("El Cheapo Organ") ripped from
VintageDreamsWaves-v2.sf2, which apparently breaks the license of that
SoundFont!  Removing.  I don't think it necessarily detracts from the
usefulness of example.c.

Most of the documentation is severely outdated (refers to FluidSynth as
Iiwusynth, etc).

- doc/FluidSynth-LADSPA.pdf - Markus Nentwig wrote this, it could come
in handy when fixing/improving the LADSPA code.  He is available if we
want to ask him if we can put a DFSG compatible license on it.

- doc/fluidsynth-v10-devdoc.xml seems to be Peter Hanappe's work. I can
ask him about this one.

- doc/midi_time.txt is just some memo of Peter Hanappe's, which could
probably just be deleted without anyone noticing.

- doc/xtrafluid.txt looks outdated.  Can Antoine Schmitt comment on
whether it is useful?  If it is useful, do you know who wrote it?


Does that cover everything?  Any suggestion on what licenses are most
appropriate for documentation?

Cheers!
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

[fluid-dev] My absence and misunderstandings

[Josh Green]

Hello FluidSynth list,

As I have mentioned a few times before, I've been rather overwhelmed
with work and what not as of late.  Things have calmed down a bit now
and I have more free time.  During the last month though, I wasn't able
to keep up with FluidSynth email and it began accruing in my inbox.
When I would think about it, it would just make me feel guilty about my
lack of dedication to the project, which just led me to try and avoid it
altogether.  This pattern is rather unproductive and unpleasant and I'm
working to change it.  We are all here volunteering our time and the
last thing we should be feeling is that its just another drudgery or
"work".  In fact we all deserve praise and reward for the time, effort
and enthusiasm we bring the project.

After combing through my emails, I realize the extent of some of the
misunderstandings that occurred.  I want to start be re-iterating that
my 1.1.0 proposal, was just that..  A PROPOSAL.  I do not want to
obsolete or override anyone's efforts if it goes against the project as
a whole.  The primary example of this has been Bernat's work on the 2.0
branch.  I didn't receive his email responding to my proposal:
http://lists.gnu.org/archive/html/fluid-dev/2009-04/msg00062.html

and only read it in the archives after he mentioned to me that I might
be missing some of the conversation.

To summarize my current understanding and thoughts:

- The path to 1.1.0 is going to largely be about learning to work
together, being a newly formed team and all, and figuring out the
development organization of the project.

- Not a whole lot of changes have occurred with the 2.x branch yet,
though that may not accurately reflect the amount of time and
investment.  It seems like there is still some understanding that I am
missing in regards to what Bernat would like to see, as far as the
direction of the project.  Part of this misunderstanding has definitely
been because of my personal change in perspective.  I had originally
thought it would be best to do a more drastic overhaul of FluidSynth
immediately.  My perspective changed largely due to the recent interest
from others in development and the idea that the underlying framework
could be changed without breaking the API and would in turn pave the way
for 2.0 and a new improved API.  I hope we can come to some better
understanding as to how to proceed in a satisfactory manner for all
involved.

- David Henningsson's patch on the MIDI timing issues should be
committed to trunk (1.x) and perfected as needed.

- New patches and bugs should be added to the ticket system in addition
to being posted to the list or risk being overlooked.  We can politely
tell clueless users to create tickets or if we are in a good mood,
create one for them.

- Pedro pointed out that we probably don't need to create a concrete
schedule for development at this point.  Thinking this over, I think
that makes sense.  Thinking in more general terms though, it would be
good to have some sort of idea of when 1.1.0 will be released, as a
goal.  3 months seems good to me (sometime mid/late July).

- Maintaining compatibility with current software is a worthy goal.  As
Jimmy mentioned, a compatibility wrapper could be created for 2.x, when
a new API is developed.



That is my current perspective on project direction.  I would like to
extend an invitation to Bernat in particular, to communicate his
thoughts on his work with 2.x and how we can develop a team strategy to
move forward.  I also encourage others to be a part of this process.

Cheers!
Josh Green

P.S. I'll be catching up on some of the past emails, so expect some
replies to old posts, etc.  Thanks for your understanding!




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

[fluid-dev] 1.1.0 Schedule, Trac permissions, etc

[Josh Green]

To help make things a bit more organized I will set forth a plan for the
1.1.0 development cycle.  This is not set in stone and is open for
input.

Development cycle will be 3 months, which means FluidSynth 1.1.0 will be
released around July 12th.  Feature freeze will occur 2 weeks before.

June 28th: Feature freeze
July 12th: FluidSynth 1.1.0 release

I modified Trac permissions to allow for anonymous users to edit the CC
field of tickets and gave additional permission to authenticated users
and the developers group.  I'm still getting used to Trac and the
permissions likely still need adjusting.  I would like things to be as
open as possible, but minimize the possibility of spam or other abuses.
If you feel there is a particular permission that isn't available to you
and should be, let me know.

The Trac developer group currently consists of myself, Bernat, David and
Pedro.  It currently has the following additional permissions: Milestone
admin, Roadmap admin, Ticket admin, Report admin, Screenshots admin and
Wiki admin.

If you want to be a part of this group, just say so.  Its mainly to
prevent someone from abusing the site, just by registering.

We should start assigning tickets to the 1.1.0 milestone, that we would
like to see included (I've done this for the ones I already suggested
and a few others that seemed rather important).

Also, many of the tickets are assigned to myself.  At the moment, there
is no particular task that I am attached to doing or in the middle of
doing, so if you would like to take over any of the tickets, please
re-assign the ticket to yourself as you wish.

I see that there has been a bit of ticket activity and remember how
someone mentioned that it is difficult to track the comments.  I added
the "Ticket details" feature to the Timeline, which allows you to see
comments, but I was thinking it might be nice to have a subscribe only
ticket mailing list too, would anyone be interested in that?

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] JACK Sample Rate

[Josh Green]

Hello Esben,

Yes indeed, its a problem.  Its on the list for the next release.
Ticket #6 if you want to track it:

http://fluidsynth.resonance.org/trac/ticket/6

Cheers!
Josh

On Wed, 2009-04-15 at 03:03 +0200, Esben Stien wrote:
> Running fluidsynth-1.0.9, which is really nice, thanks;), but it reports: 
> 
> fluidsynth: warning: Jack sample rate mismatch, expect tuning issues 
> (synth.sample-rate=44100, jackd=96000)
> 
> I run with -r 96000 and it's fine, but why don't you just get the
> sample rate from JACK?;).
> 



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Re: The 1.1.0 milestone

[Josh Green]

Hello Jimmy,

On Tue, 2009-04-14 at 15:56 -0700, jimmy wrote:
> It seems we are all looking forward to 2.0, while 1.0 is agreed as legacy 
> code base.
> 
> I don't know how far along the code refactoring (FS 2.0) is.  Can we get a 
> status update, or current functions available.  What's missing compare to 
> 1.0.9?
> 
> It may be better if we put more efforts to work toward the new 2.0 code and 
> get it to a somewhat fully functional equivalence of 1.0.9.  It would be a 
> waste of time to make changes to 1.0 code, only to have to redesign 
> everything because 2.0 won't be compatible at all.
> 
> Sure, the 2.0 code could be using libInstPatch and any other libraries, or 
> features that makes sense.  Let's get a way so folks can checkout the 2.0-dev 
> code first, new patches can be posted here before checked in to the code 
> repository by a couple of main contributors for now.  This way, folks can 
> try, or test out the new patches without checking out half-broken daily 
> updates.
> 
> Anyone who can't live with 1.0.9, and must have the current extra patches, 
> feel free to patch your own code.  Since 1.0.9+ won't be too active.
> 
> Just my thoughts.  If it makes sense, just put in your personal informal vote 
> so by next week we could have enough vote of confidence on where to put most 
> of our efforts next.
> 
> My vote is let's go for 2.0.
> 
> Jimmy
> 

I think I WAS of the same mind, as far as focusing on FluidSynth 2.0.
The question I didn't really ask myself, was how much of the goals I
envisioned with FluidSynth 2.0 could be applied to the 1.x code base and
still remain compatible.  I think the answer to that, is probably "a
lot".  In this sense, working to improve FluidSynth 1.x would not be a
waste of time and would lead towards 2.0.  I think if we just jump
headlong into 2.0, it would be another long development cycle and the
end result would be something that would not be compatible with existing
software.  Much of the work that would be put into improving the
existing FluidSynth code base, would likely directly benefit 2.0
development and therefore we could probably accomplish 2 things at once,
that is, work towards 2.0 AND make additional 1.x releases which have
improved functionality.

Having said that.  I feel it is good to have our sites on what 2.0 will
be.  I think the primary difference between 1.x and 2.0 will be the API.
At the moment I can't think of any other distinction that needs to be
made, although I imagine there will be limitations of the existing API
which mean that certain features and improvements are reserved for 2.0.
Working on 1.1.0 will help us all to identify those areas where the API
should be changed and allow us some time to get accustomed to working
together.

If someone has some examples of features or improvements which can't be
applied to 1.x without CHANGING the API or would be awkward to attempt
(NOTE: API additions are fine), I would like to hear about them.

One example of an area that needs improving, in regards to Swami, is the
SoundFont loader API.  I'm not certain how many other programs use this
portion of the API.  There is a lot of room for improvement on it though
(24 bit/floating point audio support and streaming, better optimized
generator assignment to voices, etc).  This could end up being a new
loader API, with the old one being marked as deprecated.

Thats my current thinking..  What do you guys think?

Best regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] The 1.1.0 milestone

[Josh Green]

Hello David,

On Tue, 2009-04-14 at 18:06 +0200, David Henningsson wrote:
> > With all this big changes and new plans, I'm wondering where does lie
> > the 2.0 branch? I could have done some work these holidays but I have
> > the feeling that we're diverging and I prefer to wait for the water to
> > calm down. Before starting this branch I was like one year reading the
> > list and I knew about the development status of FS, and the Miguel's
> > fork. Nowadays I see people jumping in with his own ideas but without
> > knowing much of what has been talked here lately.
> 
> Being one of the people "jumping in", I don't know much about Miguel's
> fork/branch or the 2.0 branch. That's why I asked for some pointers, so
> I don't have to read an entire year of messages. What I'm looking for
> the answer to is why all of you decided to branch instead of doing code
> cleanup one piece at a time, into the stable branch. I'm sure you had
> good reasons for doing so, I just don't see them.
> 


I think a lot of this confusion has been due to lack of direction.  The
upside of all of it, is that it can help to better define the direction.
I'm beginning to agree with your statement above, that we can do code
cleanup one piece at a time, with the current 1.x and at some point make
a 2.0, when the API itself seems too restrictive.


> > I think I will stop my activity from now on until I see where FS is
> > heading and how. I don't want to spend more time on it until it has a
> > clear route and better organization. Since some things that were planned
> > for 2.0 are now included in the 1.1.0 plan and others are going on a
> > tangent, I think it's time to talk about it all.
> 
> How is the 2.0 branch doing currently? What has been done and what
> remains? Perhaps there are parts that can be merged already?
> 


Fortunately this discussion is happening fairly early in the process and
it was just recently branched.  Bernat has invested some time and
thought into it though, but I hope he can apply that to 1.1.0.


> // David
> 

Best regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] The 1.1.0 milestone

[Josh Green]

Hello Bernat,

On Tue, 2009-04-14 at 11:00 +0200, Bernat Arlandis i Mañó wrote:
> First, I sent this message but it didn't get to my mailbox and it seems 
> to be ignored by everyone so I guess it didn't reach your mailbox 
> neither, I think it's interesting:
> http://lists.gnu.org/archive/html/fluid-dev/2009-04/msg00044.html
> 


I also read it and thought you made some very good points.  I realized
that it wasn't such a big issue as it sounded like at first.  I'll be
sure to answer next time, I guess I took it for granted that what you
said didn't need anything added to it, but I could have at least voiced
my agreement with it.  I still have a little bit of a backlog of
FluidSynth related mail to catch up on, as I haven't had a lot of time
until just a few days ago.


> With all this big changes and new plans, I'm wondering where does lie 
> the 2.0 branch? I could have done some work these holidays but I have 
> the feeling that we're diverging and I prefer to wait for the water to 
> calm down. Before starting this branch I was like one year reading the 
> list and I knew about the development status of FS, and the Miguel's 
> fork. Nowadays I see people jumping in with his own ideas but without 
> knowing much of what has been talked here lately.
> 
> I know everyone's ideas are the best and mine aren't any better unless 
> demonstrated, but I already said the 2.0 branch would take some time and 
> work and doing it alone isn't rewarding. Besides, it might happen that 
> when it's ready no one is interested on it and I end having a fork that 
> I didn't want to start.
> 
> I think I will stop my activity from now on until I see where FS is 
> heading and how. I don't want to spend more time on it until it has a 
> clear route and better organization. Since some things that were planned 
> for 2.0 are now included in the 1.1.0 plan and others are going on a 
> tangent, I think it's time to talk about it all.
> 
> Regards.
> 


I understand your concerns and I think there has indeed been problems
with having good direction and leadership for FluidSynth.  This has been
largely an issue I've been dealing with myself.  Although I feel I have
the potential to be a project leader, I haven't been applying this
ability very well.  Now that there is this recent interest, the last
thing I want to do, is stand in the way of progress and someone's own
process with being a part of the project.

I've been thinking over the 1.1.0 release and the 2.0 branch and how
that fits in.  I think one major thing that FluidSynth has going for it
currently is that many applications are using it.  While the API may
have many issues and be lacking in some areas, there is likely a lot
that can be done underneath, to make things cleaner and an overall
better piece of software, without breaking the API for current
applications.

I think your desire to make a 2.0 branch was born of the desire for the
freedom to innovate and change FluidSynth, without having to think so
much about keeping API compatibility.  FluidSynth could definitely use
innovation.  Its been collecting dust for some time now.  As I am
starting to see things now, the 1.1.0 milestone could be a stepping
stone for 2.0.  So perhaps it is premature at this point, to have a
separate 2.0 branch.

The next release of FluidSynth will largely be a time for us all to come
up to speed on where FluidSynth is, where we want it to go and how to
work as a team to get things done.  It is indeed much less rewarding to
work on something by oneself, without much appreciation for it.  I would
really hate to see that happen.  So it seems more a matter of figuring
out how you can apply what you want to work with on with FluidSynth,
with the 1.1.0 version.  There is plenty to do and I would like to see
you a part of that and the reward it deserves, as much as I myself have
a new desire to be more a part of it.  A lot of the things I have wanted
to do with FluidSynth, have been held back by the necessity to perform
other tasks, that I didn't really want to do.  My hope is that we can
organize things in such a way, where we are each doing what we want to
do and at the same time working cooperatively for the benefit of the
project.

I encourage you to not stop your contributions to FluidSynth and lets
instead discuss what the direction and organization is, as you
suggested.  From that list of proposed items that I sent, I imagine it
was the porting to glib task, that was what we had planned for the 2.0
branch.  I would like to hear more of your thoughts on what you want to
see happen and if and how that could work with the direction of 1.1.0.

Kind regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

[fluid-dev] The 1.1.0 milestone

[Josh Green]

Hello,

Its been really nice reading the introductions..  There are no specific
qualifications on this, so if anyone else feels inspired to introduce
themselves, please do.  I know there are several other people on this
list who have been long time FluidSynth contributors and users.

The next step seems to decide on what the FluidSynth 1.1.0 milestone
should look like.  What features and bug fixes we would like to see.  I
like the idea of releasing every few months (3 months?), to keep things
on track and not make users wait too long for improvements.

Proposals for tickets for 1.1.0:

- Replace some of the more ugly portability code with glib

- Timing related issues and faster than realtime audio rendering (#1,
#24, #15)

- Support dynamic change of sample rate (#6), causes improper tuning if
audio driver rate does not match FluidSynth's rate!

- Improve voice stealing algorithm (#27)

- Audio rendering to .wav or other audio file formats using libsndfile
or libaudiofile (ticket #30)


I also have some test code for doing timing metrics on FluidSynth.  It
would be nice to have a test suite, which could do timing and synthesis
tests.  This will be made much easier when we have improved sample based
MIDI to audio rendering and would help to spot regressions or
improvements in synthesis or performance.

I'd like to hear thoughts from others on what they would like to see in
the next FluidSynth release.  I think we should strive to keep API
compatibility for 1.1.0.  It might be good to deprecate certain more
obscure parts of the FluidSynth API and add additional interfaces where
desirable though.

Cheers.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Introductions and interest in FluidSynth

[Josh Green]

Hello!

Glad to have you on board.  I wonder how many other people have been
lurking on the list without saying anything, despite having interest in
contributing to the project :)

I think the next step at this point, is to decide on what tickets should
be slated for completion by the 1.1.0 milestone.  That will give us all
an idea of what needs to be done and who wants to do what.  I'll save
that for another message.

Cheers!

Josh


On Tue, 2009-04-14 at 10:53 +1000, d...@bartolec.com wrote:
> Hi everyone,
> 
> Here is my introduction.
> 
> My name is Dub Bartolec, and I live and work in Sydney, Australia. I am
> professional programmer in my forties, currently developing software for
> industrial control company.
> 
> Over the last 22 years I've worked for various industries, primarily
> developing real-time software applications for embedded platforms and real
> time operating systems. My specialty is real-time software in cross
> platform, embedded and distributed environments. I use C, C++ on all
> platforms, and C# on Windows so I might help you in this area.
> 
> One of the most challenging and at the same time most memorable periods of
> my career (so far) were years spent developing software for DAWs,
> production and post production equipment at FAIRLIGHT, Australia
> (http://www.fairlightau.com). Most of the synth sounds 80-tih were shaped
> by their sampler. So I have some experience in this field.
> 
> Also, I am part time musician, so naturally my after hours interests
> gravitate towards music and music production.
> 
> I have few software based DXI synths and apart from being easy to run they
> lack flexibility in certain areas, so I went further.
> 
> That's how I stumbled upon fluidsynth. I had a look at it and noticed lots
> of potential. Tweaked it a bit, to try how far it can go and on my way
> noticed and fixed few bugs (I believe that I fixed Ticket #1 in my local
> source base, but we can discuss that some other time).
> 
> I can help you with performance improvements, bug fixing, new
> developments, MIDI handling, testing and so on.
> I have enough equipment, experience and expertise in this area, and where
> don't I'd know who to ask.
> 
> So to conclude, I'd be more than happy to contribute to our project, so
> let me know what the plans are and I'll find some time.
> 
> Regards!
> 
>  Dub Bartolec
>  Sydney, Australia
> 
> 
> 
> 
> ___
> fluid-dev mailing list
> fluid-dev@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/fluid-dev
> 



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

[fluid-dev] Re: Linking with GPL libraries (was: FluidSynth 1.0.9 released)

[Josh Green]

Hello David,

On Mon, 2009-04-13 at 15:21 +0200, David Henningsson wrote:
> > So not sure what that is all about.  Hmm, it just occurred to me.  It is
> > one thing to have your program link with a GPL library and its another
> > to have it in turn link with other programs, perhaps that is the
> > distinction?
> 
> The people we're messing it up for is not ourselves, it's for
> applications which links with libfluidsynth AND are not GPL-compatible
> (contains code released under MPL, a proprietary license etc). Assuming
> Debian links with readline/liblash by default, they must provide their
> own compiled version of libfluidsynth, which does not link with
> readline/liblash.
> 
> Anyway this is a "gotcha" that we should mention somewhere in the
> documentation.
> 


Ok, that makes sense.


> > Does anyone use LASH?  I would miss the readline support, that is for
> > sure.
> 
> As for readline, it could perhaps be replaced with editline, which is
> under BSD license.
> 

Just glancing at editline quickly, it seems like it could indeed be a
replacement.  I would like to resolve these issues, so using editline
seems like it could be a good task to accomplish for the next release.
I suppose another way to resolve the issue would be to not have
libfluidsynth link with libreadline, but be used only by the fluidsynth
command line shell.

> Looking it up in Debian (popcon) shows that:
> 104 people have installed lashd
> 688 people have installed liblash2
> 5790 people have installed libfluidsynth
> 


It seems like something like LASH would most benefit the community by
being LGPL or some other more open license, for the purpose it has.  I
wonder if the author can be persuaded to change it?  Otherwise, perhaps
we should just remove support for it.  It is optional though, so I can't
see particularly why it would be an issue just to leave the possibility
there, but a warning could be printed at ./configure time.


> >> Seems like a very good idea. I could also have use for some pointers to
> >> why it was decided to fork the project into an 2.x branch.
> 
> Sorry about the choice of words here, I meant branch, not fork (even
> though Wikipedia says that branching is a type of forking).
> 
> // David

I guess the distinction between branch and fork, is that a branch tends
to be something that contributes back to the original and visa versa,
where as a fork is more separate.  At least that has been my conception
of the terminology.

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] FluidSynth 1.0.9 released

[Josh Green]

On Mon, 2009-04-13 at 09:45 +0200, David Henningsson wrote: 
> Done. Anything else I should know when it comes to comitting patches?
> 

I don't think we should be too hesitant about committing changes, or at
least not afraid to.  Communication is a good thing and tracking things
with tickets in Trac is also very good.  We'll likely get a better idea
of guidelines as we go along.  I think it is better to be actively
working on things than to get too caught up in some bureaucratic
processes.  If someone breaks something, we can bitch at them
afterwards ;)  When we get closer to our next release though, it would
be good to slow things down into some sort of feature freeze state.

> >> I have also started to work on getting the new 1.0.9 version into Debian
> >> - it was abandoned, so I intend to become the new Debian maintainer for
> >> FluidSynth. It's my first official package so I might have some related
> >> questions for you as well as the Debian mentors.
> > That is great, I didn't realize that the Debian package had been
> > abandoned.  I guess there has been so few releases in the past few
> > years.  Its nice that that is changing.
> 
> I've already run into trouble with the debian package, interested people
> can have a look here:
> 
> http://lists.debian.org/debian-mentors/2009/04/msg00244.html
> 
> Btw, do you know any other GPL code we (optionally) link to, more than
> lash/ladcca?


I hadn't even considered the issue with GPL versus LGPL.  What a mess.

The end of the configure.ac lists other optional packages.  Looking at
the list, it seems readline is also GPL.

I admit being confused now though, since on the readline page it
mentions it is GPL but that you can use it with "GPL Compatible"
licenses.

http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

So not sure what that is all about.  Hmm, it just occurred to me.  It is
one thing to have your program link with a GPL library and its another
to have it in turn link with other programs, perhaps that is the
distinction?

Does anyone use LASH?  I would miss the readline support, that is for
sure.


> > Since there are a number of individuals who have recently become
> > interested in FluidSynth development, I think it would be a good idea to
> > introduce ourselves a bit and mention what interest we have in
> > FluidSynth and how we would like to help out.  I'll post a new email
> > thread to this effect, to get things started.
> 
> Seems like a very good idea. I could also have use for some pointers to
> why it was decided to fork the project into an 2.x branch.
> 

This was suggested by Bernat Arlandis i Mañó and I seconded the idea, or
it could be said that I had also thought branching it would be a good
idea.  Its not a fork, its a branch.  The main reasoning was to port
FluidSynth to glib and potentially clean up the API.  I realize now
though, that porting to glib doesn't necessarily require cleaning up the
API, the could be thought of as a separate task.  Currently FluidSynth
has a lot of convoluted code for different platforms.  Using glib would
clean a lot of this up.  It could be something added to the 1.1.0 branch
though.

It would be good to get an overview of the different features and
directions for FluidSynth and start to decide what should be a part of
the next 1.1.0 release.  It would be nice to release more often and
therefore we should perhaps stick with a smaller set of changes.  This
was why it was deemed a good idea to start a branch.

> 
> // David
> 

Best regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

[fluid-dev] Introductions and interest in FluidSynth

[Josh Green]

Hello FluidSynth list,

As I mentioned in a previous email, it seems like a good idea to
introduce ourselves a little and describe our interests in FluidSynth.
The project has been pretty dormant for some time now until recently, so
many of the recent personalities on the list are new.  It would be nice
to add some more personality to the names and get a better idea of how
we can work as a team.  Its somewhat of a new concept to me, so I hope
you all will bear with me on it ;)

I'll start things off.  No need to follow my example particularly, just
describe as much or little as you feel comfortable with.

A little about who I am..
I currently live in a small town called Nevada City in California (less
than 20,000 or so inhabitants).  I'll be turning 31 in a few days.  I'm
an embedded systems programmer consultant and primarily work with Linux,
which is great.  I'm living with some family and friends on a 60 acre
ranch.  I'm rather heavily into the Gothic scene and various types of
electronic music, like to go to Gothic clubs and DJ sometimes for a
local community radio station (http://resonance.org/electrolysis).  I
lived in Germany for a year and travel there when I can for music
festivals or the Linux Audio Conference.  I've been working for a number
of years on various free software projects (Swami, libInstPatch,
PatchesDB, FluidSynth, Refdbg) and hope to be able to put them to good
use as well as see what uses other people make of them.

My history with FluidSynth..
I was contacted by Peter Hanappe early on in the development of his IIWU
Synth (If I Were U).  He borrowed some SoundFont loading code from my
project Smurf SoundFont Editor (precursor to Swami).  Some
communications began about switching from using hardware SoundBlaster
synthesis to using his software synthesizer.  I met him in Paris and we
spoke a little about creating some interface for use in Smurf.  At one
point it became evident that IIWUSynth was not a very good name and so
we had a brainstorm of names.  He ended up choosing FluidSynth which was
one of a group of ideas I threw his way.  Most of the development of
FluidSynth was done by Peter Hanappe and Markus Nentwig (whom I also met
in person, in Germany).  I contributed from time to time, but minimally.
These past years I have been the official maintainer of FluidSynth, but
have had far too little time for the project.  It seems I've been able
to keep it barely alive though.

My current interest in FluidSynth..
..is in regards to Swami.  Swami aims to be THE SoundFont editor for
Linux, Windows and Mac.  Unfortunately development has also been slow
going, so it has not yet achieved its original goal.  The future of
Swami depends on FluidSynth though and so I am interested in seeing new
features, such as 24 bit sample support (Swami/libInstPatch supports
editing 24 bit SoundFont files already), sample streaming, better MIDI
to audio rendering and perhaps a new custom instrument format at some
point.

I would like to step away from some of the tasks of being the FluidSynth
maintainer and am open to the idea of passing on the official
"maintainer" title to someone more appropriate for the task.  I would
like to focus more on adding some of the features I mentioned and
working on Swami.  If I can get libInstPatch in order (a library for
manipulating instrument formats, such as SoundFont and DLS files) it
would be nice to look into using it as the basis of FluidSynth's
instrument loading and voice rendering and potentially support for other
instrument formats too.

I'm really looking forward to working with others on FluidSynth.  A one
man team, just isn't a team ;)

Cheers.
Josh

My project links:
Swami: http://swami.resonance.org
Resonance Instrument Database: http://sounds.resonance.org




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] FluidSynth 1.0.9 released

[Josh Green]

Hello David,

On Sun, 2009-04-12 at 12:26 +0200, David Henningsson wrote:
> Josh Green skrev:
> > So, its official.  The long overdue FluidSynth 1.0.9 "A Sound Future"
> > has been released.  
> 
> Thanks! \O/ Select your favorite MIDI song, launch FluidSynth and enjoy
> a system-wide release party! :-)
> 

Sounds like fun!  We can maybe do a live FluidSynth stream at some point
with some demo songs around release time ;)

> > The tarball is now slated to propagate through the
> > Savannah download mirrors.
> 
> And for those who can't wait for the mirrors to synchronize, it's
> available from
> 
> http://download.savannah.gnu.org/releases-noredirect/fluid/
> 

Thanks for mentioning that.  I was trying to figure out how to get
around the mirror redirect.

> > With all the new development interest, I've been realizing that my lack
> > of time for the project has been hindering progress somewhat.  For this
> > reason there will be some changes in the development process and
> > delegation of responsibilities to other individuals.  
> 
> I'm interested to know more about this and perhaps to be deeper involved
> with FluidSynth core development in the future.
> 

Yes yes!  The more the merrier.  A start is to get you a subversion
account.  Send me an email directly with your desired login/pass.

Your work on the sequencer timing looks like some good stuff.  Glad to
have you on the team.

> I have also started to work on getting the new 1.0.9 version into Debian
> - it was abandoned, so I intend to become the new Debian maintainer for
> FluidSynth. It's my first official package so I might have some related
> questions for you as well as the Debian mentors.
> 
> // David
> 

That is great, I didn't realize that the Debian package had been
abandoned.  I guess there has been so few releases in the past few
years.  Its nice that that is changing.

Since there are a number of individuals who have recently become
interested in FluidSynth development, I think it would be a good idea to
introduce ourselves a bit and mention what interest we have in
FluidSynth and how we would like to help out.  I'll post a new email
thread to this effect, to get things started.

Cheers.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

[fluid-dev] FluidSynth 1.0.9 released

[Josh Green]

Hello list,

So, its official.  The long overdue FluidSynth 1.0.9 "A Sound Future"
has been released.  The tarball is now slated to propagate through the
Savannah download mirrors.

The ChangeLog summary can be found here:
http://fluidsynth.resonance.org/trac/wiki/ChangeLog1_0_9

Thanks to all those involved!  I'm looking forward to this new phase of
FluidSynth and seeing where it evolves to.

With all the new development interest, I've been realizing that my lack
of time for the project has been hindering progress somewhat.  For this
reason there will be some changes in the development process and
delegation of responsibilities to other individuals.  This should lead
to a more focused and smoother development process.  I've been the
FluidSynth maintainer now for a while, but have only really been able to
"maintain" the project.  Its time for some innovation and direction.
Stay tuned.

Cheers!
Josh Green




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

[fluid-dev] Prepairing for 1.0.9 release

[Josh Green]

Hello,

I finally got around to reviewing the differences between SVN trunk and
1.0.8 and came up with the ChangeLog summary below.  Its really nice to
see the many names of those who contributed in this last development
cycle and this has also helped motivate me to work more on it.  I'm
excited about the future of FluidSynth and what it may bring.  Please
let me know if I credited someone incorrectly or forgot something.

Along with a commit of preset fallback selection logic (mentioned in my
previous email), I made a change to the default driver selection.  The
priority of the default driver is now "jack, alsa, pulse" in that order.

The timer changes look really nice and promising, but lets hold off on
them till the next release.  I also propose that we make the next
development cycle much shorter and use the milestone feature of Trac to
mark tasks that should be completed and not get too crazy with the
number of items in each release milestone.  Since 1.0.10 can be
confusing and also since the timing changes seem fundamental enough, I
think the release following 1.0.9 should be 1.1.0.

Provided the preset fallback selection logic seems correct (I tested it
a little), then its time for a release.  Please speak up now, if there
are any outstanding issues that should be resolved before hand.

Seeing how release names seem to be all the rage these days..  How about
"A Sound Future" for 1.0.9, in reference to the new development
interest.

Cheers!
Josh Green


New Features
----
New PulseAudio driver (Josh Green)
New Jack MIDI driver (Josh Green)
New CoreMIDI driver (Pedro Lopez-Cabanillas)
Portaudio driver re-written for Portaudio 19 (Josh Green)
Support for OS/2 including Dart audio driver (KO Myung-Hun)
RPN GM MIDI messages now handled for Bend Range, Fine Tune and Coarse Tune 
(Josh Green)
MIDI channel pressure now handled (Bernat Arlandis i Mañó)
MIDI Program/Bank instrument fallback selection logic (Josh Green and thanks 
also to Jimmy)
Added midi.portname setting to ALSA sequencer, -p command line switch (Nicolas 
Boulicault)
Added midi.winmidi.device setting to winmidi driver (Pedro Lopez-Cabanillas)
Updated Max/MSP FluidSynth binding (Norbert Schnell)

Synthesis Changes
-
Volume attenuation SoundFont generator now behaves more like EMU10K1 (S. 
Christian Collins)
Stop forcing velocity based filtering (S. Christian Collins)
Fixes to linear/bipolar/positive and convex/bipolar/positive modulator 
functions (S. Christian Collins)
Added fix to properly search for percussion instrument (Josh Green)
Force velocity envelope value to be that of the previous stage when switching 
from decay to sustain (S. Christian Collins)
Filter calculation now uses synthesizer sample rate rather than fixed at 44100 
(S. Christian Collins)

Bug Fixes
-
Fixed Jack driver in "audio.jack.multi=yes" mode and Jack audio driver cleanup 
(Bernat Arlandis i Mañó and Pedro Lopez-Cabanillas)
Wrong tempo changes (ticket #22 - Pedro Lopez-Cabanillas)
Crash bug fix related to using certain modulators in a preset (S. Christian 
Collins)
Fix to non-option command line argument processing when not using readline 
(Pedro Lopez-Cabanillas)
dsound device can't be selected (Ticket #16 - Pedro Lopez-Cabanillas)
Minor build fixes (Josh Green)

Miscillaneous
-
Updated README-OSX build instructions (Ebrahim Mayat)
FluidSynth fink package accepted for Mac OS X (Ebrahim Mayat)
Minor fixes to FluidSynth man page (Sven Hoexter)




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] invalid instrument/drum selection

[Josh Green]

Hello Jimmy,

Sorry for the delay.  I looked over your proposed changes.  It doesn't
seem like that is really the proper place for them though (would affect
the default SoundFont loader only).

I went ahead and implemented this logic in fluid_synth_program_change.

This seems to satisfy basic preset fallback selection.  So I've closed
Ticket #23.  Please let me know if this functionality works as expected.

http://fluidsynth.resonance.org/trac/ticket/23

Best regards,
    Josh Green


On Sat, 2009-02-07 at 07:31 -0800, jimmy wrote:
> Hi Josh,
> 
> One more try.  This also takes care of drum bank 128 fallback. Here is 
> 
>fluid_defsfont.c : fluid_defsfont_get_preset()
> 
> >>>>>
> 
> fluid_defpreset_t* fluid_defsfont_get_preset(fluid_defsfont_t* sfont, 
> unsigned int bank, unsigned int num)
> {
>   fluid_defpreset_t* preset = sfont->preset;
>   fluid_defpreset_t* fallback_preset = NULL;
>   while (preset != NULL) {
> 
> if (num == preset->num) {
>   if ((preset->bank == bank)) {
> return preset;
>   }
>   if ((128 != bank) && (0 == preset->bank)) {
> fallback_preset = preset;
>   }
> }
> 
> if ((128 == bank) && (0 == preset->num)) {
> fallback_preset = preset;
>   }
> preset = preset->next;
>   }
> 
>   if (( fallback_preset != NULL )) {
> FLUID_LOG(FLUID_WARN, " --- fluid_defsfont_get_preset: no instrument 
> found for [bank, prog: %d, %d], substituted with: [bank, prog: %d, %d]", 
> bank, num, fallback_preset->bank, fallback_preset->num ); 
> 
> return fallback_preset;
>   }
> 
>   return NULL;
> }
> 
> <<<<<
> 
> Please don't forget
> 
>fluid_ramsfont.c : fluid_ramsfont_get_preset()
> 
> Best regards,
> 
> Jimmy
> 
> 
> 
>   
> 
> 
> ___
> fluid-dev mailing list
> fluid-dev@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/fluid-dev



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] forward midi events out

[Josh Green]

Hello Joshua,

As you mentioned in your other email, there is no MIDI output ports from
FluidSynth.  When you say "midi out on another channel" what MIDI driver
are you using?  If it was the ALSA sequencer or JACK MIDI, you could
just have your MIDI source be a MIDI output port which gets connected to
FluidSynth and whatever other destinations you want to route the MIDI
events to.

Maybe that helps?

Best regards,
Josh

On Sat, 2009-03-14 at 17:10 +, Joshua Higgins wrote:
> Hi, 
> 
> I'm writing a custom control surface program for a touch screen which
> is basically a wrapper that sends cc events to the running fluidsynth.
> This is how I plan to have it set up:
> 
> control wrapper ---> fluidsynth ---> jack connected to ---> wineasio
> running a FM7 vst
> 
> My question is how to get fluidsynth to forward these cc events to
> midi out on another channel. I've read the router docs but cant make
> any sense of it.
> 
> Thanks.
> 
> 
> -- 
> joshua higgins
> >>--
> ___
> fluid-dev mailing list
> fluid-dev@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/fluid-dev



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

[fluid-dev] FluidSynth 1.0.9 release (was Re: Patch for bad MIDI timing (with large buffer sizes))

[Josh Green]

Hello David,

First off I'd like to say, thanks for your work in this area of
FluidSynth.  Its been a long time wish of mine to be able to render MIDI
files to audio, in a faster than realtime fashion and with the same
output every time.  This patch looks like the right direction to realize
this.

On Sat, 2009-03-14 at 21:50 +0100, David Henningsson wrote:
> > * fluid_player_join() must be fixed.
> 
> My alternate implementation of that one should work (does anybody know a
> sleep function for macos 9?). Actually it was the comment that misled me


Personally I don't think we should worry about Mac OS 9 anymore.  I'm
not even sure the current FluidSynth works on Mac OS 9.  If someone out
there is using Mac OS 9 with FluidSynth, please speak up.


> > * Ensure that the MIDI rendering ends before the last audio block has been 
> > sent to the output device. It would need even some additional time if there 
> > is some reverb or other effects applied.
> 
> I assume that should read as "Ensure that the MIDI rendering DOES NOT
> end...". Anyway, I see this as a separate issue unrelated to my patch. I
> reinstalled fluidsynth 1.0.8 from the Ubuntu archives and got a working
> -i switch, and confirmed that the issue is present there as well (the
> program quits too early, especially with a large audio.period-size).
> 


It seems like handling this properly would mean waiting for all voices
to terminate after the last MIDI note, plus some extra time for reverb.


> // David
> 


A FluidSynth release is long overdue.  I already let the tentative date
of March 9th slip.  I'm buried in work right now, so I've had very
little time to put into any free software projects.

This patch seems like a pretty fundamental change, though good one.  Its
tempting to try and include it in 1.0.9.  If there was a build time or
runtime option to select this new timing source, that would be ideal.

Cheers.

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New JACK MIDI driver and other stuff

[Josh Green]

Cool, just wanted to make sure ;)  I get temporary amnesia sometimes
from having so many projects.  That sounds like the right solution.
Thanks again guys for everything you have done on this last development
cycle.

I'll be pretty busy tomorrow, so its looking like Wednesday before I
have some time to put into making a release.

Cheers!
Josh


On Tue, 2009-03-10 at 09:39 +0100, Pedro Lopez-Cabanillas wrote:
> If you look *carefully* to  the Jack driver in trunk, you would notice
> that two functions, new_fluid_jack_audio_driver() and
> new_fluid_jack_audio_driver2() are still there:
> http://fluidsynth.resonance.org/trac/browser/trunk/fluidsynth/src/fluid_jack.c
> 
> What has changed is that the first function is now calling the second
> one, the same design used in most other audio drivers. Bernat coded
> the solution in the 2.0 branch, and I tested and backported his code
> to trunk. This has been discused already in the mailing list.
> 
> In addition to better structured code, this change was made to fix the
> ticket #21 in FS, and
> a similar bug report existing in QSynth: allow multiple audio outputs
> while the output meters are enabled.
> 
> http://fluidsynth.resonance.org/trac/ticket/21
> http://sourceforge.net/tracker/index.php?func=detail&aid=2538954&group_id=93509&atid=604538
> 
> On Tue, Mar 10, 2009 at 1:00 AM, Josh Green  wrote:
> > On Mon, 2009-03-09 at 23:53 +, Rui Nuno Capela wrote:
> >> Josh Green wrote:
> >> > I just committed support for Jack MIDI to SVN.  I tested this with
> >> > jack_midiseq.  Also tested with alsaseq2jackmidi by connecting up my
> >> > MIDI keyboard to FluidSynth using that program as a bridge.
> >> >
> >> > Some details of the Jack MIDI driver:
> >> > - Creates a separate Jack client called fluidsynth-midi (sharing the
> >> > Jack client instance would be awkward in the FluidSynth code)
> >> >
> >> > - Added a midi.jack.id option for specifying the Jack client name
> >> >
> >> > - Creates an input port called "midi"
> >> >
> >> > I noticed that the jack_audio_driver2 stuff got removed.  I think I saw
> >> > something like this being discussed on the list.  Note that the driver2
> >> > code is used by programs like QSynth to provide audio meters.  My guess
> >> > is that removing this code probably broke that functionality.
> >> >
> >>
> >> sorry to chime in this late :)
> >>
> >> yes, qsynth uses new_fluid_audio_driver2() for the audio output meters;
> >> not sure how this relates to the (dis)appearing stuff.
> >>
> >> in any case, as in general, it is my understanding of shared library
> >> version-ing that, when at least one exported symbol gets dropped or
> >> changed, you must increment the library version age, eg. make it 1.1.0
> >> and not 1.0.9. the latter would assume there's only additions to the api
> >> which doesn't seem to be the case, or is it?
> >>
> >> just my 2c.
> >>
> >> seeya
> >
> >
> > Hey Rui,
> >
> > The plan is to keep binary compatibility with the previous version of
> > FluidSynth, so we shouldn't be dropping symbols at this point.  I'll
> > make sure things are sorted out before release.
> >
> > Cheers!
> >Josh
> >
> >
> >
> >
> > ___
> > fluid-dev mailing list
> > fluid-dev@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/fluid-dev
> >



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New JACK MIDI driver and other stuff

[Josh Green]

On Mon, 2009-03-09 at 23:53 +, Rui Nuno Capela wrote:
> Josh Green wrote:
> > I just committed support for Jack MIDI to SVN.  I tested this with
> > jack_midiseq.  Also tested with alsaseq2jackmidi by connecting up my
> > MIDI keyboard to FluidSynth using that program as a bridge.
> > 
> > Some details of the Jack MIDI driver:
> > - Creates a separate Jack client called fluidsynth-midi (sharing the
> > Jack client instance would be awkward in the FluidSynth code)
> > 
> > - Added a midi.jack.id option for specifying the Jack client name
> > 
> > - Creates an input port called "midi"
> > 
> > I noticed that the jack_audio_driver2 stuff got removed.  I think I saw
> > something like this being discussed on the list.  Note that the driver2
> > code is used by programs like QSynth to provide audio meters.  My guess
> > is that removing this code probably broke that functionality.
> > 
> 
> sorry to chime in this late :)
> 
> yes, qsynth uses new_fluid_audio_driver2() for the audio output meters;
> not sure how this relates to the (dis)appearing stuff.
> 
> in any case, as in general, it is my understanding of shared library
> version-ing that, when at least one exported symbol gets dropped or
> changed, you must increment the library version age, eg. make it 1.1.0
> and not 1.0.9. the latter would assume there's only additions to the api
> which doesn't seem to be the case, or is it?
> 
> just my 2c.
> 
> seeya


Hey Rui,

The plan is to keep binary compatibility with the previous version of
FluidSynth, so we shouldn't be dropping symbols at this point.  I'll
make sure things are sorted out before release.

Cheers!
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

[fluid-dev] New JACK MIDI driver and other stuff

[Josh Green]

I just committed support for Jack MIDI to SVN.  I tested this with
jack_midiseq.  Also tested with alsaseq2jackmidi by connecting up my
MIDI keyboard to FluidSynth using that program as a bridge.

Some details of the Jack MIDI driver:
- Creates a separate Jack client called fluidsynth-midi (sharing the
Jack client instance would be awkward in the FluidSynth code)

- Added a midi.jack.id option for specifying the Jack client name

- Creates an input port called "midi"

I noticed that the jack_audio_driver2 stuff got removed.  I think I saw
something like this being discussed on the list.  Note that the driver2
code is used by programs like QSynth to provide audio meters.  My guess
is that removing this code probably broke that functionality.

Also committed an updated README-OSX from Ebrahim Mayat.

I'm going to review all the changes that have occurred since 1.0.8.  I'm
not sure if tomorrow will end up being the day for the release of 1.0.9,
due to limited free time, but I think we should try and make it happen
real soon.  Testing and feedback would be great!

Cheers!

Josh Green




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] FS2.0 proposal

[Josh Green]

Hello,

I didn't feel that Max's input was particularly arrogant or disdainful.
It was some strong criticism but it seemed to be rather constructive as
well.  There are indeed many shortcomings of FluidSynth and the project
hasn't really been all that active since I took over maintainership of
it.  Its a bit difficult to tell the tone of an email, since you don't
see the person's expressions as they write.  Language barriers and other
cultural differences add to the complexity of that.

Lets take Max's input and comments and do what we can to improve
things :)

Best regards,
Josh



On Mon, 2009-03-02 at 19:57 +0100, Pedro Lopez-Cabanillas wrote:
> Max Kellermann wrote:
> > I have not insulted anybody, I have not attacked anybody personally.
> > Which you did ("spitted some bullshit").  Let's keep this discussion
> > on a technical level, don't yield to personal criticism.
> 
> OK. I have been harsh and rude with you. Sorry about that. Please accept my 
> apologies.
> 
> I hope, accordingly, that you would like to apologize for the tone of disdain 
> and arrogance of your first message, and recognize your mistakes. In that 
> case we can keep the discussion on a technical level. Otherwise, this would 
> be my last word on the matter.
> 
> Regards,
> Pedro
> 




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] FS2.0 proposal

[Josh Green]

Hello Pedro,

On Sat, 2009-02-28 at 22:55 +0100, Pedro Lopez-Cabanillas wrote:
> Anyway, I would like to ask what do you think about a new stable release 
> 1.0.9 
> from trunk, soon. I really like all the new drivers, and also interesting 
> bugfixes. I would like to be able to fix tickets #22 and #23 first. I think 
> that #23 would be not exactly the same as #10, but only a limited workaround.
> 
> Regards,
> Pedro
> 

Yes, 1.0.9 is definitely due for release.  I seem to be pretty terrible
about actually getting releases out, which isn't really that big of a
process to begin with.  If someone thinks they can do better than me,
I'd welcome someone taking that over :)

The one feature I thought would be nice to get into 1.0.9 is a Jack MIDI
driver.  I don't think it is worth holding up a release though.  How
about we try and get a release out by the end of next weekend?  Say
Monday March 9th.

Regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] FS2.0 proposal

[Josh Green]

Hello Bernat,

On Sun, 2009-03-01 at 01:46 +0100, Bernat Arlandis i Mañó wrote:
> I don't want to do a rewrite, I'd like to be conservative about changes 
> except where absolutely necessary to reach the goals. I would even delay 
> libInstPatch or any other library integration if that meant a lot of 
> changes to the code.
> 

It would basically mean replacing the existing SoundFont loader API and
would probably be significant changes.  Seems like it might make sense
to keep the libInstPatch integration as a separate phase, since
libInstPatch still needs a little work too.

> My main goals now would be the improvement on modularization and a 
> simplification and better arrangement of the API. Having this 
> established should be easier to work separately on modules, or even 
> replace one module, f.e. replacing the current soundfont loader module 
> with libInstPatch.


Ok.  I understand better now what your goals are.


> > How familiar are you with glib?  A discussion that is probably worth
> > having from the beginning, is just some overview of features and data
> > types in glib that will be useful to us.  We should also decide on how
> > FluidSynth is going to handle locking of its internal data and
> > minimizing locking in the synthesis thread.  glib has cross platform
> > thread functions and primitives for this, but having a better idea of
> > what needs to be locked and when would be a good start.
> These are details that can be discussed later. Yes, I've used glib a 
> bit. I wouldn't start using glib data types everywhere, these changes 
> should be done progressively where we can get some benefit, f.e. we 
> could replace some arrays with hash tables and lists for better 
> performance in some places.
> 
> Locking is another entirely different problem. I know there are a lot of 
> important and interesting problems to solve, but I don't want to fix 
> them all now. I just want to improve the modularization and API.
> 
> I hope you're honest and let me know if you think I should forget about 
> this. Maybe I'm talking bullshit or I'm not the right person or it's not 
> the right moment or I'm just bad explaining it. Whatever it is I think 
> we aren't getting on very well and it's making me loose confidence on 
> what I'm doing.


How did you arrive at the conclusion that we aren't getting on very
well?  I'm really excited that you are interested in working on cleaning
up the FluidSynth API and modularizing it.  From this correspondence I
realize that I have a bit more desire to overhaul things, than simply
clean them up, which might not even be that realistic at this stage.  I
think your ideas and thoughts are well thought out and the last thing I
want to do is get in the way of your efforts.  Everything you mentioned
in your proposal sounded good to me, I was simply trying to add my own
thoughts on FluidSynth 2.0.  In reality, thoughts and ideas are much
easier spoken than coded and you seem to currently have more motivation
to work on FluidSynth than I do (due to my other projects).

So by all means, the forked branch is yours to do with as you will and
as we go along, I can get a better idea of how I can help.

Best regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] FS2.0 proposal

[Josh Green]

Hello,

On Sat, 2009-02-28 at 18:20 +0100, Bernat Arlandis i Mañó wrote:
> Hi.
> 
> Sorry for the long wait but I'm a bit busy lately. This is how it's 
> gonna be since this is something I have to do on my spare time so there 
> will be ups and lows inevitably, but I'm firmly decide to get there with 
> your help.
> 


I've also been very busy and have a lot of projects too and so I'm in as
similar situation.  But I do enjoy working on FluidSynth when I get
inspired.


> I've been thinking a bit on what I'd like to do for FS2.0 and would be 
> interesting to do. My goal is having a better code base to work on 
> building new features and improving performance and compatibility 
> without the problems we have right now.
> 
> My first priority is designing a simple API that hides the internals and 
> provides just what is needed and expected from FS. I think this is also 
> the first thing that should get done since it's fundamental to other 
> decisions, the new API will guide the refactoring of the code.
> 
> I've made a simple design diagram for FS components (image attached), 
> dependencies have been minimized and there's no loops. Based on this 
> diagram we should be able to define what every component should provide 
> and what not. Every component should be seen as a library even though 
> we're not planning on distributing them separated, thus every component 
> will have its own API and the sum of them will be the FS API.
> 
> We must follow some guidelines to library implementation as suggested by 
> Max Kellermann. All API functions should check their parameters and 
> report their condition by returning result codes. Abnormal conditions in 
> internal functions can be taken care by asserts and should be treated as 
> programming errors.
> 


glib has some useful macros in this regard.  g_return_if_fail and
g_return_val_if_fail, for functions which don't return a value and ones
which do, respectively.  I use them extensively in Swami and
libInstPatch.


> We should also remove code from FS that can be used from external 
> libraries. We talked about using glib and the swami sounfont library, 
> maybe using gobject too. I took a look at gobject and I think it might 
> be overkill for this project right now.
> 


I think the properties system would be a nice replacement for the
FluidSynth settings system that exists now.  And it would pave the way
for Python and C++ bindings (leveraging off of the work of PyGObject and
GTK--).  The reference counting and consistent object
creation/destruction is also useful.  We could always do that as a
separate branch though.  Perhaps I've just gotten too used to using it
in my projects :)


> We'll be breaking compatibility in a major way, so another important 
> task is helping applications become compatible with the new API by 
> providing patches and support. We could try providing a compatibility 
> layer for the old API but it might take too much effort.
> 
> So, this is a list of tasks without strict order:
> 
>  - Define API for every component.


I'm not convinced this is entirely necessary from the get go.  We could
work on this in stages (described below).


>  - Replace code with external libraries where possible.
>  - Refactor code.
>  - Implement missing API functions.
>  - Implement checks and result codes on every API function.
>  - Document the new API.
>  - Helping applications developers upgrade to the new API.
> 

That all sounds good.

For documentation, we could use GTK doc.  The resulting HTML
documentation looks nice and I have come to really like the syntax.  You
can document pretty much everything in the code, which is where it
belongs.  Getting into the habit of documenting while coding, is the
right way to do things, rather than having to come back and document it
later.


> This is much work, and we're a just few developers with not much time. I 
> won't mind working alone, but there's some subjects where I'd truly need 
> your help:
> 
>  - Autotools/automake/libtool maintenance and support.
>  - Platform building and testing (including drivers).
> 
> Also, I'd like to avoid regressions, so everyone willing to test every 
> new commit and report feedback is very welcome. Providing patches for 
> maintaining compatibility with other applications (like QSynth) would 
> help doing better testing too.
> 
> There's some places where collaboration will be necessary (API design), 
> but sometimes it'll be troublesome (refactoring), communication will be 
> really important. I'd like this to be a collaborative effort and get you 
> all involved in some way, but coordination and direction is very 
> important to succeed so I should take the lead in this branch.
> 


Sounds good.


> As can be seen, implementing new features is not the main goal right 
> now, but if we get the new modular design right then some wanted 
> features will get done without effort. Besides, anyone can start a new 
> branch if they feel like implementing any experi

Re: [fluid-dev] FS2.0 proposal

[Josh Green]

On Sat, 2009-02-28 at 18:24 +0100, Bernat Arlandis i Mañó wrote:
> The attached image I promised. :)
> 
> Josh, I couldn't upload this image to the wiki, here: 
> http://fluidsynth.resonance.org/trac/wiki/newdesign
> 

Did you get an error?  Or did it just not give you the option to attach
it?  I was able to do so, but there could be a permission issue.

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] [PATCH] OS/2 DART support

[Josh Green]

On Wed, 2009-02-04 at 16:05 +0900, KO Myung-Hun wrote:
> Of course, there are many people to want to use FluidSynth on OS/2. If
> there was no people, would I port it ? In addition, FluidSynth is
> important as a lib as well as a stand-alone program. The reason I ported
> FluidSynth at first was also to use it as a lib for ScummVM, which is
> available to OS/2 already.
> 

Alright, you've convinced me :)  The ScummVM support for OS/2 in
particular.

> > But what's next, DOS support?  ;)
> >   
> 
> If there is someone who could do it. ^^
> 

Well, I COULD, but do I want to?  FluidSynth kind of depends on a 32 bit
memory space.  Porting it to some sort of protected mode DOS overlay,
isn't really high on my todo list.  Ha ha.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] [PATCH] OS/2 DART support

[Josh Green]

Hello,

Yes, I have a question.  Didn't OS/2 die a long time ago?  Obviously
not, if you are contributing a patch for audio driver support for it.  I
wonder if there would be any other users who would want to use
FluidSynth on OS/2 though.  If not, I don't think it should be included
in the FluidSynth code base.  Maybe I'm completely wrong though and
there are thousands of OS/2 users out there, just waiting for a
FluidSynth release on their OS platform of choice.  I could probably be
convinced to include it..  But what's next, DOS support?  ;)
Josh


On Wed, 2009-02-04 at 14:53 +0900, KO Myung-Hun wrote:
> Hi/2.
> 
> This patch enables a OS/2 DART audio driver support based on 1.0.8
> release sources.
> 
> Any comments ?
> 
> plain text document attachment (os2.diff)
> diff -EbuNr --strip-trailing-cr configure.ac.org configure.ac
> --- configure.ac.org  2007-11-17 14:32:06.0 +0900
> +++ configure.ac  2008-08-26 11:35:40.0 +0900
> @@ -75,6 +75,10 @@
>LIBFLUID_LDFLAGS="-no-undefined"
>FLUID_CPPFLAGS="-DFLUIDSYNTH_NOT_A_DLL"
>;;
> +os2*)
> +  LDFLAGS="$LDFLAGS -Zbin-files"
> +  LIBFLUID_LDFLAGS="-no-undefined"
> +  ;;
>  esac
>  
>  AC_SUBST(LIBFLUID_LIBS)
> @@ -227,6 +231,24 @@
>  AC_SUBST(COREAUDIO_LIBS)
>  
>  dnl
> +dnl - Check support for DART
> +dnl
> +AC_CHECK_HEADER(os2me.h, DART_FOUND="yes", DART_FOUND="no")
> +AC_ARG_ENABLE(dart, AS_HELP_STRING([--disable-dart],
> +[disable DART support (default=auto)]),
> +  enable_dart=$enableval, enable_dart="yes")
> +
> +DART_SUPPORT=0
> +if test "$enable_dart" = "yes" -a "$DART_FOUND" = "yes"; then
> +  AC_DEFINE(DART_SUPPORT, 1, [whether or not we are supporting DART])
> +  DART_SUPPORT=1
> +fi
> +
> +AM_CONDITIONAL(DART_SUPPORT, test "$DART_SUPPORT" = "1")
> +AC_SUBST(DART_CFLAGS)
> +AC_SUBST(DART_LIBS)
> +
> +dnl
>  dnl Check for readline support (Josh Green 2003-06-10)
>  dnl
>  AC_ARG_WITH(readline,
> @@ -379,6 +401,12 @@
>echo "LADCCA support:no"
>  fi
>  
> +if test "${DART_SUPPORT}" = "1"; then
> +  echo "DART support:  yes"
> +else
> +  echo "DART support:  no"
> +fi
> +
>  dnl if test "${AUFILE_SUPPORT}" = "1"; then
>  dnl   echo "Sound file:yes"
>  dnl else
> diff -EbuNr --strip-trailing-cr src/config.h.in.org src/config.h.in
> --- src/config.h.in.org   2007-11-17 14:32:30.0 +0900
> +++ src/config.h.in   2008-08-26 11:43:02.0 +0900
> @@ -6,6 +6,9 @@
>  /* whether or not we are supporting CoreAudio */
>  #undef COREAUDIO_SUPPORT
>  
> +/* whether or not we are supporting DART */
> +#undef DART_SUPPORT
> +
>  /* Define if building for Mac OS X Darwin */
>  #undef DARWIN
>  
> diff -EbuNr --strip-trailing-cr src/fluid_adriver.c.org src/fluid_adriver.c
> --- src/fluid_adriver.c.org   2007-08-18 14:53:34.0 +0900
> +++ src/fluid_adriver.c   2008-03-30 20:13:20.0 +0900
> @@ -96,6 +96,13 @@
>  int delete_fluid_sndmgr_audio_driver(fluid_audio_driver_t* p);
>  #endif
>  
> +#if DART_SUPPORT
> +fluid_audio_driver_t* new_fluid_dart_audio_driver(fluid_settings_t* settings,
> +  fluid_synth_t* synth);
> +int delete_fluid_dart_audio_driver(fluid_audio_driver_t* p);
> +void fluid_dart_audio_driver_settings(fluid_settings_t* settings);
> +#endif
> +
>  #define AUFILE_SUPPORT 1
>  #if AUFILE_SUPPORT
>  fluid_audio_driver_t* new_fluid_file_audio_driver(fluid_settings_t* settings,
> @@ -154,6 +161,13 @@
>  delete_fluid_jack_audio_driver,
>  fluid_jack_audio_driver_settings },
>  #endif
> +#if DART_SUPPORT
> +  { "dart",
> +new_fluid_dart_audio_driver,
> +NULL,
> +delete_fluid_dart_audio_driver,
> +fluid_dart_audio_driver_settings },
> +#endif
>  #if AUFILE_SUPPORT
>{ "file",
>  new_fluid_file_audio_driver,
> @@ -205,6 +219,8 @@
>fluid_settings_register_str(settings, "audio.driver", "portaudio", 0, 
> NULL, NULL);
>  #elif JACK_SUPPORT
>fluid_settings_register_str(settings, "audio.driver", "jack", 0, NULL, 
> NULL);
> +#elif DART_SUPPORT
> +  fluid_settings_register_str(settings, "audio.driver", "dart", 0, NULL, 
> NULL);
>  #elif AUFILE_SUPPORT
>fluid_settings_register_str(settings, "audio.driver", "file", 0, NULL, 
> NULL);
>  #else
> @@ -233,6 +249,9 @@
>  #if JACK_SUPPORT
>fluid_settings_add_

Re: [fluid-dev] One output per channel

[Josh Green]

On Tue, 2009-02-03 at 16:27 +0100, Bernat Arlandis i Mañó wrote:
> Josh Green escrigué:
> >
> > The new2 driver stuff is not obsolete.  Its used in particular by QSynth
> > to intercept the audio for meters.  I definitely think this mess should
> > be overhauled for FluidSynth 2.x, but shouldn't be removed in the 1.x
> > branch though.  I didn't look at your changes closely yet, so perhaps I
> > misunderstood exactly what changes you have made.  I'll take a closer
> > look when I get a chance.
> >
> >   
> I meant the implementation of this function, I've synched new and new2 
> so they're now doing the same, as in the ALSA driver. The code will 
> explain itself better than I do. :)
> 

Sounds good!  Just wanted to make sure :)
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] One output per channel

[Josh Green]

On Mon, 2009-02-02 at 23:39 +0100, Bernat Arlandis i Mañó wrote:
> Pedro Lopez-Cabanillas escrigué:
> >
> > I would like to see this fix (ticket #21) into trunk, if it can be 
> > backported 
> > without breaking 1.x API.
> >
> >
> >   
> It deals basically with the Jack driver, I've replaced the obsolete 
> new_fluid_jack_audio_driver2 function with the newer 
> new_fluid_jack_audio_driver function. I haven't touched the function 
> definitions so I think it's compatible, and the patch should be easy to 
> apply directly to the trunk since the new branch hasn't changed much. 
> It's up to you to decide whether it should get to the trunk.
> 
> It could have been fixed better, I know, but I didn't want to break 
> compatibility for now.
> 
> You can see the changeset here: 
> http://fluidsynth.resonance.org/trac/changeset/154
> 
> Best regards.
> 

The new2 driver stuff is not obsolete.  Its used in particular by QSynth
to intercept the audio for meters.  I definitely think this mess should
be overhauled for FluidSynth 2.x, but shouldn't be removed in the 1.x
branch though.  I didn't look at your changes closely yet, so perhaps I
misunderstood exactly what changes you have made.  I'll take a closer
look when I get a chance.

Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Fluidsynth internal structures

[Josh Green]

On Sun, 2009-02-01 at 12:23 -0800, jimmy wrote:
> Hi folks,
> 
> I know Miguel(???) was working on a reimplementation of FS using CPP.  Plus, 
> some folks here are looking to modularize FS.  You may want to use some kind 
> of dictionary, or table look up for some of the structures (objects) used in 
> FS.  Hopefully for a more efficient and a little faster real-time look up.
> 
> For what it's worth, I have been tracing through some of the FS code and find 
> that the structure:
> 
>fluid_sfont_t
> 
> can be a virtual pointer to a font structure of type:
> 
>fluid_defsfont_t
> 
> which contains a pointer to a "preset" structure:
> 
>fluid_preset_t
> 
> There is a preset for each prog_num in each soundbank(s) of a soundfont.  As 
> used in
> 
>fluid_defsfont.c : fluid_defsfont_get_preset()
> 
> The fluid_preset_t is a link-list structure pointing to the next 
> fluid_preset_t structure.  Basically, that function walks through consecutive 
> presets:
> 
>preset for bank 0 prog 0
>preset for bank 0 prog 1
>preset for bank 0 prog 2
>. . .
>preset for bank 0 prog 128
> 
> follow by presets for any additional instrument bank(s), and drum bank 128.  
> This lookup is used for every prog_change.
> 
> That's a simple and straigh forward way to implement the system using linear 
> link-list, but can be very inefficient for look up time.
> 
> Best regards,
> 
> Jimmy
> 

Indeed, but that is only during program change time, which isn't as
critical as note-on time.  As we have been discussing, FluidSynth will
likely move to using libInstPatch for instrument management, which does
things a bit differently and in a more optimized fashion (in particular
for the note-on case).
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: PortAudio driver (was Re: [fluid-dev] New development)

[Josh Green]

Hello Pedro,

On Sun, 2009-02-01 at 02:05 +0100, Pedro Lopez-Cabanillas wrote:
> I've checked in some changes to the PortAudio driver.
> 
> - PortAudio enumerates devices having input only ports. As we need audio 
> output  devices, I've changed the enumeration to ignore devices with less 
> than 2  output channels available.
> 
> - For the default device name, I've defined the string "PortAudio Default" 
> trying to solve the clash with ALSA's "default" device name. The function 
> Pa_GetDefaultOutputDevice() provides the default device index.
> 
> - Added an assignment for the device index of the matching requested device 
> name.
> 


Sounds like some good stuff.  Thanks for completing those!


> About the Windows tests. The current status of PortAudio is somewhat sad, 
> being optimist. Their autohell build system allows only one backend at once. 
> To compile the WDMKS backend the documentation says that it needs DirectX 
> SDK, but the needed headers come from the Drivers Kit instead. It compiles, 
> but the initialization is deactivated, requiring to uncomment some lines in 
> the file "pa_win_hostapis.c". After some googling you realize that there is 
> an active ticket about this: http://www.portaudio.com/trac/ticket/47
> 
> In order to build Fluidsynth, portaudio.pc needs to be modified by hand. Only 
> to  realize that there is no sound at all. Using different devices doesn't 
> help. PA Test programs don't produce noise, either. It is a problem with the 
> backend code, that only invokes the callback when there is an input stream, 
> in addition to the output one. There are some googles talking about this. 
> Finally, after commenting out the offending condition, there is sound at 
> last!. Buffer size: 64, Buffer count: 2, latency of less than 3 msecs at 
> 48000 Hz. The sample rate depends on the device: there isn't automatic 
> resampling, only the rates supported by the device. The bad news: the first 
> underrun affects very badly the audio quality forever. There is no automatic 
> recovery, or any other solution than restarting over.
> 

That sounds like a pretty sad state of affairs.  Hopefully it will
improve.  The latency under 3 msecs sounds pretty good though.  Having
the sound get out of sync though on an underrun, doesn't sound too nice
though.

> Regards,
> Pedro

Cheers!
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] invalid instrument/drum selection

[Josh Green]

On Fri, 2009-01-30 at 10:14 -0600, S. Christian Collins wrote:
> I'm used to the following behavior when using MIDI on a Creative card:
> when I select an instrument not present, such as bank 8 program 20,
> the MIDI track will sound using bank 0 program 20 instead.  This seems
> like a simple and logical way to deal with missing patches, and is
> what I've come to expect when working with MIDI.
> 
> -~Chris

Easy enough.  I'll add something to this effect.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New branch

[Josh Green]

Hello,

On Fri, 2009-01-30 at 02:05 +0100, Bernat Arlandis i Mañó wrote:
> Hi.
> 
> I've started the new branch and committed the changes I was doing. Not 
> much new, just playing around trying to learn and fix some things. You 
> might want to review it for possible inclusion of some of the fixes in 
> 1.0.9 (or later versions) in the stable branch, since we're near a new 
> stable release I don't feel like committing anything to the trunk 
> without supervision.
> 

Sounds good.  I think at this point I will see about getting a Jack MIDI
driver working and make some minor improvements to the PortAudio driver,
but otherwise I'll also be keeping my fingers out of any quick
"fixes" ;)

> Josh, I've already undone the fix for ticket #11 in the trunk.
> 

Thanks.  We can address that in the next release.

> It's pending that I post some proposals for the new branch and 
> discussing it before starting serious development in the new branch. I'm 
> getting there.
> 
> This is the URL: https://resonance.org/svn/fluidsynth/branches/2.x
> 
> Regards.
> 

I also had a thought that I'd like to run by you and others interested
in development.  That is, we decided to have glib as a dependency, what
about GObject (also part of glib).  I've gotten rather used to it
myself, since libInstPatch and Swami are completely built off of it.
Its got a little bit of a learning curve and is probably annoying to
anyone who is used to a real object oriented language, but it does the
job and has some nice features too (the properties system for example
and almost completely automated Python bindings).  FluidSynth is already
wrapped in a GObject as a Swami plugin, so that code could be used, *IF*
we decide to go that route.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development

[Josh Green]

On Thu, 2009-01-29 at 22:46 +0100, Pedro Lopez-Cabanillas wrote:
> I have a problem with ASIO, though. First, I don't like the license terms 
> from 
> Steinberg: they don't allow to redistribute their sources (that are available 
> free of charge for registered developers). Second, they ask for an unfair 
> amount of personal data before allowing you to download the SDKs. 
> 
> I've created binary setup packages for Windows bundling QSynth and FluidSynth 
> in the past (available in SourceForge). I fear that I'm not going to include 
> ASIO support in the future ones.
> 
> Regards,
> Pedro

Now that I read things right..  So your objection to ASIO extends to
PortAudio as well?  I mean, distributing a PortAudio enabled FluidSynth,
which happens to be able to use ASIO as a side effect, seems relatively
harmless.  Especially if you aren't bundling PortAudio as well.

I can understand your objections to semi-closed or completely closed
standards, I dislike them myself.  I had a rather lengthy discussion
with someone over the licensing terms of the DLS instrument standard.  I
think to this day, their clutching on to the specification is the reason
why it isn't as popular as SoundFont, despite some of its improvements
over them.  It seems like its the open standards that end up getting
adopted usually, even if they aren't necessarily the best.

Regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development

[Josh Green]

On Thu, 2009-01-29 at 23:29 +0100, Pedro Lopez-Cabanillas wrote:
> Josh Green wrote:
> > On Thu, 2009-01-29 at 22:46 +0100, Pedro Lopez-Cabanillas wrote:
> > > Thanks, Josh!
> > >
> > > I will try to find some time this week end to play in Windows. I've
> > > already succesfully tested it on Linux.
> > >
> > > I have a problem with ASIO, though. First, I don't like the license terms
> > > from Steinberg: they don't allow to redistribute their sources (that are
> > > available free of charge for registered developers). Second, they ask for
> > > an unfair amount of personal data before allowing you to download the
> > > SDKs.
> > >
> > > I've created binary setup packages for Windows bundling QSynth and
> > > FluidSynth in the past (available in SourceForge). I fear that I'm not
> > > going to include ASIO support in the future ones.
> > >
> > > Regards,
> > > Pedro
> >
> > I guess an alternative to all that would be to just write ASIO drivers
> > for FluidSynth.  Any ideas where one can find the API documentation?
> > Josh
> 
> I don't understand how it would be an alternative.
> 
> I suppose that the API documentation would be included in the ASIO SDK. 
> 
> Regards,
> Pedro

Oops, I misunderstood that.  I thought you were talking about the
license terms of PortAudio.  I should read slower :)

Regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development

[Josh Green]

On Thu, 2009-01-29 at 22:46 +0100, Pedro Lopez-Cabanillas wrote:
> Thanks, Josh!
> 
> I will try to find some time this week end to play in Windows. I've already  
> succesfully tested it on Linux.
> 
> I have a problem with ASIO, though. First, I don't like the license terms 
> from 
> Steinberg: they don't allow to redistribute their sources (that are available 
> free of charge for registered developers). Second, they ask for an unfair 
> amount of personal data before allowing you to download the SDKs. 
> 
> I've created binary setup packages for Windows bundling QSynth and FluidSynth 
> in the past (available in SourceForge). I fear that I'm not going to include 
> ASIO support in the future ones.
> 
> Regards,
> Pedro

I guess an alternative to all that would be to just write ASIO drivers
for FluidSynth.  Any ideas where one can find the API documentation?  
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development

[Josh Green]

Hello,

Good point about WineASIO, I didn't actually know such thing existed.

Best regards,
Josh

On Thu, 2009-01-29 at 11:28 +0200, ggoode.sa wrote:
> Hi Josh,
> 
> I don't have a build environment in Windows at the moment and probably
> won't for a few more weeks (in the middle of a move), but if you email
> me your build I'm willing to try it in WinXP. Alternatively one could
> test this with the WineASIO driver and WINE (which then patches into
> JACK).
> 
> GrahamG



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development

[Josh Green]

On Thu, 2009-01-29 at 00:12 +0100, Pedro Lopez-Cabanillas wrote:
> > Seems to me like it is definitely worth improving the existing PortAudio
> > driver.  Any idea what this would entail?
> > Josh
> 
> Briefly:
> * Detect and define PORTAUDIO_* in the build system. I've done that using 
> pkg-config portaudio-2.0 >= 19. Allow to disable compilation of this driver, 
> maybe disable it by default?

I think if portaudio is found, it just be included as a driver.  If its
installed, chances are the user wants to use it.

> * Implement new2() and call new2() from new() as it is usual in most other 
> audio drivers. Or leave that for a later version/never?

The new2 drivers are used by QSynth and perhaps some other applications
to intercept the audio.

> * Register the setting "audio.portaudio.device" to list/select detected 
> devices and backends as reported by Pa_GetDeviceCount() and 
> Pa_GetDeviceInfo().   
> * Maybe more settings? Some backends would require special ones?
> * PortAudio API functions changed: Pa_OpenStream(), PaStreamCallback, ...
> * Testing: ASIO in Windows, but it should also work for other 
> platforms/backends...
> 
> Regards,
> Pedro

After looking at the fluid_portaudio.c and seeing how small it was, I
decided to take a crack at it.  Checked in is the new PortAudio driver
using PortAudio API 19.  I added device enumeration, but it still needs
some improvement.  It is using the device names for the setting
audio.portaudio.device, but these look like they can be rather long and
I'm not sure if there is any guarantee that they will be unique.  I also
am using the string "default" to try and select the default device,
which I was assuming would be device 0, but I'm not sure about that and
this would also conflict with the ALSA "default" device name.

PortAudio selects its devices based on index.  Perhaps specifying the
device numerically would be better, though it would be nice to be able
to see the names in a drop down list in applications as well.

Other improvements would be the addition of a new2 driver.

Anyone willing to try this with ASIO on Windows?

Best regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] One output per channel

[Josh Green]

On Wed, 2009-01-28 at 22:37 +0100, Bernat Arlandis i Mañó wrote:
> What do you think about fixing ticket #21 for 1.09? Without this, 
> multi-channel output cannot be enabled from QSynth.
> 

I'm looking at this now.  I must admit, I've never quite figured out why
there are 2 sets of drivers (driver and driver2 from here on), except
for allowing for the possibility of an audio callback function so that
other applications can intercept the audio.  It looks like it allows for
audio input ports as well, which are fed to this callback.

Looking at the two Jack new() functions though, it seems like they
should be merged (or at least have as much of the same functionality
that makes sense).  Its a bit confusing to me still since I see the
following:

driver uses synth.audio-channels while driver2 uses
audio.output-channels to set the number of output channels

driver seems to create 2 * synth.audio-channels Jack ports, whereas
driver2 just creates the requested number of audio.output-channels

driver2 allows for input Jack ports (who uses these?  I don't think
FluidSynth does).

FX ports are used with driver but not with driver2.  I'm not even sure
what these are actually, can anyone enlighten me?

driver supports LASH, driver2 does not.


It looks like a pain to make sense of this stuff.  I don't really use
these features myself, so I'm a little at a loss to figure out how to do
it right.  I think the whole driver system needs a good overhaul for
2.0.

Rather than try to do it right for 1.0.9, seems like we should just get
things working for QSynth and multi-channel audio.  Does it work if you
set audio.output-channels instead?


> Also, I've fixed the reverb and chorus effects in multichannel mode so 
> they're applied to every channel, instead of mixing the effects separately.
> 

Cool!

> I'm thinking about starting the new branch and commit these changes 
> there so you can review them in case you consider merging them to the trunk.
> 

Seems like a good candidate for the branch.  I don't want to break 1.0.9
by putting in stuff that should get more testing before inclusion.

Cheers!
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

[fluid-dev] Trac ticket details enabled

[Josh Green]

Hey guys,

I enabled the Trac ticket details on the Timeline, since this was
mentioned as a desired feature.  Make sure the "Ticket details" toggle
is on in the Timeline settings box.

Cheers.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development : system clock vs. audio clock

[Josh Green]

On Wed, 2009-01-28 at 11:34 +0100, Antoine Schmitt wrote:
> Hello,
> I'm not sure that the problem can be ignored for Midi file playback,  
> because a large driver buffer will miss some midi events, which will  
> then happen late in the audio stream.
> 
> About my patch, the fact is that I haven't found a clean way to link  
> the synth to the sequencer. I verified that my fix worked, but did not  
> manage to clean up the API nicely. The synth and the seq currently  
> just point to each other. I did not know how to manage this API  
> change, and still don't. There is this seqbingd.h file which purpose  
> was to isolate the synth from the seq. If we link them directly in  
> some way, this file is useless. I need advice...
> 

Having some source code to sink our teeth into, would help a lot.  Did
you already make it available and I missed that memo?  If not, would it
be possible to place it somewhere?  I could make a branch for it in SVN.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] invalid instrument/drum selection

[Josh Green]

Hi Jimmy,

Just keeping the already selected instrument when an invalid selection
is received seems strange to me.  Do you think that would create the
desired effect in most MIDI files?  It is a case of the MIDI file
expecting an instrument to be present, which is not, right?  I'm not
convinced that just keeping the previous instrument selection is any
better than trying to be a little smarter about it, depending on the
mode (GM, GS, XG, etc).  If a SoundFont was loaded, which supported all
the instruments of the playing MIDI file, then there would be no issue.

Best regards,
Josh

On Wed, 2009-01-28 at 06:08 -0800, jimmy wrote:
> Hi Josh,
> 
> If bank 0 has a full GM soundfont, then what you said should work.
> 
> In an ideal situation, since FS allows loading multiple soundfonts in any 
> order, I think a search for all soundfonts and all soundbanks of each 
> soundfont for the first available prognum for this substitution scenario.  
> However, I do know this could potentially slows FS down, I think this mapping 
> of 128 "fall-back" instruments could be done once, after all soundfonts have 
> been loaded, and cached for performance reasons.  Of course, if one of these 
> 128 fall-back instruments doesn't exist, then keep the currently loaded 
> instrument on that channel.  My suggested "if-statement" only keeps the 
> currently loaded instrument.
> 
> 
> Whatever you did last year did solve the drum portion already, for me at 
> least.  Somehow that also did seem to take care of invalid program change for 
> those 6 or so midi test files of the time.
> 
> I only notice the problem with this one midi file because several of the 
> instruments did not sound, and one instrument is panned off-center so it 
> sounded odd, and I took a closer look.
> 
> Best regards,
> 
> Jimmy
> 




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Re: CoreMIDI driver changes

[Josh Green]

Great to hear.  Thanks as always for your testing efforts.  Cheers!
Josh

On Wed, 2009-01-28 at 09:16 -0500, Ebrahim Mayat wrote:
> Hello
> 
> Following up from yesterday, I just tried the new enhanced CoreMIDI  
> feature with a dual port MIDI interface and sure enough I can trigger  
> samples of two different soundfonts from the two MIDI ports.
> 
> Also worth noting, is that I could also use the CoreMIDI driver in  
> SWAMI after selecting it from
> Edit --> Preferences --> FluidSynth --> Midi Driver
> 
> then restarting fluidsynth from within SWAMI : Plugins --> Restart  
> FluidSynth
> 
> Compilation of fluidsynth is now straight-forward with the addition of  
> the CoreMIDI feature. There is no need to install MidiShare though  
> MidiShare support can still be built as an option.
> BTW, the latest version of JackOSX (0.80) runs seamlessly with  
> fluidsynth.
> 
> E
> 
> 
> ___
> fluid-dev mailing list
> fluid-dev@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/fluid-dev



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development

[Josh Green]

On Tue, 2009-01-27 at 21:59 +0100, Pedro Lopez-Cabanillas wrote:
> I don't think so. Seems that the PortAudio driver would be useful only to  
> Windows users, where FluidSynth has only a DirectSound driver with huge 
> latency problems. For this platform PortAudio provides ASIO and WinMM audio 
> drivers. There was also a WDM KS driver, but I don't know about the current  
> status of it. I don't know if this business would be a success or a failure 
> at all, before testing it. Even if PortAudio is not near our (high) 
> expectations, I would like to give it an opportunity.
> 
> Regards,
> Pedro
> 

Seems to me like it is definitely worth improving the existing PortAudio
driver.  Any idea what this would entail?
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

[fluid-dev] Re: CoreMIDI driver changes

[Josh Green]

On Tue, 2009-01-27 at 21:18 +0100, Pedro Lopez-Cabanillas wrote:
> > Hello Pedro
> >
> > I am unable to add any feedback on the ticket referred to above.
> 
> Trac requires to log in with your user/password to edit tickets. If you 
> provided it, then there is a problem with the site. Josh, can you take a 
> look?
> 

I just successfully registered an account and was able to at least
preview changes in the ticket system (didn't actually submit anything).
What is the issue in particular?  Any error messages?

Best regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] invalid instrument/drum selection

[Josh Green]

Hello Jimmy,

I remember discussing this issue way back when, but kind of left it for
later, since I wasn't really sure what the best solution was.  I should
probably read over the older thread, since I think I did have some good
ideas of how to resolve it then (something about determining whether the
MIDI file is expecting a GM, GS or XG MIDI device).

In summary and to check my understanding..

MIDI file selects an instrument in an alternative bank/program,
expecting a variation on an instrument.  The loaded SoundFont doesn't
have the particular bank/program combination.  Currently FluidSynth
mutes the channel.  What you are proposing is to just have it continue
using the previously selected instrument.

Personally I think FluidSynth should listen for MIDI events indicating
GM, GS or XG mode and also have the ability to override the mode
manually.  When in GS or XG mode, it could fall back to bank 0 same
program #, if an instrument is not found.  Does that sound adequate?
Josh


On Tue, 2009-01-27 at 08:28 -0800, jimmy wrote:
> Hi Josh,
> 
> Again, the test midi is:
> 
>www.sternton.com/midi/xgmidi/orion_xg.mid
> 
> May I suggest a change in
> 
>src/fluid_synty.c:  fluid_synth_program_change()
> 
> changing the two lines near the end from:
> 
>fluid_channel_set_sfontnum(channel, sfont_id);
>fluid_channel_set_preset(channel, preset);
> 
> put an extra check that "preset" is not NULL first, to become:
> 
> if ( preset ) {
>fluid_channel_set_sfontnum(channel, sfont_id);
>fluid_channel_set_preset(channel, preset);
> }
> 
> It would take care of the case when the preset is NULL, which is the case 
> when the loaded soundfonts doesn't have the prognum.
> 
> From what I understand in XG sounds, the same prognum for different 
> soundbanks are the same type of instrument.  In the simplest case, it can 
> simply be same instrument with different effects.
> 
> The suggested change doesn't guarrantee the same type of instrument, just 
> keep the already loaded instrument in that channel.  Currently it sets the 
> channel to point to invalid, non-existing instrument.
> 
> Preferably, FS should try to find any soundbank with that prognum and use 
> that instrument instead.  Maybe you can decide what best to do here.
> 
> Thanks,
> 
> Jimmy
> 
> 
> 
>   
> 
> 
> ___
> fluid-dev mailing list
> fluid-dev@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/fluid-dev



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development

[Josh Green]

I probably shouldn't say too much, until I see what Antoine's solution
is..  But..

On Tue, 2009-01-27 at 03:04 +0100, Bernat Arlandis i Mañó wrote:
> >  It makes sense to me to
> > process the audio based on the audio playback.  This would lead to
> > identical playback between successive renders of a MIDI file, which is
> > what we want.
> This could be the only advantage I can think of, but it would be only 
> reproducible in the same hardware, driver and audio buffer size setup. 
> If you're thinking on case testing then the only solution is non-RT 
> rendering.

Indeed, it seems like it is the most useful for non-RT rendering.  I
think the issue that Antoine was originally trying to fix was related to
the Windows DSound driver implementation processing a lot more data than
just an audio buffer, which really seems like a driver issue to me.

> >   I don't see a problem with this change and I think it
> > would vastly improve things.  There might be a little more overhead as
> > far as MIDI event processing, but it would lead to more accurate timing
> > as well.
> >
> >   
> This would worsen latency since the core thread would have to do more 
> work at the critical point where the sound card is waiting for data. 

Hmmm.  Not if you are simply using the number of samples played out of
the sound card as a timing source.  Or am I still overlooking something.
It seems to me like using a system timer for MIDI file event timing
(something that has different resolutions depending on the system) is
going to be a lot less reliable than using the sound card time.  Again
though, I agree that this probably only benefits MIDI file
playback/rendering.

> Besides, I don't think having the MIDI file player depending on the 
> audio driver is good.
> 

What about just using it as a timing source?  I still haven't thought it
all through, but I could see how this could have its advantages.

> And, please, this shouldn't be taken as disrespect to Antoine's work, 
> I'd still have a look at it to see what he has really accomplished.
> 
> I think it's cool having this discussion now, since you're the 
> maintainer and you'll want to have some control in the future 
> development, it's logical. I'd like to know how good we work it out when 
> we don't agree. :)
> 
> Cheers.

Well I'm not particularly attached to how things go, just as long as we
do the "right thing" (TM) and KIFS (Keep It F.. Simple) ;)

Cheers.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development

[Josh Green]

On Tue, 2009-01-27 at 01:12 +0100, Bernat Arlandis i Mañó wrote:
> > About new development, there is an improvement to fluid that I had  
> > worked on two years ago in a private branch that I think should be  
> > integrated inside the main code base. I don't know if it should be  
> > integrated into 1.x or 2.x, because it changes the API a bit.
> > 
> > The bug is with the sequencer : in short, the sequencer uses the  
> > computer clock to trigger its sequenced events, whereas the audio  
> > buffers are requested and created by the soundcard when it needs
> > them  
> > which may be ahead of realtime, resulting in events not being  
> > triggered at the right moment in the audio stream. The fact is that
> > in  
> > real life, audio cards do request audio buffers ahead of time,  
> > sometimes a lot ahead, in bulk (like 16 buffers at once), thus not  
> > leaving time for the sequencer to trigger its events at the right  
> > moment in the audio stream.
> > I have fixed this by:
> > - making the sequencer use the audio stream as a clock
> > - calling the sequencer from the synth audio callback so that  
> > sequenced events are inserted in the audio buffer right before the  
> > audio is rendered
> > This implied a small change in the API because now the sequencer  
> > depends on the synth to get its clock (which was not the case
> > before).
> > 
> > How should I proceed to include it in the main code base ?
> > 
> > ++ as
> > 
> 
> Maybe I'm not understanding what he's done, but it sounds to me like
> he's talking about simple and well-known sound card latency. I don't see
> it related to what you're talking about.
> 
> I don't know why latency could be a problem playing midi files, maybe
> it's another problem. It might happen that his system timer has a low
> resolution and thus MIDI file playing is affected, I think fluidsynth
> tries to get a 4ms period system timer. In Linux you can solve this
> easily by setting up a higher system timer resolution in the kernel, I
> don't know about other systems.
> 

I think the difference is between clocking MIDI events in MIDI files
based on the system timer versus using the sound card as the timing
source (how much audio has been played back).  It makes sense to me to
process the audio based on the audio playback.  This would lead to
identical playback between successive renders of a MIDI file, which is
what we want.  I don't see a problem with this change and I think it
would vastly improve things.  There might be a little more overhead as
far as MIDI event processing, but it would lead to more accurate timing
as well.

Does this adequately describe your solution Antoine?

Best regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development

[Josh Green]

On Mon, 2009-01-26 at 15:10 -0500, Ebrahim Mayat wrote:
> ...and while we are on the topic of new development...one thing that has
> been on my mind for a while is the subject of effects plug-ins. For the
> last few releases, I have chosen not to add the option of LADSPA for the
> simple reason that this often causes spontaneous crashes particularly
> when running qsynth.
> 
> Since lv2 is the new alternative to LADSPA
> 
>  
> 
> I think that it would be a good idea to consider including lv2 as a
> feature that could be coded into the new branch. 
> 
> Such considerations would probably affect future planning.
> 
> E 
> 

Indeed, LV2 is a good item for 2.x inclusion.

I updated the Future of FluidSynth page (now titled FluidSynth 2.0):
http://fluidsynth.resonance.org/trac/wiki/Future

Everyone, feel free to add to this.  At some point we'll need to make
some decisions about priority and focus of tasks and some ideas may not
get addressed during the 2.x development cycle.

Best regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development

[Josh Green]

On Mon, 2009-01-26 at 09:43 +0100, Antoine Schmitt wrote:
> Le 25 janv. 09 à 23:14, Josh Green a écrit :
> > Things for the new 2.x branch:
> 
> 
> About new development, there is an improvement to fluid that I had  
> worked on two years ago in a private branch that I think should be  
> integrated inside the main code base. I don't know if it should be  
> integrated into 1.x or 2.x, because it changes the API a bit.
> 
> The bug is with the sequencer : in short, the sequencer uses the  
> computer clock to trigger its sequenced events, whereas the audio  
> buffers are requested and created by the soundcard when it needs them  
> which may be ahead of realtime, resulting in events not being  
> triggered at the right moment in the audio stream. The fact is that in  
> real life, audio cards do request audio buffers ahead of time,  
> sometimes a lot ahead, in bulk (like 16 buffers at once), thus not  
> leaving time for the sequencer to trigger its events at the right  
> moment in the audio stream.
> I have fixed this by:
> - making the sequencer use the audio stream as a clock
> - calling the sequencer from the synth audio callback so that  
> sequenced events are inserted in the audio buffer right before the  
> audio is rendered
> This implied a small change in the API because now the sequencer  
> depends on the synth to get its clock (which was not the case before).
> 
> How should I proceed to include it in the main code base ?
> 
> ++ as
> 

What you mention here addresses what I had listed as "Sub audio buffer
MIDI event processing" in that new things for 2.x branch list.  I had
not realized that there was any work done on resolving this.  Great!

Could you send me an archive of this branch?  Also, if you could
describe what part of the API it changes, that would be helpful, but I
could probably gather that from doing a diff on the sources as well.

This sounds like something that could be useful to integrate into 1.x.

Cheers.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development

[Josh Green]

On Mon, 2009-01-26 at 22:52 +0100, Pedro Lopez-Cabanillas wrote:
> I would like to find more time to work on the PortAudio driver, as it was my 
> plan for ticket #19. I will try, but don't hold your breath.
> 
> You are right: there is already a PortAudio driver, but it doesn't compile 
> with PortAudio V19. This version includes ASIO support (Mac OSX and Windows), 
> so we don't need to write another driver for it. Do you agree?
> 

Sure, if it satisfies the ASIO support, that would be great!  I'm not
too keen on writing a driver myself, it being windows and all ;)

> Regards,
> Pedro
> 

Cheers.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development

[Josh Green]

On Mon, 2009-01-26 at 12:06 +0100, Bernat Arlandis i Mañó wrote:
> Still, keep in mind that it's not my main goal splitting into separate libs
> but having good modularization to the point this would be really easy and
> practical.
> 

Sounds good.

> > libInstPatch *does* handle 24 bit audio and floating point as well.  Its
> > got its own audio managing for converting formats internally and what
> > not.  Swami and libInstPatch support 24 bit audio in SoundFont files.
> > FluidSynth does not.  That is what I would like to change.
> > 
> I'll need help there with libInstPatch integration. I don't know exactly
> what libInstPatch can do and what not, but using it seems a good idea.
> 

There is still a little work that I would like to do with libInstPatch
to bring it up to the task.  The sample caching code is what I have been
working on.  Swami loads instruments on demand, rather than a whole
SoundFont all at once.  I haven't yet implemented code for managing this
cache as it grows and freeing unused samples and what not, but its in
the works.

> > No that isn't quite right.  The SoundFont loader API is used for
> > synthesis in FluidSynth (not loading SoundFont files themselves).
> > libInstPatch and Swami do their own instrument management, but when they
> > want to synthesize those instruments, the SoundFont loader API is used.
> > This API abstracts the synthesis into a set of voices which can be
> > created by the application.  The voices have a list of SoundFont based
> > parameters, modulators and sample data.  In this way though, FluidSynth
> > can be used to synthesize any format, well at least within the confines
> > of SoundFont parameters.  Its a flexible API, but I think it could use
> > some cleanup and expansion of its capabilities (different audio formats
> > for example, like 24 bit).
> > 
> That's really interesting, this is what I like the least from FS.
> Theoretically this would help supporting every sound font format but it
> becomes a very hard thing to do mainly because when trying you'll be
> implementing a synthesis engine inside every font loader. There's another
> solution that would work best. Later on this.
> 

Actually, it seems to work pretty well abstracting instruments into
voices.  I think the way it is modeled is OK, its just that the API
needs some cleanup.  I'm not sure what you mean by "implementing a
synthesis engine inside every font loader".  If you mean, loading the
instruments into memory, calculating the parameters and creating the
appropriate voices when a note-on is pressed, that is what libInstPatch
and the FluidSynth Swami plugin does.

> > I'm starting to think having libInstPatch be a dependency could be a
> > good move.  libInstPatch is itself a glib/gobject based library.  It has
> > some additional dependencies, but most of them are optional (the Python
> > binding for example).  The components that would be of the most interest
> > would be the instrument loading and synthesis cache objects.  The cache
> > allows for the "rendering" of instrument objects into a list of
> > potential voices.  When a MIDI note-on event occurs, these voices can be
> > selected in a lock-free fashion, the cache is generated at MIDI program
> > selection time.  It seems like FluidSynth should be able to take
> > advantage of this code, whether it be used in something like Swami or
> > standalone.
> > 
> I really think all the sound font loader stuff should go there, after
> having moved the synthesis related parts to the synth component.
> 

I could probably get a libInstPatch enabled FluidSynth running pretty
quickly, since a lot of the code is already written.

> > I think the next question is.  When should we branch?  It probably makes
> > the most sense to release 1.0.9 and then branch off 2.x.  At some point
> > 2.x would become the head and we would make a 1.x branch.
> > 
> These should be totally independent, don't think of them as related in any
> way. We can branch when it's needed, and 1.0.9 can be released whenever you
> want. If you can wait a few days I'll kick off the new branch with a
> proposal and I'll also throw a couple fixes in, they started playing with
> the code but have become a bit more serious.
> 
> Usually, in most projects, new development goes to the trunk and stable
> releases are branches. However, since people here is used to having a
> stable trunk we can start the experimental 2.x in a branch.
> 

Sounds good.

> > Some decisions should be made about what remains to put into 1.0.9.
> > 
> > What of the following should be added?
> > - PortAudio driver (it exists, does it just need to be improved?)
> > - Jack MIDI driver
> > - ASIO driver
> > 
> That's another discussion, we should think about two different and
> independent development branches. Personally, I'm not interested, but
> someone might want to do them for 1.x and we could be merge them later in
> the 2.x branch.
> 

I'll see if I feel inspired to work on any of those in the com

Re: [fluid-dev] New development

[Josh Green]

On Mon, 2009-01-26 at 01:47 +0100, Bernat Arlandis i Mañó wrote:
> Specifically, on the modularization aspect I'd like to break FS down in 
> several libraries that could build separately if needed. This libraries 
> might be, guessing a bit: fluid-synth (the synthesis engine), 
> fluid-soundfont (sound font loader), fluid-midi (midi playing 
> capabilities incl. midi drivers), fluid-midir (midi routing), 
> fluid-audio (audio conversion utilities and output drivers, maybe LADSPA 
> too), fluid-ctrl (shell and server).
> 
> Some of these components could grow and become independent projects, in 
> particular I think midi routing could become a general library being 
> able to read routing rules from a XML file and with a front end for 
> editing these files. Some other components might just disappear if 
> there's some external one that can do the same.
> 
> Being able to break it down and build it like this would be a good 
> modularization test. It would also help 3rd party developers taking just 
> what they need and connect all the parts in more flexible ways than is 
> possible now.
> 
> In some way, the code has already been developed with this goals in 
> mind, so we're not that far. It's really difficult to fully reach these 
> goals in one try, or even two, but we're already somewhat close.
> 

I think breaking FluidSynth into multiple libraries would likely
needlessly complicate things.  However, I think keeping the code well
modularized is good and would make splitting things off into separate
libraries easy, if and when it seems like a good idea.

> > - 24 bit sample support
> > - Sample streaming support
> >   
> 24bit support is needed for complete SF2.04 support, and sample 
> streaming would be good too, specially with 24bit samples. I thought 
> this belonged to libInstPatch but no. These should be post-2.0.

libInstPatch *does* handle 24 bit audio and floating point as well.  Its
got its own audio managing for converting formats internally and what
not.  Swami and libInstPatch support 24 bit audio in SoundFont files.
FluidSynth does not.  That is what I would like to change.

> > - Sub audio buffer MIDI event processing
> >   
> This one would be hard and I think it would hit performance hard. I 
> don't think it's important to have such a high MIDI resolution. Talk 
> later about this, post-2.0.

I agree with this.  I think this was mainly an issue in regards to some
audio drivers not processing audio at the buffer size to which they are
set to.  That seems to be more of an issue with the sound driver though.

> > - Faster than realtime MIDI file to audio rendering
> >   
> When doing modularization, I'd like to implement external timing, that 
> is, synthesis and MIDI timing controlled by external functions. That 
> would make it really easy to do.

Yeah, I think most of the timing related stuff in regards to MIDI
playback happens in realtime, rather than holding a queue of timing
events.  This is one area though, where I am a bit in the dark as far as
the FluidSynth code base.  It would be nice though, to be able to render
a WAV file from a MIDI and SoundFont file and get the exact same audio
output, every time.  This would also be extremely useful in SoundFont
compliance testing, something that I think really needs to be done with
FluidSynth.

> > - Overhaul SoundFont loader API (used only by Swami as far as I know)
> >   
> This means Swami depends on FS Soundfont API, I thought libInstPatch 
> duplicated this functionality. This is in the pack then.

No that isn't quite right.  The SoundFont loader API is used for
synthesis in FluidSynth (not loading SoundFont files themselves).
libInstPatch and Swami do their own instrument management, but when they
want to synthesize those instruments, the SoundFont loader API is used.
This API abstracts the synthesis into a set of voices which can be
created by the application.  The voices have a list of SoundFont based
parameters, modulators and sample data.  In this way though, FluidSynth
can be used to synthesize any format, well at least within the confines
of SoundFont parameters.  Its a flexible API, but I think it could use
some cleanup and expansion of its capabilities (different audio formats
for example, like 24 bit).

> > - Leverage off of libInstPatch (optional dependency perhaps, maybe not?)
> > which would add support for other formats and flexible framework for
> > managing/manipulating instruments.
> >   
> You could certainly help a lot with this.

I'm starting to think having libInstPatch be a dependency could be a
good move.  libInstPatch is itself a glib/gobject based library.  It has
some additional dependencies, but most of them are optional (the Python
binding for example).  The components that would be of the most interest
would be the instrument loading and synthesis cache objects.  The cache
allows for the "rendering" of instrument objects into a list of
potential voices.  When a MIDI note-on event occurs, these voices c

Re: [fluid-dev] New development

[Josh Green]

On Sun, 2009-01-25 at 09:27 -0500, Ebrahim Mayat wrote:
> By "break compatibility backwards", do you mean that old soundfont files
> could not be parsed successfully ?
> 
> Perhaps you are talking about the linking of FS libraries to other
> programs like SWAMI, MAX/MSP and  fluid~ ?  
> 
> Thanks for keeping us informed.
> E

Its about breaking library compatibility and API compatibility.  But as
mentioned by Pedro, the old FluidSynth library can be installed along
side the new one.  So older applications will continue to work, but any
program which wants to take advantage of newer developments will need to
change their code to interface to the new library.

Hope that explains it well enough.  To the user, there shouldn't be a
lot of difference, except for the added functionality of FluidSynth 2.0
of course.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New development

[Josh Green]

Hello Bernat,

On Sun, 2009-01-25 at 13:41 +0100, Bernat Arlandis i Mañó wrote:
> This is concerning ticket #11.
> 
> I'm thinking on a lot of changes to take FS forward as I review the 
> source code and fix some things, but most of these changes would break 
> compatibility backwards. Maybe we should think about making a branch for 
> something that could be FS2.0. Fixes that break compatibility could go 
> there, what do you think? Or we could take intermediate steps that would 
> be 1.1, 1.2,... I think it's better working in gradual steps with public 
> releases.

> I'm willing to push development for that branch since I'm getting to 
> know its internals and I like working with it very much, but it wouldn't 
> be good to do it completely on my own without your expertise and the 
> users support. I don't want this to start a fork neither, so there has 
> to be an initial agreement that we all support this branch while it 
> accomplishes some goals or we all forget about it.
> 

I think creating a 2.x branch would be the way to go.  One of the things
that has made FluidSynth so successful, is that the API has been pretty
solid.  It is indeed also one of the reasons why it is difficult to move
forward, as you point out.  I think that the 1.x branch should continue
to be compatible as much as possible, at least at a code API level (just
requires a recompile, but no source changes on the part of other
software using FluidSynth).

Things for the new 2.x branch:
- Move to glib
- 24 bit sample support
- Sample streaming support
- Sub audio buffer MIDI event processing
- Faster than realtime MIDI file to audio rendering
- Overhaul SoundFont loader API (used only by Swami as far as I know)
- Design in a fashion which allows for additional instrument formats to
be supported, if desired (a Fluid instrument format?).
- Leverage off of libInstPatch (optional dependency perhaps, maybe not?)
which would add support for other formats and flexible framework for
managing/manipulating instruments.


I would imagine that as we work on the 2.x branch, the 1.x branch will
become less appealing to work on.  So it is likely that some of the
things which really should be done with 1.x, wont get done.  I think
this is OK though.  Other developers which use FluidSynth in their
applications will likely be more willing to change their own API code to
FluidSynth if it has lots of new features.  Those new features will be
easier for us to add, when the code base is more to our liking, so it is
to the benefit of all, for us to have the flexibility to change the API
as needed.  The 1.x can remain, with bug fixes and minor functionality
improvements, for those applications which don't move to the new version
immediately.

> I know it's a short time since I'm working with the code, but I'm 
> already playing with it and there are simple things that can't be done 
> without breaking backwards compatibility since the code exposes a lot of 
> internals and there's a highly coupling between some components. These 
> are issues that keep FS from evolving.
> 
> Opinions, please.
> 

Its very inspiring to have you so interested in development.  I've been
the maintainer for several years now and haven't been able to quite give
FluidSynth as much attention as it needs, and deserves.  I look forward
to working on a new FluidSynth with you, and whomever else has the will
and enthusiasm to do so :)

One thing I really want to get into, is creating a new instrument
format.  This is slightly off topic, but I think it would be good to
keep in mind this kind of possibility, as we develop FluidSynth 2.0.
I'm thinking something XML based, which uses splines for describing
waveforms, envelopes, oscillators, audio samples, etc.  Kind of a
Structured Vector Audio.  I think Fluid instruments would be a fitting
name for this format.  There is still a bit of work to do, before
exploring this realm.  But I'm really excited about developing such a
format and hearing it synthesized.

Cheers.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] news

[Josh Green]

Hello,

Great that you added channel pressure.  I wish I had a keyboard that
could test it out ;)

As for the velocity to filter cutoff issue.  There is a version field in
SoundFont files (ifil chunk).  If there are SoundFont files out there
which assume the broken velocity to filter cutoff modulator behavior,
perhaps they have version 2.01 in there.  Christian Collins sent a patch
in, which I believe addressed these issues.  So perhaps that ticket can
be flagged as fixed (any comments Christian?).

Thanks for all the contribution to the project, its rather inspiring.

Best regards,
Josh

On Thu, 2009-01-22 at 18:57 +0100, Bernat Arlandis i Mañó wrote:
> Hi. This is to inform you about a few things.
> 
> I've been commenting on some tickets, but since these changes don't show 
> in the timeline you might not know. Couldn't ticket comments appear in 
> the timeline?
> 
> See ticket #11, I've been trying to deal with this problem.
> 
> I've implemented channel pressure in SVN, you can check it if you have 
> an aftertouch keyboard.
> 
> Also, I've written a bit of documentation, although it's still 
> incomplete and badly structured. You can see it in the wiki.
> 
> Cheers.




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] A new beginning for the Resonance Instrument Database

[Josh Green]

Swami aims to be a SoundFont editor.  The older version 0.9.x generally
works, except for a crash bug I believe, but its rather un-appealing due
to being GTK1 based.  I'm working on getting Swami 2.0 ready for
release, but it is still lacking in some critical features.  Its been a
long time in development now, so I'm not sure when it will be ready.

Best regards,
Josh

On Wed, 2009-01-21 at 07:40 -0800, Ken Ellinwood wrote:
> I've been thinking recently about creating soundfonts.  Which tool/version 
> should I be starting out with on Linux?  Thanks,
> 
> Ken
> 
> 
> --- On Wed, 1/21/09, Bernat Arlandis i Mañó  wrote:
> 
> > From: Bernat Arlandis i Mañó 
> > Subject: Re: [fluid-dev] A new beginning for the Resonance Instrument 
> > Database
> > To: "Josh Green" 
> > Cc: "FluidSynth Devel" 
> > Date: Wednesday, January 21, 2009, 7:17 AM
> > That's great news! I hope this attracts soundfont
> > designers. See you there.
> > 
> > 
> > Josh Green escrigué:
> > > Hello,
> > >
> > > I'm happy to announce that the Resonance
> > Instrument Database is now
> > > ready for use.  Sorry to those who tried to use it in
> > the last year and
> > > found that it was broken.
> > >
> > > For those who are not familiar with this project.  It
> > is a deployment of
> > > the GPL project PatchesDB, part of the Swami
> > collection of projects.
> > > This software allows for the creation of an online
> > database for
> > > importing SoundFont, DLS and GigaSampler instruments. 
> > Some of the
> > > current features include:
> > >
> > > - User accounts
> > > - All sample and instrument names are imported from
> > files as well as
> > > other information (author, copyright, etc)
> > > - Ratings and comments on instruments
> > > - Any user can submit content
> > > - Searches
> > > - Browse by category
> > >
> > >
> > > There is still a lot of features planned (improve user
> > profiles,
> > > arbitrary tag words on instruments, improve licensing
> > information, etc).
> > >
> > > It hasn't had a lot of testing yet, so feedback
> > would be great.  I
> > > wanted to give it a little testing before announcing
> > it on the Linux
> > > Audio Announce list.  Submitting your favorite freely
> > distributable
> > > instruments, either ones you created or off the net,
> > would also be very
> > > helpful.
> > >
> > > Best regards,
> > >   Josh Green
> > >
> > > http://sounds.resonance.org
> > >
> > >
> > >
> > >
> > > ___
> > > fluid-dev mailing list
> > > fluid-dev@nongnu.org
> > > http://lists.nongnu.org/mailman/listinfo/fluid-dev
> > >   
> > 
> > -- 
> > Bernat Arlandis i Mañó
> > 
> > 
> > 
> > ___
> > fluid-dev mailing list
> > fluid-dev@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/fluid-dev
> 
> 
>   
> 
> 
> ___
> fluid-dev mailing list
> fluid-dev@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/fluid-dev



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

[fluid-dev] A new beginning for the Resonance Instrument Database

[Josh Green]

Hello,

I'm happy to announce that the Resonance Instrument Database is now
ready for use.  Sorry to those who tried to use it in the last year and
found that it was broken.

For those who are not familiar with this project.  It is a deployment of
the GPL project PatchesDB, part of the Swami collection of projects.
This software allows for the creation of an online database for
importing SoundFont, DLS and GigaSampler instruments.  Some of the
current features include:

- User accounts
- All sample and instrument names are imported from files as well as
other information (author, copyright, etc)
- Ratings and comments on instruments
- Any user can submit content
- Searches
- Browse by category


There is still a lot of features planned (improve user profiles,
arbitrary tag words on instruments, improve licensing information, etc).

It hasn't had a lot of testing yet, so feedback would be great.  I
wanted to give it a little testing before announcing it on the Linux
Audio Announce list.  Submitting your favorite freely distributable
instruments, either ones you created or off the net, would also be very
helpful.

Best regards,
    Josh Green

http://sounds.resonance.org




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Feature request: JACK MIDI

[Josh Green]

It has also been on my mind to add Jack MIDI support.  Maybe someone
will beat me to it? ;)
Josh

On Sat, 2009-01-10 at 17:56 -0500, Ebrahim Mayat wrote:
> Hello again
> 
> Both jack-0.116.0 and jack-keyboard compile successfully on OS X and
> Linux. So, I was wondering if it would be possible to also add JACK MIDI
> support for the next release. This could be a nice way to rout different
> MIDI inputs to multiple instances of fluidsynth particularly on OS X.
> 
> E
> 
> 
> 
> 
> 
> ___
> fluid-dev mailing list
> fluid-dev@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/fluid-dev



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Documentation

[Josh Green]

On Sat, 2009-01-10 at 17:59 +0100, Bernat Arlandis i Mañó wrote:
> Hi.
> 
> I've copied the fluidsynth man page to the wiki for a start. Although it 
> gets duplicated I think it will be easier to access it and review it 
> there. I've formatted it for the wiki without changing the section 
> layout so it's easy to track changes for the man page. If you think 
> there's a better way of doing it please tell me.
> 
> The man page seems to have an error, this definition gets cut when 
> viewing formatted, the last line here isn't shown:
> 
> .B router_chan min max mul add
> Limits the rule for events on min <= chan <= max.
> If the channel falls into the window, it is multiplied by 'mul', then
> 'add' is added.
> 

Good idea about putting the FluidSynth man page on the Wiki.  I fixed
the problem with that part of the man page.  Looks like the line that
begins with 'add' was the issue, so I just moved it to the end of the
previous line.

Best regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] About documentation and code

[Josh Green]

On Fri, 2009-01-09 at 21:02 +0100, Bernat Arlandis i Mañó wrote:
> Josh Green escrigué:
> >
> > Really?  Seems pretty standard to me.  Toplevel is branches/, tags/ and
> > trunk/.  Under trunk is the fluidsynth/ directory.  What did you have in
> > mind?
> >   
> Normally, the fluidsynth directory is on the top, that saves a lot of 
> fluidsynth directories. If there's no intention of putting more projects 
> in the same repository it could be left out too. Anyway, if it makes 
> sense to you like it is there's no real need to change it, don't worry, 
> I didn't want to sound picky.
> Let's move to other more interesting things. :)


Indeed lets do that ;)  There might be other components in the future in
the tree.  That was how the original CVS repository was setup, so I just
continued in that vein.  Shouldn't be much of a problem.

> -- 
Bernat Arlandis i Mañó


Cheers!
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] New CoreMIDI driver for Mac OSX

[Josh Green]

Hi Ebrahim,

On Fri, 2009-01-09 at 08:37 -0500, Ebrahim Mayat wrote:
> Hello Pedro
> 
> My deep gratitude for the CoreMIDI implementation. I managed to
> compile and run fluidsynth with CoreMIDI. 
> 
> 
> There are a couple of minor bugs that need to be ironed out. 
> 
> 
> 1. I had a slight problem checking out the latest sources:
> 
> 
> $ svn co https://resonance.org/svn/fluidsynth/trunk/fluidsynth
> Error validating server certificate for 'https://resonance.org:443':
>  - The certificate is not issued by a trusted authority. Use the
>fingerprint to validate the certificate manually!
>  - The certificate hostname does not match.
>  - The certificate has expired.
> Certificate information:
>  - Hostname: u15323830.onlinehome-server.com
>  - Valid: from Tue, 28 Oct 2008 23:49:24 GMT until Sat, 27 Dec 2008
> 23:49:24 GMT
>  - Issuer: Germany, DE
>  - Fingerprint:
> 2a:29:df:e3:b5:09:77:c0:b1:a5:f0:c5:a6:47:36:8d:7b:97:79:62
> (R)eject, accept (t)emporarily or accept (p)ermanently? 
> 

The FluidSynth services are now running on a new server, which appears
to not have a very good certificate at the moment.  I should create one.
It would likely just be a self signed cert at this point though.

> 
> 2. I modified the autogen script either by adding a space between "-I"
> and "/sw/share/local" or by taking out the definition
> for $ACLOCAL_FLAGS altogether in order to eliminate the error:
>  aclocal: unrecognized option -- `-I/sw/share/aclocal'
> 

So just adding a space between the -I and path works?

>   
> 3. Configure choked because there was no "m4" directory.
> 
> 
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> configure: error: cannot find macro directory `m4'
> 
> 
> So I simply added this directory to the top level one to get configure
> to run to completion. "m4" remains empty throughout the whole
> compilation. Is there any particular need for this folder ? 
> 

I just made some build changes in regards to libtool, which fixed the
build on my Ubuntu system.  When building in that environment there are
some .m4 files placed by libtool in m4/.  So all you had to do was
create the directory?  I guess an empty m4 folder could be checked into
subversion or perhaps the files are also supposed to be checked in.  I
have trouble keeping up with the evolution (or devolution) of
autoconf/automake/libtool etc.

> 
> I jsut did a brief test and external MIDI triggering via the "Virtual
> fluidsynth MIDI port" works beautifully.
> 

Good to hear.  Thanks to Pedro for coding this up!
 
> (I must add that I agree with Bernat. There is absolutely no need for
> unnecessary discussion on licensing issues. Flame-baiting is totally
> inappropriate.  With all due respect to Stephane, the CoreMIDI API is
> well documented with code examples and freely available online
>  ;
> i.e. no need to be "careful". In the spirit of true FOSS co-operation,
> Stephane very generously offered his input. Pedro and Josh very
> generously offered to implement this CoreMIDI functionality. Thanks
> again fellas.)
> 
> 
> I could do more extensive testing this weekend though judging by my
> initial experience, I do not expect any glitches.
> 
> 
> Sincerely,
> Ebrahim
> 
> Greetings,
> E
> 

Best regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] About documentation and code

[Josh Green]

On Fri, 2009-01-09 at 00:28 +0100, Bernat Arlandis i Mañó wrote:
> I think this would ease development in the long term by reducing the 
> amount of code. If you all agree we can entirely drop that "no external 
> dependencies" requirement unless there's some problem.

Changing the code to use glib is worth branching.  If there is nothing
else outstanding, then I'll make a FluidSynth release.  Then indentation
formatting followed by branching.

> > Indeed, using a standard code indentation/syntax would be nice.  I
> > personally like 2 space indentation, with braces always on a new line
> > and some other specifics (described by the indent command: indent -bli0
> > -sc -ncs).  Using spaces instead of tabs would be fine too.
> >   
> Overall, it seems like the code is already using a standard code 
> indentation/syntax. I'm flexible about which one to use, but it would be 
> easiest to follow what's already done and I think it matches your proposal.

Well its fairly close.  I personally don't like trailing braces like:

  if (blah) {
  }

Much prefer:

  if (blah)
  {
  }

Its just a heck of a lot more readable to me, especially when nested
several times.  Also dislike: char* var;  over  char *var;  but that is
more of a nitpick I suppose.

> I think we should branch stable releases and develop on the trunk while 
> fixing bugs in the stable branch. Other big changes could be done also 
> on their own branch until they're enough tested and stable to go to the 
> trunk.
> 

We can start with one branch for the glib conversion effort.

> I've noticed the SVN has a strange layout with much more directories 
> levels that needed. This is not all that important but if there's ever 
> going to be a fair amount of SVN activity and new developers we should 
> make a more logical arrangement. I can help with this since I have some 
> experience with SVN.
> 

Really?  Seems pretty standard to me.  Toplevel is branches/, tags/ and
trunk/.  Under trunk is the fluidsynth/ directory.  What did you have in
mind?

> I'll start with documentation on the wiki, I'll keep you informed on my 
> progress.
> 

Excellent!

> Best regards.
> 
> -- 
> Bernat Arlandis i Mañó
> 

Cheers.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Spreading fluidsynth as binary

[Josh Green]

On Thu, 2009-01-08 at 21:23 +0100, Pedro Lopez-Cabanillas wrote:
> Josh Green wrote:
> > On Wed, 2009-01-07 at 20:19 -0500, Ebrahim Mayat wrote:
> > > One workaround that I had suggested to Josh was to add CoreMIDI support
> > > to fluidsynth.
> > >
> > > E
> >
> > I remember now..  So adding CoreMIDI support is the key.
> 
> OK. Ticket #18 opened and assigned to me.
> http://fluidsynth.resonance.org/trac/ticket/18
> 
> Regards,
> Pedro

Great!  Let me know if you need any assistance with integrating with
FluidSynth.  Should be fairly straightforward though.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Spreading fluidsynth as binary

[Josh Green]

On Wed, 2009-01-07 at 20:19 -0500, Ebrahim Mayat wrote:
> On Wed, 2009-01-07 at 23:19 +0100, Pedro Lopez-Cabanillas wrote:
>  
> > I think that the best solution would be to properly package Fluidsynth, 
> > maybe 
> > as a Fink package, and also the applications depending on it. Not sure why 
> > there is not a Fluidsynth package in Fink yet.
> 
> Fluidsynth was submitted as a fink package a year ago but since this
> required an external MidiShare installation with respect to the fink
> assigned /sw directory, it was suggested that an additional midishare
> package for fink was required. This turned out to be a problem since the
> task of preparing a fink MidiShare installation consisting of three
> Cocoa apps, configuration files and drivers in addition to the MidiShare
> framework is rather complicated to say the least.
> 
> One workaround that I had suggested to Josh was to add CoreMIDI support
> to fluidsynth.
> 
> E
> 

I remember now..  So adding CoreMIDI support is the key.

Regards
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Spreading fluidsynth as binary

[Josh Green]

Ebrahim Mayat (also on this list) has been providing testing and
documentation for FluidSynth on Mac OS X for some time now.  He
submitted a Fink package a while back, I'm not sure what the status of
that is though.  Maybe Ebrahim will chime in?

Regards,
Josh

On Wed, 2009-01-07 at 23:19 +0100, Pedro Lopez-Cabanillas wrote:
> Felix Krause wrote:
> > Hi,
> > I am developing an application that uses fluidsynth. I want to spread it as
> > binary for Windows and MacOSX. As for Windows, there seems to be no problem
> > with simply spreading the fluidsynth.exe and the fluidsynth.dll along with
> > my application. But on MacOSX, this doesn't work. I already figured out
> > that the destination system needs to have midishare installed. On my Mac,
> > fluidsynth works of course, because I compiled and installed it on this
> > system. But I don't have a second Mac for testing purposes, so all I know
> > is that fluidsynth doesn't simply run on another Mac by copying the binary
> > and installing midishare.
> >
> > Can someone provide information about what whether - and how - it is
> > possible to spread fluidsynth as binary for Mac? The target user group of
> > my application won't probably be able to build fluidsynth from source,
> > that's why I need to spread it as binary.
> >
> > Cheers,
> > Felix
> 
> Hi Felix,
> 
> I'm not sure to fully understand your problem. In Windows you can install a 
> dynamic library (DLL) in two ways: first, as a private library, when you 
> place the library at the same directory of the executable using it. This is 
> how QSynth setup package installs fluidsynth.dll and also the Qt4 libraries. 
> The second way is system-wide, when you install the libraries somewhere in 
> the system PATH. Any program can access the libraries installed in this way, 
> with the advantage of saving disk space, and the drawback of possible 
> DLL-hell problems, when another setup package replaces an existing library 
> with another version.
> 
> In Mac OSX the first approach of installing the libraries at the same 
> directory of the executable doesn't automatically work. As a workaround, you 
> can set the environment variable DYLD_LIBRARY_PATH pointing to the directory  
> before running the program. 
> 
> I think that the best solution would be to properly package Fluidsynth, maybe 
> as a Fink package, and also the applications depending on it. Not sure why 
> there is not a Fluidsynth package in Fink yet.
> 
> Regards,
> Pedro
> 
> 
> ___
> fluid-dev mailing list
> fluid-dev@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/fluid-dev



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] running server on Windows

[Josh Green]

Yes.  Should be added to the ticket tracker.  If no one gets around to
it by this weekend, I'll add it.
Josh

On Wed, 2009-01-07 at 18:02 +0100, Bernat Arlandis i Mañó wrote:
> In this case this should go to the ticket tracker for future
> implementation. Anyone for confirmation?
> 
> Ken Ellinwood escrigué:
> > Nada,
> >
> > If I remember correctly the server is disabled for the Windows build 
> > because the code for this feature uses Unix file descriptors for the 
> > sockets and does regular read()/write() on the sockets.  None of that works 
> > on Windows where a first class socket object must be created and 
> > send()/recv() used instead.
> >
> > Ken
> >
> > --- On Mon, 12/29/08, Nada Amin  wrote:
> >
> >   
> >> From: Nada Amin 
> >> Subject: [fluid-dev] running server on Windows
> >> To: fluid-dev@nongnu.org
> >> Date: Monday, December 29, 2008, 10:21 AM
> >> Hello,
> >>
> >> I am trying to get the fluidsynth server to work on
> >> Windows. I use the
> >> version bundled with QSynth.
> >> When I run fluidsynth with
> >> fluidsynth -is VintageDreamsWaves-v2.sf2
> >> the command seems to exist immediately and I get an error
> >> (impossible
> >> to connect to host) when I then run
> >> telnet localhost 9800
> >>
> >> Still, if I just run
> >> fluidsynth VintageDreamsWaves-v2.sf2
> >> I am able to send notes and hear them.
> >>
> >> However, I'd like to run fluidsynth as a server so that
> >> I can send
> >> notes from Python using telnet.
> >>
> >> What am I doing wrong?
> >>
> >> Thanks. Best Regards,
> >> ~n
> >> --
> >> Nada Amin
> >> namin.net
> >> +41.22.734.31.36
> >> +41.79.275.15.35
> >>
> >>
> >> ___
> >> fluid-dev mailing list
> >> fluid-dev@nongnu.org
> >> http://lists.nongnu.org/mailman/listinfo/fluid-dev
> >> 
> >
> >
> >   
> >
> >
> > ___
> > fluid-dev mailing list
> > fluid-dev@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/fluid-dev
> >   
> 



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] About documentation and code

[Josh Green]

Hello Bernat,

On Wed, 2009-01-07 at 18:00 +0100, Bernat Arlandis i Mañó wrote:



> Could we start this kind of manual in the wiki? Some of you will know a
> lot better about fluidsynth so you can join me or just review what I do.
> 

The Wiki is perfect for that kind of undertaking.  Improving the inline
documentation is a good one too.

> Besides, some things to note about the code so far:
> - It has a disabled and (apparently) non-working implementation for
> LADSPA output filters that could be interesting for some uses, specially
> when embedded in other apps. Maybe even channel chorus and reverb
> effects could be fully implemented as external LADSPA plugins as an
> option, although feasibility and performance should be checked.

LADSPA was indeed working at one point, but I believe currently has some
stability issues, which I didn't get around to looking into.  It would
be nice to get it up and running again and properly document the syntax
for adding plugin effects.

> - It has a number of functions that seem obsolete, probably leftovers
> from old implementations. Mainly duplicated functions that were probably
> used to check changes, but also pieces of code of (old?) missing features.

Originally the author (Peter Hanappe) did not want FluidSynth to have
any external dependencies.  In particular the SoundFont loading code was
borrowed from my previous application Smurf SoundFont Editor and also
Swami.  Rather than depending on the glib library, he opted to include
some of this code into the application directly.  I think glib is a
fairly minor dependency though these days and it runs on just about
every currently supported FluidSynth platform.  I think it would clean
up a lot of the code to use glib and would provide some of the
portability features that are currently kludged into FluidSynth.

> - There's a feature that allows to output reverb and chorus in separate
> lines to Jack. I don't think this is used very much, it doesn't seem to
> work from the QSynth version I have. Some code could be disabled when
> this feature is off to save some cycles. In general, it seems like some
> barely used or even extinct features might have some code executing for
> nothing.

That is new to me ;)

> - In general the code seems in very good shape for collaborative work,
> except that some files have tabs and spaces mixed thus breaking the
> indentation. Using just spaces and good indenting is considered good
> practice for better collaboration. Submitters should configure their
> editors to put spaces instead of tabs and we could fix existing tabs in
> one go or along the away.
> 

Indeed, using a standard code indentation/syntax would be nice.  I
personally like 2 space indentation, with braces always on a new line
and some other specifics (described by the indent command: indent -bli0
-sc -ncs).  Using spaces instead of tabs would be fine too.

FluidSynth is a bit overdue for a release.  Provided everything seems to
be working as it should (feedback anyone?), a release could be made and
then indent could be run on all the code and checked in.  That would
give us a new start as far as formatting is concerned.

> After documenting features and fixing bugs, I think the next best thing
> coud be cleanning the code up a bit from all unused code. This would
> pave the way for further development.
> 
> I can try to put my hands on some of these, but I'd like to hear any
> comments first.
> 
> Happy new year!
> 

Sounds good to me!  You seem to be a good candidate for a FluidSynth
subversion account.  If you are interested, email me personally your
desired login information.

Happy new year to you as well.
Josh Green




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Tuning (forget my last message)

[Josh Green]

Hello Bernat,

Great to hear that it is working for you!  As for debugging, if you pass
the ./configure script --enable-debug, then it will build it with
debugging symbols turned on.  I think it turns off optimization too,
which will make for a rather significantly un-optimized build of
FluidSynth.

Cheers.
Josh


On Fri, 2008-12-26 at 19:09 +0100, Bernat Arlandis i Mañó wrote:
> Bernat Arlandis i Mañó escrigué:
> > Well, I've tried compiling from the SVN trunk but none of the three 
> > RPN controllers have worked. I've look at the new code and everything 
> > seems in place.
> > ...
> >
> Forget all the bullshit I said above, it works great!
> 
> I still had a previous fluidsynth library lying around that was getting 
> loaded instead of the new one. I need to refresh some of my Linux 
> programming skills, and MIDI knowledge too.
> 
> I've checked all the three new controllers and they seem to do what they 
> should, it's just what I needed right now, fantastic.
> 
> Thank you again.
> 



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Tuning

[Josh Green]

Hello Bernat,

I added support for the following RPNs:
00: Bend range (MSB only, in semitones)
01: Fine tune (MSB and LSB +/- 50 cents, center at 8192)
02: Coarse tune (MSB only +/- semitones, center at 64)

I did not test them though.  If you could try them out and let me know
if they work as expected, that would be great!

Along with these changes, I also checked in a new PulseAudio driver.

Best regards,
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Tuning

[Josh Green]

Hello,

It looks like FluidSynth currently supports SoundFont 2.01 NRPN numbers
for setting any effect generator in realtime (well most generators at
any rate), which you could use to set the fine and course tuning
parameters.  I looked at the code though and there is no handling of the
General MIDI RPNs.  I'll try and add these in the next few days, since
it shouldn't be that difficult to implement.
Josh

On Mon, 2008-12-22 at 10:54 +0100, Bernat Arlandis i Mañó wrote:
> Sorry, Josh and John, I took these numbers directly from my keyboard
> controller manual. It's the master tuning control, actually, it sends RPN
> controllers messages Master Fine Tuning (RPN 0,1) and Master Coarse Tuning
> (RPN 0,2). FluidSynth seems to ignore these controllers. Do you know any
> other way to change master tuning?
> 
> I'll take a look at the shell help, maybe I can learn something there, but
> I was trying to use midi controller messages so I could do it from the
> keyboard.
> 
> Thanks.



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Tuning

[Josh Green]

I don't think these messages are supported, although I seem to remember
seeing some FluidSynth code which dealt with tuning messages.  Just to
clarify though, are you referring to the MIDI Tuning specification?

http://www.midi.org/about-midi/tuning.shtml

This uses RPN dumps though and not controllers.  At the moment I'm a
little confused about your statement that it uses controller 129 and
130, since MIDI controllers only go up to 127.  Maybe I'm overlooking
something though, its been a while since I was messing with MIDI
directly.

Cheers.
Josh

On Sun, 2008-12-21 at 23:12 +0100, Bernat Arlandis i Mañó wrote:
> I'm trying to use the midi tuning controllers (129 and 130) but nothing
> happens. Does fluidsynth support these?
> 
> Is there a table of midi messages implemented?
> 
> Cheers.



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Future of FluidSynth

[Josh Green]

Hello Bernat,

I agree that major changes aren't really needed or necessary at this
point.  I would like to add additional features though, in a backwards
compatible manner when possible (24 bit audio, sample streaming, faster
than realtime MIDI rendering, etc).

I began documenting all functions with doxygen style comments (in the .c
files, rather than the .h files, which was how it was before).  This
will allow for Doxygen API generation.  I didn't get around to finishing
this effort though, as it isn't really that fun ;)  Its definitely
something on my list though.  Any contribution to this effort, in the
form of patches or what not, would be great.

Best regards,
Josh

On Sun, 2008-12-21 at 23:31 +0100, Bernat Arlandis i Mañó wrote:
> I've read this page in the wiki and some related messages in this list. 
> I think any decision should be taken by developers which know the 
> sourcecode well and are used to working with it. I wouldn't try big 
> changes now unless there's such a developers base.
> 
> I've always liked the idea of looking at the source and document it so 
> it's easier to work with. We would know more about implemented,  
> unimplemented and buggy features. Fixing bugs would be easier, besides, 
> this experience could help taking decisions and clear the way for bigger 
> changes in the future.
> 
> Are there any pointers to start the documentation process?
> 



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] resonance

[Josh Green]

Hello Philip,

I'm not sure exactly what could be causing that.  I know that reverb and
chorus can sometimes cause some adverse side effects, especially if the
settings for them are not good.  The low pass filter is another area
which could be causing this.  For the instruments which are causing the
issue, do they use the low pass filter?  Try messing with the reverb
and/or chorus settings to see if it helps.

Best regards,
Josh

On Tue, 2008-12-16 at 12:51 -0800, O. P. Martin wrote:
> 
> Hi, Josh,
> hi, Antoine,
> 
> Thank you for your help.
> 
> While I have you, there was another problem I was having.
> 
> All in all, FluidSynth is performing admirably well, and I am using it
> daily for worship.
> 
> The problem is that there seems to be a peak resonance at 'E' at high
> frequencies that is unpleasant to the ear.  I am avoiding the fuller
> stops on the organ because the high E's are too loud.  This is not a
> problem with the same soundfonts outside Fluid or with other source
> material.
> 
> Do you have any ideas what could be causing it and how to fix it?
> Would it have to do with the audio driver or maybe the reverb
> settings?  The bass seems weak.  Are there eq settings?
> 
> Thank you.
> 
> May the Lord bless you,
> Philip
> 
> 
> Josh Green wrote: 
> > Hello Philip,
> > 
> > When using the ALSA sequencer MIDI driver there is the option of setting
> > channels to a multiple of 16 (synth.midi-channels), which will create
> > one ALSA MIDI port per 16 channels.
> > 
> > As for setting panning on a per note basis..  This is possible to do
> > with the SoundFont loader API in FluidSynth.  This would require that
> > you write your own SoundFont loader for FluidSynth, which is what Swami
> > does, since it does its own instrument management (the Swami FluidSynth
> > plugin might be useful as a reference, at least in regards to the
> > loader).
> > 
> > You could use libInstPatch to make this easier (already has a SoundFont
> > loader and system for converting instruments to lock/malloc free voice
> > caches for use with FluidSynth).  In the noteon handler for the loader,
> > you would then override the panning SoundFont generator when creating
> > the FluidSynth voices.  The libInstPatch API is unfortunately not yet
> > stable, although I'm working to make that happen.  Let me know if you
> > would like to try this option and I can help you with it.
> > 
> > Best regards,
> > Josh
> > 
> > 
> > 
> > 
> > On Tue, 2008-12-16 at 11:16 -0800, O. P. Martin wrote:
> >   
> > > Hi,
> > > 
> > > Thank you guys for bringing this up.  I would like to be able to
> > > control not only pan but also tuning on a per-note basis.  Channel
> > > level control is a limitation of Midi.  Function call entry points to
> > > FluidSynth which optionally rise above Midi would be nice.
> > > 
> > > In the mean time, is it not possible to have multiple instances of
> > > Fluid, each with a number of channels?  It may be.  Also, is it
> > > possible to recompile to increase the number of channels?  I haven't
> > > looked.  Perhaps a #define?
> > > 
> > > Merry Christmas.
> > > 
> > > May the Lord bless you,
> > > Philip
> > > 
> > > 
> > 
> > 
> > 
> >   
> 



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] note panning

[Josh Green]

Hello Philip,

When using the ALSA sequencer MIDI driver there is the option of setting
channels to a multiple of 16 (synth.midi-channels), which will create
one ALSA MIDI port per 16 channels.

As for setting panning on a per note basis..  This is possible to do
with the SoundFont loader API in FluidSynth.  This would require that
you write your own SoundFont loader for FluidSynth, which is what Swami
does, since it does its own instrument management (the Swami FluidSynth
plugin might be useful as a reference, at least in regards to the
loader).

You could use libInstPatch to make this easier (already has a SoundFont
loader and system for converting instruments to lock/malloc free voice
caches for use with FluidSynth).  In the noteon handler for the loader,
you would then override the panning SoundFont generator when creating
the FluidSynth voices.  The libInstPatch API is unfortunately not yet
stable, although I'm working to make that happen.  Let me know if you
would like to try this option and I can help you with it.

Best regards,
Josh




On Tue, 2008-12-16 at 11:16 -0800, O. P. Martin wrote:
> 
> Hi,
> 
> Thank you guys for bringing this up.  I would like to be able to
> control not only pan but also tuning on a per-note basis.  Channel
> level control is a limitation of Midi.  Function call entry points to
> FluidSynth which optionally rise above Midi would be nice.
> 
> In the mean time, is it not possible to have multiple instances of
> Fluid, each with a number of channels?  It may be.  Also, is it
> possible to recompile to increase the number of channels?  I haven't
> looked.  Perhaps a #define?
> 
> Merry Christmas.
> 
> May the Lord bless you,
> Philip
> 




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Loading soundfonts from ram

[Josh Green]

Hello,

Swami (http://swami.resonance.org) does its own instrument handling
using the FluidSynth SoundFont loader API.  You could have a look at
src/plugins/fluidsynth.c to get an idea of how this works, although it
might be difficult to sort out the parts you want versus the rest of the
code.  All the sfloader_* functions are related to it though.

Path to fluidsynth.c in Swami subversion:

http://swami.resonance.org/trac/browser/trunk/swami/src/plugins/fluidsynth.c

Best regards,
Josh

On Sun, 2008-11-02 at 22:05 +0100, thomasg wrote:
> Hi,
> 
> I'm currently using a fluidsynth instance in a application (using the
> midi api) and load the soundfront directly from a sf2-file (using
> fluid_synth_sfload).
> Now I want to change that and load a file directly out of the ram. I
> have soundfonts in a kind of db and get a void-pointer (+ size) to the
> data of every file in the db.
> Is there a possibility to use the soundfonts like I did until now and
> only change the way of loading?
> The ramsfont api didn't look appropriate.
> 
> Thanks in advance,
> 
> thomasg
> ___
> fluid-dev mailing list
> fluid-dev@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/fluid-dev



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Dealing with startup

[Josh Green]

Hello Gerald,

On Tue, 2008-10-14 at 11:18 +0100, Edenyard wrote:
> I had the same problem when putting together a system using Fluid and 
> Jorgan and I devised a Bash script to make the necessary connections 
> after loading Fluid but before loading Jorgan. (I've shown the script 
> below between the lines of #s).
> 
> However, although it works, it seems to cause another problem: it seems 
> to slow down the loading of my soundfont considerably. I wondered 
> whether that was something to do with the testing loop taking up too 
> many CPU cycles that should have been used on Fluidsynth's loading. I'm 
> not much of a programmer (as my script probably reveals) and I'm 
> somewhat stuck to know what the solution is. For now, I've resigned 
> myself to accepting the very l-o-n-g SF load time but it would be nice 
> to be able to speed it up a bit. For reference, the SF2 file is about 
> 275 Mb in size.
> 
> Any clues would be very gratefully received. I only just cope with Bash 
> scripts so I don't think that I could handle anything of a higher nature!
> 
> Cheers,
> Gerald
> 
> # Script to connect Fluidsynth once it's running 
> 
> #!/bin/bash
> ###
> ### Connect Fluidsynth to VirMIDI.
> ### 7/9/2005.
> ###
> echo "Waiting for Fluidsynth . . ."
> while true
> do
>aconnect -o | grep "Synth input port" > /dev/null
>FINDFLUID=$?
>if [ $FINDFLUID -eq 0 ]
>then
>  echo "Fluidsynth running!"
>  break
>fi

 sleep 0.2

> done
> echo "Connecting Fluidsynth to Virtual MIDI . . ."
> sleep 0.2
> aconnect "Virtual Raw MIDI 1-0":0 FLUID:0
> aconnect "Virtual Raw MIDI 1-1":0 FLUID:1
> aconnect "Virtual Raw MIDI 1-2":0 FLUID:2
> CONNECTFLUID=$?
> if  [ $CONNECTFLUID = 0 ]
> then
>echo "Fluidsynth connected!"
> fi
> 
> 
> #
> 
> 

The first "while true" loop is essentially a busy loop, since it will be
executing acconect and checking its value as fast as it can.  Adding a
sleep inside of the loop (like I added above), should help things.
Josh




___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] How to send manual midi commands to fluidsynth from another program?

[Josh Green]

Hello,

As Pedro suggested, you could control FluidSynth via TCP/IP.  If you
want finer grained control over FluidSynth and don't mind writing C
code, then you could use FluidSynth as a shared library.  This is how
Swami and QSynth use FluidSynth.

Best regards,
Josh


On Sun, 2008-10-12 at 12:50 +, John O'Hagan wrote:
> Hi,
> 
> I'm writing an algorithmic music program which generates lists of numbers 
> representing notes and durations. The results can be printed as scores and 
> played as midi files using lilypond, and to play the results as they are 
> generated (i.e., bar by bar), I'm using the sox synth.
> 
> That's pretty limited, however, so I thought that fluidsynth might be the way 
> forward. 
> 
> The simplest solution would be to translate my number lists into noteon 
> commands, etc, and pipe them to fluidsynth.
> 
> But I need a little help understanding the fluidsynth shell. 
> 
> When that is active, I can type commands in, but I cant figure out how to 
> pipe 
> them from my program. I tried sending a file object to stdout but it seemed 
> to just disappear. Also, when I try to run fluidsynth with the -i switch, (no 
> shell), it seems to start up, then immediately exit.
> 
> I can get a result by translating my data  into a text-to-midi program, then 
> piping that to, say, pmidi, which plays via fluidsynth, but that seems very 
> roundabout.
> 
> Any advice?
> 
> Regards, 
> 
> John O'Hagan
> 
> 
> ___
> fluid-dev mailing list
> fluid-dev@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/fluid-dev
> 



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Some Questions About FluidSynth MIDI Player

[Josh Green]

Hey Julien,

Just some more clarity on licenses..  First, FluidSynth is under the
LGPL.  Indeed the GPL does not forbid incorporation in a commercial
product, as long as the source code is not linked or included directly
in another program (i.e., it is used as a stand alone application).  The
LPGL on the other hand permits linking as a shared library.  At any
rate, I don't think we should turn the FluidSynth list into a discussion
on licenses, beyond the scope of FluidSynth ;)  As a side note though, I
think originally LinuxSampler had an additional custom clause in its
license that forbid any sort of commercial use (perhaps this is no
longer the case?).  I remember some controversy over this, since that
could indeed also forbid distribution by Linux distribution companies.
Since Benno is a copyright holder of the software, he has the right to
re-license its use, to be used in a commercial application.

Best regards,
Josh

On Tue, 2008-09-30 at 18:42 +0200, Julien Claassen wrote:
> Hi!
>I think fluidsynth is GPL as well. and if I'm not wrong - having had and 
> heard endless discussions on linux audio users and developers mailinglists - 
> GPL does not forbid incorporation in a commercial product. that why 
> LinuxSampler isn't exactly GPL, because Benno Senona has his own commercial 
> product, in which he incorporates LinuxSampler. So this should be no problem.
>Kindest regards
>   Julien
> 
> 
> Music was my first love and it will be my last (John Miles)
> 
>  FIND MY WEB-PROJECT AT: 
> http://ltsb.sourceforge.net
> the Linux TextBased Studio guide
> === AND MY PERSONAL PAGES AT: ===
> http://www.juliencoder.de
> 
> 
> ___
> fluid-dev mailing list
> fluid-dev@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/fluid-dev
> 



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [fluid-dev] Some Questions About FluidSynth MIDI Player

[Josh Green]

Hello Peter,

I just wanted to make sure you are aware of some of the implications of
using software under the LGPL, like FluidSynth, in a commercial
application.  Since some of these things are overlooked at times.  The
LGPL allows commercial applications to link to it as a shared library.
However, including code directly from FluidSynth in a commercial
application which is distributed, is not permitted (unless the program
itself is made LGPL).  You could modify FluidSynth and link it with your
program, but any changes you make to FluidSynth would need to be
released back to the community, if you distribute it.  One of the things
that is often overlooked by companies (I myself have done a lot of
commercial projects utilizing open source software), is that even if no
modifications are made to an LGPL or GPL program, the source code for
those programs must still be made available to anyone who may ask for
it.  All these clauses are active only upon distribution of the
software.  If it is never distributed (used internally only) then none
of those clauses apply.

At any rate, perhaps you are already aware of those, just wanted to make
sure.  The LGPL may still work for you in your case.

Best regards,
Josh

On Tue, 2008-09-30 at 23:29 +1000, Zegelin Peter wrote:
> Thanks for your reply Julien,
> 
>   I've had a bit of a look at Timidity but unfortunately it is GPL and  
> can't be used in a commercial app. I've had a bit of a closer look at  
> the fluidsynth midi player and it looks like it will require quite a  
> bit of modification to work how I need it. I may end up just using the  
> timer part (which is probably the hardest part to get right) and synth  
> pieces and building my own player.
> 
> 
> On 30/09/2008, at 7:30 PM, Julien Claassen wrote:
> 
> > Hi!
> >  I don't know too much about fluidsynth's inner workings. But this:  
> > fluidsynth is mainly intended for live playing or simple midifile  
> > playback. Surely you could fool around, if you know bit about  
> > programming and MIDI, but I'm not sure, if that's what you want.
> >  I have - on more than one occasion - noticed, that fluidsynth's  
> > MIDI-file-player is very CPU-hungry. The crackle and stutter.
> >  If you need a good midifile-player, take a look at timidity. It can  
> > also play soundfonts, but in addition GUS-patches (its original  
> > format), it can pass midi thourhg to another MIDI output, it sets  
> > controllers correctly, you can start/stop rewind/forward. It also  
> > supports JACK, ALSA and a few other audio outputs. I think that  
> > timidity should work with OSX, I've definitely heard of Linux, other  
> > Unices and windows. Well OSX is a kind of Unix today.
> >  Drawback is: I think timidity's builtin reverb is not as nice as  
> > fluidstynth's. But you can turn it off.
> >  I hope it helps, although it answers in a completely different  
> > direction.
> >  Kindest regards
> >   Julien
> >
> > 
> > Music was my first love and it will be my last (John Miles)
> >
> >  FIND MY WEB-PROJECT AT: 
> > http://ltsb.sourceforge.net
> > the Linux TextBased Studio guide
> > === AND MY PERSONAL PAGES AT: ===
> > http://www.juliencoder.de
> 
> 
> ___
> fluid-dev mailing list
> fluid-dev@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/fluid-dev
> 



___
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev