should read
this. Particularly the possibility of mapping/wrapping and mixing
to the application's output buffers.
jjc
> Message du 18/05/18 13:31
> De : "Tom M."
> A : fluid-dev@nongnu.org
> Copie à :
> Objet : Re: [fluid-dev] API design: fluid_synth_p
Hi Tom,
looks very good, thanks!
Initially a was a bit confused with regard to the effects buffers in the
first usage example. I thought that the code would only render the reverb
effects... but then I remembered that the channels wrap around and that
chorus would simply add to the same two chann
I have drafted a proposal for a possible implementation of
fluid_synth_process() based on the previous discussion. Anybody interested,
please check it out:
http://www.fluidsynth.org/api-unstable/synth_8h.html#aa8960f664e2b22025a8a72a78a614279
As it's only a proposal, it hasn't been implemented
Ok thanks. So we at least have an idea of how to cope with
fluid_synth_process(). Implementation might be a little tricky, not sure if if
will be ready for the beta. But shouldnt hurt that much, since it wont break
existing behaviour either.
Tom
___
gt; Message du 02/05/18 21:45
> De : "Tom M."
> A : "Ceresa Jean-Jacques"
> Copie à : fluid-dev@nongnu.org
> Objet : Re: [fluid-dev] API design: fluid_synth_process()
>
> > You mean 5.1 (i.e 6 channels)
> > Sorry i dont' understand this index
s
possible)" is common to both subject. I hope that any reader will not be
confused by these 2 subjects. To avoid any possible confusion for now, i will
not talk anymore about "MIDI channel mapping".
jjc.
> Message du 02/05/18 21:45
> De : "Tom M."
&g
> You mean 5.1 (i.e 6 channels)
> Sorry i dont' understand this index 5 ?.Does Surround could follow any others
> know buffers ?
I think each audio channel should receive the full spectrum. fluidsynth
shouldnt be in charge of rendering the subwoofer channel. But these are
implementation details
e) Also, i think that in the future, the actual internal "MIDI channel to
output buffer" hard coded mapping should be replaced by an API.
jjc
> Message du 02/05/18 16:40
> De : "Tom M."
> A : "Ceresa Jean-Jacques"
> Copie à : "FluidSynth mai
> fluid_synth_process() behaves like fluid_synth_nwrite_float()
Except for the fact that it doesnt handle fx channels.
> Consequently nout and out array must be set to sufficient size (nout >= 2 x
> synth->audio_channels).
Not necessarily. I think fluid_synth_process() should also be usable for
llustrates this.
Hope the author of this API could tell more about the intended unused
parameters int nin, float** in.
jjc
> Message du 26/04/18 14:42
> De : "Tom M."
> A : fluid-dev@nongnu.org
> Copie à :
> Objet : [fluid-dev] API design: fluid_synth_process()
>
> I
> I have noticed that 24 bits support introduces not negligible lost of
> performance that could be solved relatively easily .
Thanks for the hint. Looking forward to filing an issue or PR.
> Perhaps it worth to solve this before any beta realease ?
Sorry, I do not think it's worth to delay the
>One function that still strikes me is fluid_synth_process()..
Sorry, i never used this function, but i will take a look.
jjc.
> Message du 26/04/18 14:42
> De : "Tom M."
> A : fluid-dev@nongnu.org
> Copie à :
> Objet : [fluid-dev] API design: fluid_synth_proce
I thought to release a beta in the nearer future. But I would like to have the
API ready before I do so. One function that still strikes me is
fluid_synth_process() [1]. It's lacking a real implementation for 15 years. If
we dont get it right now, we'll never do, so we better discuss it.
This f
13 matches
Mail list logo
