Re: [fluid-dev] FluidSynth tuning and more commits

[josh]

Quoting David Henningsson <address@hidden>:
> address@hidden skrev:
> > The reverb and chorus
> > fluid_synth_* routines are also problematic areas, since double floating
> > point values are being assigned, which aren't atomic on SMP machines.
> > This could potentially lead to synthesis glitches when values are being
> > assigned.
>
> Couldn't we just send them through the queue then, just as we do with e
> g synth gain?

That would probably be the right way to do it.  Perhaps sending each  
setting individually would be the easiest, though it wouldn't be  
possible to ensure atomic assignment of all reverb or chorus settings  
as a group then.  Adding a fluid_event type for all chorus or reverb  
parameters might be somewhat bloated though.  What do you think?

> > I'm a little bit perplexed in regards to the tuning routines though.  It
> > seems that it allows for arbitrary per MIDI note tuning modifications,
> > using floating point values in cents.  Tunings are added by instrument
> > bank and program #s.  What is strange, is that it seems these tunings
> > only take effect when fluid_synth_select_tuning() is called, to activate
> > an existing tuning on a given bank and program.  What is strange, is
> > that this is never called in the FluidSynth code base, meaning that
> > tunings will only be active if an external application activates them,
> > which seems to defeat the purpose of bank:program tuning assignment.  It
> > seems to me like a tuning should be automatically used when a
> > bank/program change occurs, if there is an assigned tuning for the given
> > bank/program.  The tuning infrastructure should probably also be
> > integrated with MIDI tuning standards, for assigning tunings via MIDI.
> > It seems like the tuning system is currently not entirely complete.  Any
> > opinions on this?
>
> After having read some of the stuff listed here:
> http://www.midi.org/techspecs/midituning.php
> ...some things clear a bit - then bank and prog numbers are not the same
> as the instrument banks and progs.
> What's actually missing, are calls to fluid_synth_select_tuning() from
> the RPN_TUNING_PROGRAM_CHANGE and RPN_TUNING_BANK_SELECT switches in
> fluid_synth_cc_LOCAL.


You're right about the tuning bank/preset #s not correlating to MIDI  
instrument bank/program #s.  I had suspected that was the case when  
glancing at the standard, but didn't make the connection that  
FluidSynth also currently treats them as separate, as it should.

In addition to implementing the tuning select RPNs, the SYSEX tuning  
messages would also need to be implemented, to be complete.


> Btw, what's also seems to be missing are implementations of
> DATA_ENTRY_INCR and DATA_ENTRY_DECR, for both RPN and NRPN...?


Yeah, I think you are right!  I wasn't even sure how this should be  
implemented, but this document seems to give somewhat of a clue:
http://www.midi.org/techspecs/rp18.php


> I had a quick look at the code and fixed two memory leaks. You could
> review my changes to ensure they are correct.


Seems fine to me.


> // David


I committed some more settings related changes.  In particular I added  
fluid_settings_dupstr and fluid_settings_copystr for thread safe  
string setting retrieval.  I reverted the changes to getstr() since  
that was bad and introduced lots of bugs.  It now behaves as before,  
but is not thread safe.  But as long as the caller can ensure the  
setting wont be assigned during its use of the returned value, it  
should be OK.  Internally FluidSynth now uses dupstr.  The copystr  
variant could be useful in a realtime context, to avoid malloc() calls.

Josh