[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Denemo-devel] The 0.8.12 release
From: |
Jeremiah Benham |
Subject: |
Re: [Denemo-devel] The 0.8.12 release |
Date: |
Wed, 23 Dec 2009 11:27:52 -0600 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
Ok. I have pushed this to git.
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
- Re: [Denemo-devel] The 0.8.12 release, (continued)
- Re: [Denemo-devel] The 0.8.12 release, Richard Shann, 2009/12/22
- Re: [Denemo-devel] The 0.8.12 release, Jeremiah Benham, 2009/12/22
- Re: [Denemo-devel] The 0.8.12 release, Richard Shann, 2009/12/22
- Re: [Denemo-devel] The 0.8.12 release, Nils, 2009/12/22
- Re: [Denemo-devel] The 0.8.12 release, Richard Shann, 2009/12/23
- Re: [Denemo-devel] The 0.8.12 release, Nils, 2009/12/23
- Re: [Denemo-devel] The 0.8.12 release, Richard Shann, 2009/12/23
- Re: [Denemo-devel] The 0.8.12 release, Nils, 2009/12/23
- Re: [Denemo-devel] The 0.8.12 release, Richard Shann, 2009/12/23
- Message not available
- Re: [Denemo-devel] The 0.8.12 release, Richard Shann, 2009/12/23
- Re: [Denemo-devel] The 0.8.12 release,
Jeremiah Benham <=
- Re: [Denemo-devel] The 0.8.12 release, Richard Shann, 2009/12/23
Re: [Denemo-devel] The 0.8.12 release, Richard Shann, 2009/12/22
Re: [Denemo-devel] The 0.8.12 release, Richard Shann, 2009/12/30
Re: [Denemo-devel] The 0.8.12 release, Richard Shann, 2009/12/30