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
