Re: [Denemo-devel] Fluidsynth build

[Richard Shann]

On Wed, 2009-10-28 at 11:32 -0500, Jeremiah Benham wrote:
> On Wed, 2009-10-28 at 09:54 +0000, Richard Shann wrote:
> > On Tue, 2009-10-27 at 12:43 -0500, Jeremiah Benham wrote:
> > > Now I need to make some command available
> > > like --disable-portaudio. Does this sound appropriately labeled? 
> > People who are building themselves are probably techie enough to use
> > whatever we give them, though --disable-pitch-detection might describe
> > better what it is they are disabling. Likewise, --enable-synth might
> > mean more than fluidsynth, in which case we would want to change all the
> > references to fluidsynth to synth. (The idea being that fluidsynth is
> > just an implementation detail, which could change).
> 
> I am not sure if I like labeling it --enable-synth. This does not tell
> the person trying to compile what libraries she is compiling in. So you
> are suggesting that maybe in the future there be more synths added? So
> if we actually used csound api instead of using it as an external we
> would have another synth. How would the person compiling it choose the
> difference. Csound already has soundfont support (it maybe fluidsynth I
> don't know). The user would not need to compile with fluidsynth then
> because soundfont playback could be done with csounds. Maybe I am
> confused what you mean here.

It is more likely me that is confused! What I imagined was that we might
change the synth we have built in at some stage, but then as you say
whoever is building it will want to know what the synth library is and
will be happy to change the flag to suit. So let's stick with
--enable-fluidsynth. It was --disable-portaudio that made me think about
this, as it is not obvious what portaudio might be being used for. That
is it would not be obvious features were being disabled. I'm happy
either way - indeed perhaps we could have both --disable-portaudio and
--disable-pitch-detection, meaning the same thing?

> 
> > 
> > > This is
> > > assuming portaudio is to be compiled in by default for purposes of
> > > audio
> > > input (pitch detection). 
> > I think the choice of default requires knowledge of the "politics" of
> > distros. If your package *requires* a lot of other packages it can
> > suffer, but if the minimal system does not have features people want it
> > can suffer too. Ideally we want to offer at least two things, a fully
> > featured program and a minimal program; better still if we can offer
> > music education games as straight from the box. But I am not sure how
> > distros do packaging, what they decide to build or not.
> 
> Just to be clear... When I am saying "default", I mean that it will be
> checked and compiled with $X unless $X is disabled with --disable-$X.
that's what I understood you to mean
> I
> am not forcing any requirements. Should they all be turned off?
That is the bit I am not sure about - what will be the effect on the
distro maintainers - my guess is we should keep the current things as
the default and make all the new things non-default, so as not to
perturb current users; but as I say, I don't really understand who does
what downstream.

>  That is
> the user would have to specify ./configure --enable-jack
> --enable-pitch-detection --enable-fluidsynth 
> 
> 
> > > If portaudio is disabled there is no need for
> > > libaubio and fftw3 correct? 
> > libaubio certainly, fftw3 I think so, in fact this one might even be
> > specific to tuning, but I don't suppose we want to start trying to tease
> > that apart.
> 
> Well if denemo can't receive any audio in fftw3 is useless isn't it? 
yes, but it may be that if people just want to do microphone note entry
and not instrument tuning they might need libaubio but not need fftw3,
however it is worth ignoring this even if its true.
 
> 
> > 
> > > Is there a method of shuting down portaudio
> > > once it has been initialized. Is this even needed?
> > Perhaps not - one of the portaudio directions (in or out) does starting
> > up and shutting down for each use, IIRC. Perhaps wait for a problem to
> > show, then fix it. I have just done Input->Audio Input and got notes
> > from a microphone, then Input->No External Input and fludisynth still
> > played back notes as I entered them. Then I turned on my MIDI keyboard
> > and chose Input->MIDI input and entered notes from the MIDI keyboard
> > (these played back immediately thru portaudio as sine-wave notes) and
> > then switching back to no external input I got fluidsynth notes as I
> > entered notes from the pc-keyboard.
> > If you can do the same there may be no problem to fix. The fact that I
> > hear portaudio notes when inputting from the MIDI controller implies
> > that you have not (yet?) wired up the d-PutMIDI command to fluidsynth I
> > guess. (I noticed yesterday that there is d-PutMIDI which puts out 4
> > MIDI bytes and d-PlayMidiNote, or some such, which plays a note via
> > MIDI).
> 
> Its wired up to d-Output-midi-event or whatever it is called. I really
> don't understand the differences between what d-PutMIDI and
> d-PlayMidiNote? Is d-PutMIDI any arbitrary midi message? 
I think it is just 4 byte messages - it was supposed to be just passing
midi event from midi in to the midi out, after having intercepted and
modified them - i.e. it was supposed to be the basis for midi filtering;
but I think it may only deal with 4 byte events (hmm let me look - yes
that's right, d-PutMidi takes an 4 byte integer and outputs it, while
d-OutputMidi takes a string of bytes in decimal or hex format,
substitutes $ and %%% for current channel and volume and outputs that).
d-PutMidi goes with d-GetMidi which gets a number encoding a 4-byte
message, other messages are dropped, I think. Maybe all this needs
re-visiting - I didn't, still don't, have a clear idea what other things
MIDI in/out might be useful for, beyond the uses I have already made -
entering notes, figured basses, checking by playing over a score etc.
Clearly d-PutMidi *could* be re-written using d-OutputMidi but there
might be no point, it would anyways be less efficient.
Richard


> Maybe I will
> reread the code again. I read it once but it did not seem clear at
> first. Perhaps I need to read more carefully.
> 
> 
> > >  I mostly just need to
> > > make sure that /dev/dsp does not have anything keeping it open with
> > > some
> > > sort of lock disallowing other things to write to it. I am not sure if
> > > that is the case or not.
> > Try those things out, and await reports from users, while we do stuff
> > that definitely needs doing.
> > I'll try and have a look at the fluidsynth api.
> 
> Will do.
> 
> Jeremiah
> 
> 
> > Richard
> > 
> > 
> > 
> > 
>