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

[Peter Hanappe]

M. Nentwig 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);

Hi Markus,

I can't help but find it a little confusing. I'd like to find
a more straighforward way. Here's how I see it.

Currently, the audio driver calls the synth and gets two filled
buffers as a result. Internally, the synthesizer uses some sort of
mixing console concept (16 channels input, aux1 goes to reverb, aux2
goes to chorus, ...) that mixes everything down to one stereo signal.

If we want to export the internal 'mixing console' outside of the
synthesizer, we need to change the API of the synth. In that case, the
driver asks to fill 16 mono buffers instead of one stereo buffer. All
the volume and effects-send parameters are exported to the driver.

The default driver will pretty much do the same thing as now. We only
need to copy some of the current code to into the driver and don't
handle pan and effects send in the DSP loop.

A Jack driver could be asked to export all 16 mono channels, so users
can mix and apply effects using other applications. In that case, the
Jack driver would ignore the mixing and effects send values. We then
need a way to send additional command line options to the driver so it
can configure itself.

So that brings me to:

1) change the iiwu_synth_write function to accept 16 mono buffers:

int
iiwu_synth_write(iiwu_synth_t* synth, iiwu_sample_t** buffers, int nbuf);

2) change the audio drivers for setting/getting mixer values:

enum {
  IIWU_MIXER_VOLUME,
  IIWU_MIXER_PAN,
  IIWU_MIXER_REVERB_SEND,
  IIWU_MIXER_CHORUS_SEND,
  IIWU_MIXER_LAST
};

struct _iiwu_adriver_definition_t
{
  char* name;
  iiwu_audio_driver_t* (*new)(char* devname, int format,
                              int sample_rate, int bufsize,
                              int queuesize, iiwu_synth_t* synth);
  int (*free)(iiwu_audio_driver_t* driver);
  int (*set_control)(iiwu_audio_driver_t* driver, int chan,
                     int ctrl, float value);
  float (*get_control)(iiwu_audio_driver_t* driver, int chan, int ctrl);
};


Does that make sense?

Cheers,
Peter


> Markus