Re: [iiwusynth-devel] Individual channel and reverb / chorus outputs

[Juan Linietsky]

On Sat, 10 Aug 2002 11:32:59 +0300
"M. Nentwig" <address@hidden> wrote:

> Hei,
> 
> long response times on the iiwuysynt-devel list, looks like it's
> summer:-)
> 
> I had been thinking about a similar solution, that has the following
> features:
> 
> - Operation as before (internal reverb, chorus, doesn't break
> existing iiwusynth-applications)
> - On demand: external routing of reverb signal, using this feature
> disables the internal reverb unit
> - Same with chorus
> - On demand: Individual output for some or all channels. This
> disables reverb send / chorus send for the channels in question.
> 
> The idea is to tell iiwusynth once, which buffer to use for which
> channel. If this is not done (or the buffer is NULL), default
> processing is done.
> 
> The whole scheme starts inconspicously with a couple of constants,
> for example:
> 
> IIWU_OUT_MONO, IIWU_OUT_STEREO:
>     Sets the type of the output. If MONO, single-channel output of a
> stereo sample will be converted to mono. If stereo, vice versa.
> Parameter 'int type'.
> IIWU_OUT_REVSEND, IIWU_OUT_CHOSEND:
>     Used to control reverb send / chorus send. Parameter 'int
>     output'
> IIWU_OUT_INDIV0, IIWU_OUT_INDIV1,...IIWU_INDIV_OUT_15
>     Used to control the individual output of MIDI channel X.
>     Parameter
> 'int output'
> IIWU_OUT_MAIN_L, IIWU_OUT_MAIN_R
>     Used to set the master output buffer (for consistency, giving
> non-NULL buffer arguments to iiwu_synth_write_float will maybe
> override this)
> 
> Then we have one more function:
> 
> void iiwu_out_control(int output, int type, float * buf_space):
> This tells iiwusynth to use buf_space as buffer for the data denoted
> by'output' (and perform a mono / stereo conversion, if needed).
> If buf_space is NULL, the default behaviour is restored.
> 
> That's it, basically. An example:
> This routes the drum channel (9) to buffer my_mem. It will not
> appear any more on the main L/R output.
> 
> float * my_mem=(float*)malloc(...);
> iiwu_out_control(IIWU_OUT_INDIV9,IIWU_OUT_STEREO,my_mem);
> 
> 
> When implementing this, we'll have to take into account the
> multithreading aspects (i.e. not change a buffer, while the
> synthesis process writes to it).
> I hope this is not counter-productive, since Tim has already
> provided a working patch. But I'd rather implement all the related
> features consistently at one time.
> The only drawback I have found so far is, that the application
> cannot use alternating buffers for the individual outputs (still for
> master out).
> 
> What do you think?
> 


This is how I do it in legasynth:

1-I have a struct like this, 16 of them:

struct Channel {
        
     vector<Sint32> buffer; //i use integers for managing audio
     bool used_in_block;
     int reverb_send;
     int chorus_send;
} channel[16];

So how does it work?
Every voice has a channel assigned, this is by default because of the
midi implementation,
at mixtime, for each channel the buffer is cleared (if used in the
previous block) each voice is mixed to its respective buffer (and
used_in_block toggled true), then i go through each channel, and if it
was used, i copy it to the mix buffer/and the send_buffers (if
reverb/chorus amount >0).
It may seem overkill but it's not, and it actually scales much better
than having to send chorus/reverb
per voice when you have a lot of channels. This lets me easily
register all 16 channels to JACK and the send buffers, so basically, i
can simply turn off chorus and reverb (and i dont have to modify the
voice mixing code nor place an "if" inside, which will slowdown things
more) and have the things exported
individually. So overall I think this gives advantages not only for
this approach, but for speeding up the mixing when a lot of voices are
in use.

Juan Linietsky