denemo-devel
[Top][All Lists]
Advanced

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

Re: [Denemo-devel] Fluidsynth build


From: Jeremiah Benham
Subject: Re: [Denemo-devel] Fluidsynth build
Date: Wed, 28 Oct 2009 11:32:41 -0500

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.

> 
> > 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. I
am not forcing any requirements. Should they all be turned off? 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? 

> 
> > 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? 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
> 
> 
> 
> 





reply via email to

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