Hi Ken,
Of course IANAL, but naturally happy to share my opinion.
When talking about libLO, the website states:
"if you have a specific requirement for liblo in a close-source system then
mail me and I may relicense it on an individual basis."
Would the libLO people be prepared to relicense lib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I can't imagine the license being a problem. Doesn't everyone love the GPL? :-)
Besides, lots of LPGL programs link with GPL programs.
IIRC, the typical approach is to make it optional at build time via a
"./configure --disable-osc" flag, so that p
I added OSC support to FluidSynth one time using liblo and it was
pretty straightforward (I'll see if I can find the code). I meant to
submit the patch, but then I realized that liblo is GPL licensed while
FluidSynth is LGPL. I never got around to figuring out if there was a
way to resolve thing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 20, 2007 at 08:55:28PM +0200, Josh Green wrote:
> On Fri, 2007-04-20 at 19:42 +0200, Miguel Lobo wrote:
> > Hi Josh,
> >
> > Glad to hear you like the idea!
> >
>
Another thing to add to the list: OSC support, at least for the kind of
> > Yes, man page needs updating. Something to add to the list ;)
> > Josh
>
>
> You might be able to scratch that off the list too. Patch attached.
>
> -ken
Thanks for the patch. Cheers!
Josh
___
fluid-dev mailing list
fluid-dev@non
On Fri, Apr 27, 2007 at 08:46:43PM +0200, Josh Green wrote:
> On Fri, 2007-04-27 at 11:12 -0700, Ken Restivo wrote:
> > On Fri, Apr 27, 2007 at 07:54:32PM +0200, Josh Green wrote:
> > > I believe that functionality is already available:
> > > fluidsynth -f configfile.txt
> > >
> > > The config fil
On Fri, 2007-04-27 at 11:12 -0700, Ken Restivo wrote:
> On Fri, Apr 27, 2007 at 07:54:32PM +0200, Josh Green wrote:
> > I believe that functionality is already available:
> > fluidsynth -f configfile.txt
> >
> > The config file just contains commands like you would type at the
> > command prompt.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 27, 2007 at 07:54:32PM +0200, Josh Green wrote:
> I believe that functionality is already available:
> fluidsynth -f configfile.txt
>
> The config file just contains commands like you would type at the
> command prompt.
>
> fluidsynth --h
On Fri, 2007-04-27 at 09:30 -0700, Ken Restivo wrote:
> >
> > 1) Streaming to use less memory.
> >
> >
> > I'm not sure what this is. Perhaps reading the soundfont information
> > on-demand from disk instead of storing it in memory? Are soundfonts really
> > so big that memory pressure is a pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 27, 2007 at 12:24:09PM +0200, Miguel Lobo wrote:
> HI Ken,
>
> There are some uses of FluidSynth I'm not familiar with and I would like to
> know more about these use cases.
>
> For me, as a pretty heavy user of fluidsynth (it's my main i
Good suggestions, I generally agree with all of it :) I'm planning on
doing a GObject code up, just to see if it makes sense. It may indeed
be more complex than need be, but a lot of the work is already done, and
it would add things like properties and signals which would make
FluidSynth more usa
HI Ken,
There are some uses of FluidSynth I'm not familiar with and I would like to
know more about these use cases.
For me, as a pretty heavy user of fluidsynth (it's my main instrument), the
top things I'd request are:
Could you describe in a bit more detail how you use FluidSynth? Do you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 21, 2007 at 04:45:48PM +0200, Josh Green wrote:
> On Sat, 2007-04-21 at 12:29 +0300, Mihail Zenkov wrote:
> > Why we hear it only in 16 bits?
> >
>
> FluidSynth currently only has support for 16 bit samples. Swami uses
> the SoundFont lo
On Monday 23 April 2007 19:44, Miguel Lobo wrote:
> > function. Of course, one can do this with C++ (or OOP, in general)
> > ideas; but I'd say it should still be possible with C.
>
> I'm honestly curious; in the specific case I've mentioned, how would you
> achieve the same result in C without co
On Apr 23, 2007, at 9:38 PM, Miguel Lobo wrote:
Specifics please. Which versions and for which OSes.
I'm using MSVC.NET 2003 which can target Windows from 2000
(possibly earlier) on. I'm sure you can find more information in
the microsoft.com website.
> On the ones with 90%+ of the user
Specifics please. Which versions and for which OSes.
I'm using MSVC.NET 2003 which can target Windows from 2000 (possibly
earlier) on. I'm sure you can find more information in the
microsoft.comwebsite.
On the ones with 90%+ of the user base?
>
You are being vague again. The user base of wh
Argh, again I forgot to hit "Reply All". Sorry about the dupe Josh.
Well OSS supports Solaris, which means, yes!
Ok, didn't know that.
MSVC likely won't run on my ARM 9 based embedded system, but gcc sure the
hell will ;)
Well, I plan to support both g++ *and* MSVC. In fact I'm primarily
Three points:
Users of an OSS project are not necessarily what is known as "end
users" i.e. people who only want to run an application and have no
interest in how it is coded. In particular, the users I'm thinking
of for my project are OSS coders who need an embeddable synthesizer
for
On Mon, 2007-04-23 at 19:18 +0200, Miguel Lobo wrote:
>
> I actually knew that. On the other hand, many of those OSes won't be
> able to use Fluidsynth as long as it lacks an audio driver compatible
> with them. Fluidsynth has a Windows audio driver. Does it have one
> for Solaris? No? Then w
I've had a better look at the code you mentioned and I see what you mean:
it
does look like the code there isn't so well structured.
Not only that, those very long two functions I mentioned differ in only one
line. There are some other similar cases throughout the code.
I'd say the code need
Hi Miguel,
I'm afraid this is just a quick reply (to be polite!) as I've just caught the
tip-end of a work snow-drift.
On Friday 20 April 2007 14:33, Miguel Lobo wrote:
[...]
> I wanted to avoid a very detailed discussion of the current codebase,
> because I think it's likely to get too specific
You have forgotten one very important aspect: Before one can
contribute in terms of code; compile errors, runtime errors, bugs,
critical performance bottlenecks, maintenance problems, etc. have to
be identified. A program/app is only as good as its performance in
the real world. This feedback ca
On Apr 22, 2007, at 5:16 PM, Miguel Lobo wrote:
> Anyway, I believe in the usefulness of the "show me the code"
> approach in these situations. Many people have strong opinions on
> some technical issues, but not so many are usually willing to
> translate those opinions into actual working code
On Sun, 2007-04-22 at 17:47 +0200, Miguel Lobo wrote:
>
> Definitely. As I mentioned, that name was just meant as a joke and I
> hope nobody took it in any other way. In fact, I have already renamed
> the fork to something else completely Fluidsynth-unrelated.
>
Ok, I hadn't realized that na
On Sun, 2007-04-22 at 17:16 +0200, Miguel Lobo wrote:
>
> Sure. I just mean that talk is cheap. Technical flamewars on OSS
> mailing lists tend to involve many people with strong opinions, even
> people whose contribution to the project in question in terms of code
> are slim to none. That doe
> Anyway, I believe in the usefulness of the "show me the code"
> approach in these situations. Many people have strong opinions on
> some technical issues, but not so many are usually willing to
> translate those opinions into actual working code.
Hmm, interesting opinion. Could you be more sp
On Sat, 2007-04-21 at 21:13 +0200, Miguel Lobo wrote:
> Oh, my understanding from yesterday's discussion was that the decision
> had indeed been made. The belief in maintaining the statu quo seemed
> fairly strong around the list.
It didn't really seem like a decision was made to me, it was jus
It didn't really seem like a decision was made to me, it was just that
the overall consensus seemed to indicate that continuing to support
existing FluidSynth users is important. It sounds to me like you would
like to have your own FluidSynth based project which is coded in the way
that you woul
On Apr 21, 2007, at 9:13 PM, Miguel Lobo wrote:
Anyway, I believe in the usefulness of the "show me the code"
approach in these situations. Many people have strong opinions on
some technical issues, but not so many are usually willing to
translate those opinions into actual working code.
Well, I would say that the decision has not yet been made. I am leaning
towards continuing to use C, but I don't feel that it has really been
very well weighed out yet. The biggest issue is once again, who is
willing to program on FluidSynth. I'm not completely convinced that C++
is necessarily
On Apr 20, 2007, at 8:36 PM, Josh Green wrote:
I think the main thing that FluidSynth lacks currently is simply
active development. The project has been barely limping along
since I took over the maintainer-ship. It could really use, new
ideas and a well thought out direction.
Yeah, I a
On Sat, 2007-04-21 at 12:29 +0300, Mihail Zenkov wrote:
> Why we hear it only in 16 bits?
>
FluidSynth currently only has support for 16 bit samples. Swami uses
the SoundFont loader API, which just currently doesn't have support for
other formats other than 16 bit. It would take some changes to
On Fri, 2007-04-20 at 21:22 +0200, Miguel Lobo wrote:
> Ok, thanks. I don't know to which degree libInstPatch makes other
> instrument formats look like SoundFonts, but if the "abstract"
> libInstPatch instrument looks very different from a SoundFont's, kaing
> FluidSynth use it will be a big job
> - Other audio formats (floating point or 24 bit for example, new
> SoundFont 2.04 supports 24 bit, and now Swami/libInstPatch does too, but
> can only hear it in 16 bits!)
Why we hear it only in 16 bits?
> As for the question of platform. We have:
>
> A. Continue using C without any support
Hi Josh,
Its unfortunate that C and C++ have to be so divided in the world of
programming.
I agree, especially since C++ is 99% a superset of C and all the new
features are completely optional.
In the past the ABI unstability and incompatibility was a real problem for
C++ (although IMO much
Hello Miguel,
On Fri, 2007-04-20 at 20:50 +0200, Miguel Lobo wrote:
> Well then, since it seems there is some consensus on continuing
> Fluidsynth development in C, I'll go on with my project as a fork with
> a different name. Hope you guys don't mind me announcing public
> availability of my pro
On Fri, 2007-04-20 at 19:42 +0200, Miguel Lobo wrote:
> Hi Josh,
>
> Glad to hear you like the idea!
>
I like the general idea of doing some overhaul like activity :) I'm not
completely sure at this point if C++/QMake is the best direction for
"FluidSynth" though. I imagine its a platform you
I think if anything writing in C++ will make it easier to write bindings for
other languages, since those other languages are usually object-oriented
nowadays and their concepts are closer to C++ than to C.
I understand what you're getting at, but at least in my experience it
doesn't bear out.
Well then, since it seems there is some consensus on continuing Fluidsynth
development in C, I'll go on with my project as a fork with a different
name. Hope you guys don't mind me announcing public availability of my
project in this list (when and if that happens) and asking questions about
Flui
Having read over the responses of other users, I wanted to write a bit
more on my thoughts, since I think I was a bit hasty in my response to
Miguel concerning his changes.
I think the main thing that FluidSynth lacks currently is simply active
development. The project has been barely limping alo
Damn it, I forgot to do "Reply to All". Sorry about the dupe mail Josh.
-- Forwarded message --
From: Miguel Lobo <[EMAIL PROTECTED]>
Date: Apr 20, 2007 7:40 PM
Subject: Re: [fluid-dev] Fluidsynth changes
To: Josh Green <[EMAIL PROTECTED]>
Hi Josh,
Gla
Hello Miguel,
On Fri, 2007-04-20 at 00:31 +0200, Miguel Lobo wrote:
> Hi list,
>
> Since there's been a surge in the activity of this list recently, I
> thought I'd let you know about some work I've been doing on
> Fluidsynth, although it is by no means finished.
>
> Now, the changes I've done a
At the risk of rampant me-too-ism, I'll have to agree violently with Paul
Millar.
Not that there's any danger of my contributing significant code to the project.
I'm just a (very) old guy who can read and understand the C, and it's OOP
leanings
without the potential arcana of C++.
I also think t
Hi Paul,
Thanks for your comments.
OOP is very powerful programming methodology, facilitating concepts like
polymorphism. However, there seems to be a mass amnesia that other
languages
both exist and also work. OOP (and C++) code is not prima facie better
than
code written in a non-OOP langua
Hi Miguel,
Its always good to hear ideas about alternative approaches. I've some
comments I've included below.
On Thursday 19 April 2007 23:31, Miguel Lobo wrote:
>- Translating from C to C++, using classes and templates to increase
>code reuse where possible.
OOP is very powerful prog
Hi Marc,
Thanks for your comments.
I do believe, however, that a C++ Fluidsynth may not be quite as easy to
absorb and apply as a C Fluidsynth.
Once the C++ API is mostly stable I would like to provide C bindings to it.
They should be fairly easy to generate from the C++ headers, although to
Hello Miguel and thank you for your excellent work with Fluidsynth.
As a novice programmer who is making use of the Fluidsynth libs in a
new program, my reaction is mostly positive to these changes. The
only concerns I have are 1) to be sure that the move from C to C++ is
entirely worthwhile. Y
Hi list,
Since there's been a surge in the activity of this list recently, I thought
I'd let you know about some work I've been doing on Fluidsynth, although it
is by no means finished.
Now, the changes I've done are of the kind that flamewars are sometimes
started over, so let me begin with a l
48 matches
Mail list logo
