> I'm not exactly sure what you mean here. There is no problem in statically
> linking BSD with LGPL code as long as you redistribute the entire source
> (BSD + LGPL parts) with your binary, right? So then it would not be the
> linking or the license combination that's the problem, it becomes only
On 2011-02-21 02:37, Matt Giuca wrote:
That's a good summary. I would just add one thing:
Can I include FluidSynth in my closed-source commercial project
I would add to this section "The same advice applies to projects
released under permissive licenses (e.g., BSD or MIT). Because such
license
That's a good summary. I would just add one thing:
> Can I include FluidSynth in my closed-source commercial project
I would add to this section "The same advice applies to projects
released under permissive licenses (e.g., BSD or MIT). Because such
licenses permit closed-source redistribution, th
There are a few licensing related questions which seem to come up once
in a while and it's sometimes difficult to remember what we have said
about them, so I wrote up a little wiki page about them:
https://sourceforge.net/apps/trac/fluidsynth/wiki/LicensingFAQ
Anything wrong/forgotten?
// Dav
Thanks very much David.
It was great working with you throughout the concept and implementation of
this new feature.
Also the adding an example in the documentation and for providing easy links
> in the email above was much appreciated!
>
No problem. I love Launchpad. I really recommend anyone w
On 2011-02-20 07:27, Matt Giuca wrote:
I have updated the midi-buffer branch with the previous two suggestions:
1. fluid_player_add_mem now copies the buffer before it stores it, so
the caller can now free it immediately (and it is now the caller's
responsibility to free).
2. Internally, fluid_mi
On 2011-02-20 15:06, Nils Hammerfest wrote:
Hello,
currently our software uses fluidsynth as an internal synth you can switch the
midi engine to jackmidi.
I wonder if we need this split (and double work). Is it possible to just
forward messages which are generate through the fluidsynth api (no
Hello,
currently our software uses fluidsynth as an internal synth you can switch the
midi engine to jackmidi.
I wonder if we need this split (and double work). Is it possible to just
forward messages which are generate through the fluidsynth api (not midi) as
midi messages via jack or alsa mi
