O. P. Martin wrote:
Hi, Josh,
hi, Pedro,
How are you?
I was hoping to use PortAudio in my own project under Windows and
cross platform. The current state of affairs does sound quite
discouraging.
Does audacity use pa ...? How do they do it?
Thank you for your work. Keep up the good w
Hi, Josh,
hi, Pedro,
How are you?
I was hoping to use PortAudio in my own project under Windows and cross
platform. The current state of affairs does sound quite discouraging.
Thank you for your work. Keep up the good work!
May the Lord bless you,
Philip
Josh Green wrote:
Hello Pedro
Hello Pedro,
On Sun, 2009-02-01 at 02:05 +0100, Pedro Lopez-Cabanillas wrote:
> I've checked in some changes to the PortAudio driver.
>
> - PortAudio enumerates devices having input only ports. As we need audio
> output devices, I've changed the enumeration to ignore devices with less
> than 2
Josh Green wrote:
> After looking at the fluid_portaudio.c and seeing how small it was, I
> decided to take a crack at it. Checked in is the new PortAudio driver
> using PortAudio API 19. I added device enumeration, but it still needs
> some improvement. It is using the device names for the sett
Hi Pedro,
Given that the generic ASIO4ALL driver is really just an ASIO overlay
of WDM/KS I think that a WDM/KS PortAudio driver would produce the
desired lower latency that windows users are hoping for. Do you know
what type of configuration options would be available - buffers,
sample rate, etc?
On Thu, Jan 29, 2009 at 11:41 PM, Josh Green wrote:
>
> On Thu, 2009-01-29 at 22:46 +0100, Pedro Lopez-Cabanillas wrote:
> > I have a problem with ASIO, though. First, I don't like the license terms
> > from
> > Steinberg: they don't allow to redistribute their sources (that are
> > available
> >
On Thu, 2009-01-29 at 22:46 +0100, Pedro Lopez-Cabanillas wrote:
> I have a problem with ASIO, though. First, I don't like the license terms
> from
> Steinberg: they don't allow to redistribute their sources (that are available
> free of charge for registered developers). Second, they ask for an
On Thu, 2009-01-29 at 23:29 +0100, Pedro Lopez-Cabanillas wrote:
> Josh Green wrote:
> > On Thu, 2009-01-29 at 22:46 +0100, Pedro Lopez-Cabanillas wrote:
> > > Thanks, Josh!
> > >
> > > I will try to find some time this week end to play in Windows. I've
> > > already succesfully tested it on Linux.
Josh Green wrote:
> On Thu, 2009-01-29 at 22:46 +0100, Pedro Lopez-Cabanillas wrote:
> > Thanks, Josh!
> >
> > I will try to find some time this week end to play in Windows. I've
> > already succesfully tested it on Linux.
> >
> > I have a problem with ASIO, though. First, I don't like the license
Hi,
> Hi Pedro,
>
> I can understand your dislike of the Steinberg license terms! ASIO is,
> however, the best general low latency audio for Windows users.
>
> Would it be possible for you to create/update a
> How-To-Build-Fluidsynth / Qsynth in windows using mingw with the ASIO
> information (onc
On Thu, 2009-01-29 at 22:46 +0100, Pedro Lopez-Cabanillas wrote:
> Thanks, Josh!
>
> I will try to find some time this week end to play in Windows. I've already
> succesfully tested it on Linux.
>
> I have a problem with ASIO, though. First, I don't like the license terms
> from
> Steinberg:
Josh Green wrote:
> On Thu, 2009-01-29 at 00:12 +0100, Pedro Lopez-Cabanillas wrote:
> > > Seems to me like it is definitely worth improving the existing
> > > PortAudio driver. Any idea what this would entail?
> > > Josh
> >
> > Briefly:
> > * Detect and define PORTAUDIO_* in the build system.
Hello,
Good point about WineASIO, I didn't actually know such thing existed.
Best regards,
Josh
On Thu, 2009-01-29 at 11:28 +0200, ggoode.sa wrote:
> Hi Josh,
>
> I don't have a build environment in Windows at the moment and probably
> won't for a few more weeks (in the middle of a move
Hi Josh,
I don't have a build environment in Windows at the moment and probably
won't for a few more weeks (in the middle of a move), but if you email
me your build I'm willing to try it in WinXP. Alternatively one could
test this with the WineASIO driver and WINE (which then patches into
JACK).
On Thu, 2009-01-29 at 00:12 +0100, Pedro Lopez-Cabanillas wrote:
> > Seems to me like it is definitely worth improving the existing PortAudio
> > driver. Any idea what this would entail?
> > Josh
>
> Briefly:
> * Detect and define PORTAUDIO_* in the build system. I've done that using
> pkg-c
Josh Green wrote:
> On Tue, 2009-01-27 at 21:59 +0100, Pedro Lopez-Cabanillas wrote:
> > I don't think so. Seems that the PortAudio driver would be useful only to
> > Windows users, where FluidSynth has only a DirectSound driver with huge
> > latency problems. For this platform PortAudio provides A
On Wed, 2009-01-28 at 11:34 +0100, Antoine Schmitt wrote:
> Hello,
> I'm not sure that the problem can be ignored for Midi file playback,
> because a large driver buffer will miss some midi events, which will
> then happen late in the audio stream.
>
> About my patch, the fact is that I haven'
Right ! ;-)
"2. FS doesn't work well with big audio output sizes (or high
latencies) since MIDI events get quantized to it."
But then problem #2 is a problem for midifile playback, right ?
Le 28 janv. 09 à 18:03, Bernat Arlandis i Mañó a écrit :
Antoine Schmitt escrigué:
Hello,
I'm not
Antoine Schmitt escrigué:
Hello,
I'm not sure that the problem can be ignored for Midi file playback,
because a large driver buffer will miss some midi events, which will
then happen late in the audio stream.
Hello Antoine.
Notice how I've split your issue into two problems. Problem #1 can b
Hello,
I'm not sure that the problem can be ignored for Midi file playback,
because a large driver buffer will miss some midi events, which will
then happen late in the audio stream.
About my patch, the fact is that I haven't found a clean way to link
the synth to the sequencer. I verified
On Tue, 2009-01-27 at 21:59 +0100, Pedro Lopez-Cabanillas wrote:
> I don't think so. Seems that the PortAudio driver would be useful only to
> Windows users, where FluidSynth has only a DirectSound driver with huge
> latency problems. For this platform PortAudio provides ASIO and WinMM audio
>
Bernat Arlandis i Mañó wrote:
> 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: ther
Antoine Schmitt escrigué:
Hi Josh and Bernat,
The issue I fixed was for real time rendering, when using the
sequencer. And it was related, not only to standard and simpler
latency caused by the size of the driver buffer, but because of
unexpected behavior from the DSound driver, which, depend
Hi Josh and Bernat,
The issue I fixed was for real time rendering, when using the
sequencer. And it was related, not only to standard and simpler
latency caused by the size of the driver buffer, but because of
unexpected behavior from the DSound driver, which, depending on the
target hard
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
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
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é:
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
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
> 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 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
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
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 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
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
...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
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
> 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
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 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
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
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 01:47 +0100, Bernat Arlandis i Mañó wrote:
> Specifically, on the modularization aspect I'd like to break FS down in
> several libraries that could build separately if needed. This libraries
> might be, guessing a bit: fluid-synth (the synthesis engine),
> fluid-soundfont (
Pedro:
Changes breaking the API compatibility, not only for FluidSynth but for any
ELF shared library (i.e., to be deployed in Linux), should require a change
in the SONAME internal attribute for the library. This is usually
accomplished changing the major version number.
I wasn't sure about th
On Sun, 2009-01-25 at 09:27 -0500, Ebrahim Mayat wrote:
> By "break compatibility backwards", do you mean that old soundfont files
> could not be parsed successfully ?
>
> Perhaps you are talking about the linking of FS libraries to other
> programs like SWAMI, MAX/MSP and fluid~ ?
>
> Thanks
Hello Bernat,
On Sun, 2009-01-25 at 13:41 +0100, Bernat Arlandis i Mañó wrote:
> This is concerning ticket #11.
>
> I'm thinking on a lot of changes to take FS forward as I review the
> source code and fix some things, but most of these changes would break
> compatibility backwards. Maybe we sh
On Sun, 2009-01-25 at 13:41 +0100, Bernat Arlandis i Mañó wrote:
> This is concerning ticket #11.
>
> I'm thinking on a lot of changes to take FS forward as I review the
> source code and fix some things, but most of these changes would break
> compatibility backwards. Maybe we should think abou
Bernat Arlandis i Mañó wrote:
> This is concerning ticket #11.
>
> I'm thinking on a lot of changes to take FS forward as I review the
> source code and fix some things, but most of these changes would break
> compatibility backwards. Maybe we should think about making a branch for
> something that
Julien Claassen escrigué:
Hello Bernat!
How do you mean: breaking compatibility? Would commands no longer
work? Would you have a new syntax for the more complex parts of FS?
Could you explain a bit more, so the stupid user understands. Because
only then I could really think about it. General
Hello Bernat!
How do you mean: breaking compatibility? Would commands no longer work?
Would you have a new syntax for the more complex parts of FS? Could you
explain a bit more, so the stupid user understands. Because only then I could
really think about it. Generally I'd have no probelm with
This is concerning ticket #11.
I'm thinking on a lot of changes to take FS forward as I review the
source code and fix some things, but most of these changes would break
compatibility backwards. Maybe we should think about making a branch for
something that could be FS2.0. Fixes that break com
52 matches
Mail list logo
