Re: [Denemo-devel] The 0.8.12 release

[Richard Shann]

On Wed, 2009-12-23 at 11:27 -0600, Jeremiah Benham wrote:
> Ok. I have pushed this to git.

It looks good. One thing, though, default if you have compiled with
fludisynth should be fluidsynth not portaudio (first tab in prefs).
Richard



> Jeremiah
> 
> 
> On Wed, Dec 23, 2009 at 08:12:39AM +0000, Richard Shann wrote:
> > 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
> >  
> > 
> > 
> > 
> > _______________________________________________
> > Denemo-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/denemo-devel