denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] The 0.8.12 release


From: Richard Shann
Subject: Re: [Denemo-devel] The 0.8.12 release
Date: Tue, 22 Dec 2009 22:35:52 +0000

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.
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, placing
a default one there if no match.
And then at deciding-where-to-send-output-time we can compare pointers
rather than strcmp.
Richard

Oh - above I have followed Nils' suggestion of not calling it fluidsynth
- I think that is right for anything user facing... (Other than in the
denemorc, there is just the prefs dialog headings? we don't otherwise
publish the name from a running denemo program, right?).
Richard


> The three choices being:
> "portaudio"
> "fluidsynth"
> "jack"
> 
> Then we would need an enum but a strcmp
>  when deciding which system to use for various audio playback/feedback. Would 
> that be better?
> 
> Jeremiah
> 
> >Still, life is too short.
> > Last call for features for the release!
> > Richard
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Denemo-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/denemo-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]