Bernat Arlandis i Mañó wrote:
> Pedro Lopez-Cabanillas escrigué:
> > I would like to see this fix (ticket #21) into trunk, if it can be
> > backported without breaking 1.x API.
>
> It deals basically with the Jack driver, I've replaced the obsolete
> new_fluid_jack_audio_driver2 function with the n
On Tue, 2009-02-03 at 16:27 +0100, Bernat Arlandis i Mañó wrote:
> Josh Green escrigué:
> >
> > The new2 driver stuff is not obsolete. Its used in particular by QSynth
> > to intercept the audio for meters. I definitely think this mess should
> > be overhauled for FluidSynth 2.x, but shouldn't be
Josh Green escrigué:
The new2 driver stuff is not obsolete. Its used in particular by QSynth
to intercept the audio for meters. I definitely think this mess should
be overhauled for FluidSynth 2.x, but shouldn't be removed in the 1.x
branch though. I didn't look at your changes closely yet, s
On Mon, 2009-02-02 at 23:39 +0100, Bernat Arlandis i Mañó wrote:
> Pedro Lopez-Cabanillas escrigué:
> >
> > I would like to see this fix (ticket #21) into trunk, if it can be
> > backported
> > without breaking 1.x API.
> >
> >
> >
> It deals basically with the Jack driver, I've replaced the o
Pedro Lopez-Cabanillas escrigué:
I would like to see this fix (ticket #21) into trunk, if it can be backported
without breaking 1.x API.
It deals basically with the Jack driver, I've replaced the obsolete
new_fluid_jack_audio_driver2 function with the newer
new_fluid_jack_audio_driver f
On Miércoles, Enero 28, 2009, Bernat Arlandis i Mañó wrote:
> What do you think about fixing ticket #21 for 1.09? Without this,
> multi-channel output cannot be enabled from QSynth.
>
> Also, I've fixed the reverb and chorus effects in multichannel mode so
> they're applied to every channel, instea
List readers
I forgot that LADSPA headers are required for compiling the DSSI host
which in turn is required for the dssi-vst plugin wrapper for VST
effects. So LADSPA is not exactly disposable (no pun intended).
E
___
fluid-dev mailing list
fluid-de
On Thu, 2009-01-29 at 16:32 +0100, Bernat Arlandis i Mañó wrote:
> It scales pretty well, the reverb/chorus processing time multiplies by
> the number of channels, but still acceptable. With all 16 channels I got
> around 70% CPU load in my tests with an AMD64 2Ghz. There's some room
> for impr
Ebrahim Mayat escrigué:
Also, I've fixed the reverb and chorus effects in multichannel mode so
they're applied to every channel, instead of mixing the effects separately.
This would be a powerful feature allowing for inserts directly from
fluidsynth into a live mix. Would this entail a sig
On Wed, 2009-01-28 at 22:37 +0100, Bernat Arlandis i Mañó wrote:
> What do you think about fixing ticket #21 for 1.09? Without this,
> multi-channel output cannot be enabled from QSynth.
>
Excellent idea. I'm all for it. Then it would also be easy to prepare a
midnam file (for the General Users
On Wed, 2009-01-28 at 22:37 +0100, Bernat Arlandis i Mañó wrote:
> What do you think about fixing ticket #21 for 1.09? Without this,
> multi-channel output cannot be enabled from QSynth.
>
I'm looking at this now. I must admit, I've never quite figured out why
there are 2 sets of drivers (drive
What do you think about fixing ticket #21 for 1.09? Without this,
multi-channel output cannot be enabled from QSynth.
Also, I've fixed the reverb and chorus effects in multichannel mode so
they're applied to every channel, instead of mixing the effects separately.
I'm thinking about starting
12 matches
Mail list logo
