Re: [Denemo-devel] The 0.8.12 release

[Richard Shann]

On Tue, 2009-12-22 at 23:28 -0600, Jeremiah Benham wrote:
> On Tue, Dec 22, 2009 at 10:35:52PM +0000, Richard Shann wrote:
> > On Tue, 2009-12-22 at 15:49 -0600, Jeremiah Benham wrote:
> > > On Tue, Dec 22, 2009 at 09:11:47PM +0000, Richard Shann wrote:
> > > > On Tue, 2009-12-22 at 20:51 +0000, Richard Shann wrote:
> > > > > On Tue, 2009-12-22 at 13:35 -0600, Jeremiah Benham wrote:
> > > > > > On Tue, Dec 22, 2009 at 07:18:59PM +0000, Richard Shann wrote:
> > > > > > > On Tue, 2009-12-22 at 20:16 +0100, Nils wrote:
> > > > > > > > With newest git (which is working again) you can't set the
> > > > > general audio-backend (Denemo ones) to fluidsynth.
> > > > > > > Well you can set it, but it isn't remembered...
> > > > > > > this is just the bug that Jeremiah was going to fix, except that
> > > > > it
> > > > > > 
> > > > > > I should get a chance to fix this in a few hours. 
> > > > > > 
> > > > > > Jeremiah
> > > > > hmm, it occurs to me that the fix I put in is probably defective.
> > > > Well it isn't but only because of some less that wonderful coding -
> > > > there is an enum in denemo_types.h which sets these values in stone,
> > > > they have to match an array of strings elsewhere (I have added a
> > > > warning). 
> > > 
> > > I thought you wanted it stored as an integer. Would it be better then to 
> > > store it as a string? 
> > In the prefs it should really be a string - it is me that just went and
> > dumped out the integer. I wasn't thinking. What we should do is look up
> > the string that corresponds with the integer field that is stored in
> > Denemo.prefs.midi_whatever_it_was and store that in denemorc.
> > 
> > I really think life is too short, but having some enum values in
> > denemo_types.h and a matching array of strings elsewhere is not good,
> > especially as we really don't want to present the same set of strings to
> > all versions of the program. In fact, this is one of those cases where
> > we could do with a separation between what the user is using just at the
> > moment and his long term preference - we tend to save whatever the user
> > used last as a pref.
> > 
> > Hmm - your comment (below) about strcmp has made me *really* think about
> > this. The only neat solution is this:
> > In main.c define three const strings
> > 
> > const gchar *Jack = "Jack";
> > const gchar *Portaudio = "Portaudio";
> > const gchar *Fluidsynth = "InternalSynth";
> > 
> > and then declare them
> > extern const gchar *Jack; etc in denemo.h
> > 
> > then we can store these in the
> > Denemo.prefs.midi_audio_out_whatever_it_is_called rather than an enum.
> 
> Store as a GString or gchar*? 
const gchar*

> Because all the rest of the code is GString it will look cleaner.
The distinction is a fixed set of strings which this is one of versus a
string value that may be changed by the user. The fixed set *can* be
described by and enum, but using a fixed set of pointers means we can
just test for pointer equality instead of looking at the string...
>  I think what you are describing though is using gchar* for 
> Denemo.prefs.midi_audio_output.
yes

> If this is the case we will need to use different macros for writing and 
> saving to it because the others use GString.  
yes, we could review the others in case there are other fixed sets of
const strings in use (although life is very short).
>  
> 
> > Then we can always look up the string by dereferencing the pointer.
> > We store the string in denemorc and we do strcmp to find out which of
> > the three const pointers should be placed in the midi_... field, 
> 
> So this suggest gchar *
> 
> I have done most of this work already but currently have 
> Denemo.prefs.midi_audio_output as a GString. I will adjust it to use gchar 
> tommorow and push it to git if you like. 
> 
> >placing
> > a default one there if no match.
> 
> ok. I will have to write a function to do this. 
> 
> > And then at deciding-where-to-send-output-time we can compare pointers
> > rather than strcmp.
> 
> Is strcmp too slow? On midi playback it will only be done once on scripted 
> playback and immediate playback it will be called for every note. 
It could be, it just feels a bit strange where we are choosing between
fixed, known, alternatives - I am sure we have other instances of such
things going on in the code.
Richard