Re: [fluid-dev] Soundfont banks

[jimmy]

> On Wed, 11 Jul 2012 , Matt Giuca <address@hidden> wrote:

> I've been observing this conversation, and while I do think
> the reaction to
> the original mail (on a completely different topic by a
> different
> contributor) was overly negative, there also has to be room
> in a software
> project to say "no."

I know.  I'm not a stranger to software development processes.


> My understanding of the project is that there aren't a lot
> of people
> contributing, nor do the people at the top have much time to
> give.
> Therefore, proposing drastic changes is probably not going
> to be feasible,
> even if it's theoretically a good idea.

Sure.


> It's more complicated than saying to the project leads "I
> don't expect you
> to deal with this, I'll do the research and the work." The
> problem is that
> ultimately, someone who "owns" the project will need to
> understand this
> stuff in order to accept it. They will need to review your
> patch and
> understand how it fits in with the overall system and the
> interests of many
> users. For example, whether including this patch will break
> other users in
> some obscure case, or whether it will pull in too many
> dependencies. If you
> are proposing a non-trivial amount of work for yourself to
> do, it
> *will*ultimately end up becoming a non-trivial amount of
> work for
> someone else as
> well.
> There's also the fact that if you submit it, you may not be
> around to
> maintain it, and then people like David will have to
> understand it even
> better to fix it when it breaks.

I know.  In fact, I'd prefer more "programmer's comments" in the code for 
posterity sake.  But some folks prefer to have comments elsewhere, or no 
comments in the code.  Heck, I waddle throught every piece of software trying 
to understand what the hey the original developer was thinking all the time.  
Much of those time, that's my own code :-}  That's why you hear developers 
always have announcements of code being restructured, optimized, or rewritten.


> I'm not trying to be a nay-sayer and block progress. I just
> want to make
> the point that sometimes, as a project lead, it isn't a good
> idea to embark
> on a large new feature with a contributor you don't know
> well, especially
> if you don't have much time to give to the project
> yourself.
> 
> In any case, getting angry doesn't help. It can be
> frustrating when nobody
> is accepting your patch. You should assume they have
> forgotten, as opposed
> to deliberately ignored you. It never hurts to wait a week
> and then post a
> follow-up: "Just checking if anybody has gotten around to
> looking at my
> patch yet?"
> 
> Matt

Well, the reason they pulled was just silly at best.  GM specs came out years 
before SoundFont specs.  Soundfont specs, to me was a partial implementation of 
GM specs, because their hardware (soundcards) capabilities were limited to the 
memory and chipsets they had at their disposal as well as budget and price 
point.  Their Soundfont specs only allow 128 soundbanks was their rights, I do 
give them that.  Doesn't mean I have to live with it and avoid the full GM 
specs at all costs.

Anyway, GM specs was even older and allows for [128x128] soundbanks.  In fact 
FluidSynth already have some code in place to deal with the GM specs in 
supporting the full [128x128] soundbanks via CC0/CC32 mechanism.  My patch 
simply save the "value" from the CC0 and CC32 message the way it should be, 
which is totally messed up in the current code base.  Plus, the internal 
variable storage area is already in place to hold these values.  It's not like 
I'm ripping out the current system with my 2-line patch.  Sure, further and 
more invasive changes in the code is needed for the full functionality, but 
that's not yet the point.

I also need those numbers kept and properly reported via FluidSynth console, so 
I can formulate a plan for tackling the full 128x128 soundbanks supports.  
Without such info, I'd be reading invalid soundbank numbers.  Again, FluidSynth 
already have the variable space to hold on to those information. 

I suppose they don't personally care for that.  Or choose to see from the 
Roland GS and Soundfont perspective that 128 soundbanks ought to be enought for 
anyone, the same way that 640KB ought to be enough for anybody. 

I saw that OSC querry being shot down, that's why I let them know don't have 
high hopes for new features in FluidSynth.  Heck, FS can't even support GM 
specs relating to CC0/CC32 from 40 years ago.  And GM has always been the 
de-facto standard for anything musical since.

It may be easy for someone to say to implement OSC as a new layer on top of 
FluidSynth, but there may be times when some features might be needed from 
FluidSynth to deal with the various info.

Outside the XG-mode via my earlier patch(es), there's no way to use multiple 
drum channels, except adding the full 16-channels, remember to differentiate 
those channels, may have to add rules to MIDI router of some sort, just to use 
that one extra drum channel.  Talking about twisted logic by some people with 
their GM-specs interpretation.  Sad, but true.

Jimmy