Hi Josh,
I am replying to an old message so you can hunt down the original messages with
the same email subject line if it may help refresh your memory. This time,
similar problem, different midi song.
Let me refresh your memory of the scenario. The result was that even if an
invalid bank_n
Le 25 janv. 09 à 23:14, Josh Green a écrit :
Things for the new 2.x branch:
About new development, there is an improvement to fluid that I had
worked on two years ago in a private branch that I think should be
integrated inside the main code base. I don't know if it should be
integrated
On Mon, 2009-01-26 at 12:06 +0100, Bernat Arlandis i Mañó wrote:
> Still, keep in mind that it's not my main goal splitting into separate libs
> but having good modularization to the point this would be really easy and
> practical.
>
Sounds good.
> > libInstPatch *does* handle 24 bit audio and f
On Sun, 25 Jan 2009 18:29:27 -0800, Josh Green wrote:
I think breaking FluidSynth into multiple libraries would likely
needlessly complicate things. However, I think keeping the code well
modularized is good and would make splitting things off into separate
libraries easy, if and when it seems
Hi Josh,
Oops, my bad on the source code path mentioned in the last email. For this
particlular song
www.sternton.com/midi/xgmidi/orion_xg.mid
the problem includes invocation of fluid_synth_program_change() for unavailable
or invalid "prognum" on channels 2, 3, 4 (counting from 0) and ma
Le 25 janv. 09 à 23:14, Josh Green a écrit :
Things for the new 2.x branch:
About new development, there is an improvement to fluid that I had
worked on two years ago in a private branch that I think should be
integrated inside the main code base. I don't know if it should be
integrated
> Date: Mon, 26 Jan 2009 01:47:12 +0100
> From: Bernat Arlandis i Ma??
>
>
> Although it's mainly about whatever we can agree that
> is good for the
> development of the project, I have some generic ideas that
> I think would
> work. These are modularization, decoupling the API from the
> inte
On Sun, 25 Jan 2009 18:29:27 -0800, Josh Green wrote:
> I think breaking FluidSynth into multiple libraries would likely
> needlessly complicate things. However, I think keeping the code well
> modularized is good and would make splitting things off into separate
> libraries easy, if and when it
...and while we are on the topic of new development...one thing that has
been on my mind for a while is the subject of effects plug-ins. For the
last few releases, I have chosen not to add the option of LADSPA for the
simple reason that this often causes spontaneous crashes particularly
when runnin
...and while we are on the topic of new development...one thing that has
been on my mind for a while is the subject of effects plug-ins. For the
last few releases, I have chosen not to add the option of LADSPA for the
simple reason that this often causes spontaneous crashes particularly
when runnin
Hi,
I've added two settings to the CoreMIDI driver (SVN revision 145) as it was
proposed:
* "midi.coremidi.id" setting adds the provided identifier to the Client Name.
If not set, the identifier is built using the process ID number. The Client
Name would become something like: "FluidSynth 1234
Josh Green wrote:
> > > Some decisions should be made about what remains to put into 1.0.9.
> > >
> > > What of the following should be added?
> > > - PortAudio driver (it exists, does it just need to be improved?)
> > > - Jack MIDI driver
> > > - ASIO driver
> >
> > That's another discussion, we s
On Mon, 2009-01-26 at 22:52 +0100, Pedro Lopez-Cabanillas wrote:
> I would like to find more time to work on the PortAudio driver, as it was my
> plan for ticket #19. I will try, but don't hold your breath.
>
> You are right: there is already a PortAudio driver, but it doesn't compile
> with Por
On Mon, 2009-01-26 at 09:43 +0100, Antoine Schmitt wrote:
> Le 25 janv. 09 à 23:14, Josh Green a écrit :
> > Things for the new 2.x branch:
>
>
> About new development, there is an improvement to fluid that I had
> worked on two years ago in a private branch that I think should be
> integrate
On Mon, 2009-01-26 at 15:10 -0500, Ebrahim Mayat wrote:
> ...and while we are on the topic of new development...one thing that has
> been on my mind for a while is the subject of effects plug-ins. For the
> last few releases, I have chosen not to add the option of LADSPA for the
> simple reason tha
Josh Green escrigué:
On Mon, 2009-01-26 at 09:43 +0100, Antoine Schmitt wrote:
Le 25 janv. 09 à 23:14, Josh Green a écrit :
Things for the new 2.x branch:
About new development, there is an improvement to fluid that I had
worked on two years ago in a private branch that I think
> Date: Mon, 26 Jan 2009 15:25:13 -0500
> From: Ebrahim Mayat
>
> ...and while we are on the topic of new development...one
> thing that has
> been on my mind for a while is the subject of effects
> plug-ins. For the
> last few releases, I have chosen not to add the option of
> LADSPA for the
>
Josh Green escrigué:
On Mon, 2009-01-26 at 22:52 +0100, Pedro Lopez-Cabanillas wrote:
I would like to find more time to work on the PortAudio driver, as it was my
plan for ticket #19. I will try, but don't hold your breath.
You are right: there is already a PortAudio driver, but it doesn't
Josh Green escrigué:
On Mon, 2009-01-26 at 15:10 -0500, Ebrahim Mayat wrote:
...and while we are on the topic of new development...one thing that has
been on my mind for a while is the subject of effects plug-ins. For the
last few releases, I have chosen not to add the option of LADSPA for th
On Tue, 2009-01-27 at 01:12 +0100, Bernat Arlandis i Mañó wrote:
> > About new development, there is an improvement to fluid that I had
> > worked on two years ago in a private branch that I think should be
> > integrated inside the main code base. I don't know if it should be
> > integrated
Josh Green escrigué:
I think the difference is between clocking MIDI events in MIDI files
based on the system timer versus using the sound card as the timing
source (how much audio has been played back).
It seems so.
It makes sense to me to
process the audio based on the audio playback. This
I probably shouldn't say too much, until I see what Antoine's solution
is.. But..
On Tue, 2009-01-27 at 03:04 +0100, Bernat Arlandis i Mañó wrote:
> > It makes sense to me to
> > process the audio based on the audio playback. This would lead to
> > identical playback between successive renders
Date: Mon, 26 Jan 2009 22:52:10 +0100
From: Pedro Lopez-Cabanillas
Subject: Re: [fluid-dev] New development
To: fluid-dev@nongnu.org
Message-ID: <200901262252.10107.pedro.lopez.cabanil...@gmail.com>
Content-Type: text/plain; charset="utf-8"
Josh Green wrote:
Some decisions should be made abo
23 matches
Mail list logo
