Re: [fluid-dev] API design: fluid_synth_process()

2018-05-02 Thread Ceresa Jean-Jacques
>jj >Note) Also, i think that in the future, the actual internal "MIDI channel >to output buffer" hard coded mapping should be replaced by an API. > >Tom>Shouldnt be the user in charge of properly mapping any multichannel >rendered output?   I prefer thinking of "MIDI channels mapping" (done i

Re: [fluid-dev] API design: fluid_synth_process()

2018-05-02 Thread Tom M.
> 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

Re: [fluid-dev] API design: fluid_synth_process()

2018-05-02 Thread Ceresa Jean-Jacques
>In fact I believe that no matter how many output buffers the user calls it >with, fluid_synth_process should always render all playing voices to those >buffers (provided that nout >= 2). yes, this is what fluid_synth_process() actually does (apart the internal mapping "MIDI channel to ouput bu

Re: [fluid-dev] API design: fluid_synth_process()

2018-05-02 Thread Tom M.
> 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