Re: [iiwusynth-devel] MIDI router proposal

[Peter Hanappe]

Hi Markus,

I think it's a good idea but I'd like to wait till we have a final 1.0
version before making the changes. Besides bug fixes and tests, I
don't have a lot of new features on my todo list for the first
official release.

One thing that I may change - see also Tim Goetze's request - is
define the interactions between modules more clearly. That will make
the introduction of the midi router easier.

These are the current modules:

- The synthesizer (iiwu_synth)
- The audio drivers
- The midi drivers
- The sequencer
- The midifile player
- The shell

It should be possible to compile the library without audio drivers,
midi drivers, and so on. That means that the synthesizer shouldn't
depend on any other module. Actually, none of these modules should
ideally depend on any other module. For version 1.0, it's okay if the
audio and midi drivers depend on the synthesizer (both drivers know
the synthesizer's API). For version 1.1, it'd be nice if the midi and
audio drivers are independent of the synthesizer. In that way, we can
put other modules between the drivers and the synthesizer, for
example, the ladspa fx unit, or the midi router. This is not so
difficult to do for the midi driver. However, for the audio driver it
is more complicated.

For the time being, the changes I'd like to propose is that the audio
thread is no longer created by the synthesizer, but explicitely by the
developer:

  iiwu_settings_t* settings = new_iiwu_settings();
  iiwu_synth_t* synth = new_iiwu_synth(settings);
  iiwu_audio_thread_t* at = new_iiwu_audio_thread(settings, synth);

I'll take a look at the current midi driver API to see if we can make
a more clean separation between the midi thread and the synthesizer.
That may open the door to add a midi router module.


Cheers,
Peter


M. Nentwig wrote:
> Hei,
>
> I'd like to propose a new feature, MIDI routing.
> Most important, the feature is completely transparent in 'default' mode:
> When a new synth is started, the MIDI router does not do anything. The
> user won't even notice that it exists. If a user doesn't need the
> router, he doesn't have to know about it.
>
> The router makes sense, when Fluidsynth is used as 'a virtual 19'' rack'
> - MIDI input from a keyboard on one side, audio output to the speakers
> on the other side. It's probably not too useful, when using the synth as
> a library.
> The scheme is similar to the MIDI router in any multitimbral synth, just
> much more general.
>
> The MIDI router is one more processing layer directly behind the MIDI
> input. It processes incoming MIDI events and generates control events
> for the synth.
> The user can specify 'windows', in which MIDI data is routed. Here is an
> example (in human-readable form, those are no commands).
> It splits the keyboard and routes CC 7 (vol) to one part, and CC 11
> (expr) to the other.
>
> 'route MIDI note events from MIDI-in channel 1 to synth channel 1, when
> 60 <= key <= 72'
> 'route MIDI note events from MIDI-in channel 1 to synth channel 2, when
> 73 <= key <= 127'
> 'route MIDI CC events from MIDI-in channel 1 to synth channel 1, when  7
> <= CC <= 7' ('CC=7')
> 'route MIDI CC events from MIDI-in channel 1 to synth channel 2, when 11
> <= CC =< 11'
> 'route MIDI CC events from MIDI-in channel 1 to synth channel 1, when 7
> <= CC =< 7'
> 'route MIDI CC events from MIDI-in channel 1 to synth channel 2, when 11
> <= CC <=11'
> 'route MIDI aftertouch events from MIDI-in channel 1 to synth channel 1'
>
> Another way to use this feature is to implement OMNI mode:  incoming
> MIDI input on all input channels is treated equally and routed to one
> particular synth channel.
> With the MIDI router it will also be possible to set up arbitrary
> layered sounds and process the parts with separate effects.
>
> About implementation: I thought to implement two separate filtering
> passes:
> The first pass is used to ignore incoming events. So to get rid of the
> sustain pedal, we just tell the router to ignore all events with CC =
> 64.
> The second pass does the actual routing. Each 'window' (one of the
> 'route ...' lines from above) checks against a range for channel,
> param1, param2, modifies / offsets channel, param1, param2 and sends the
> event to the synth.
>
> Long-term planning:
> - Several MIDI inputs (input 2: MIDI channel 17..32 etc)
> - MIDI output (similar routing commands, only to a MIDI interface
> instead of the synth).
>
> What do you think?
>
> Cheers
>
> Markus
>
>
>
> _______________________________________________
> iiwusynth-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/iiwusynth-devel