Ideas - Support for multiple MIDI devices on a single interface

Ideas - Support for multiple MIDI devices on a single interface

[mailing-list-recipient]

Hi guys, I'm new to this list so be gentle :)

I've got a pretty in-depth knowledge of the MIDI standard/protocol, and
have been working with it for a few years (both as a user of it, and as a
developer of software using it.)

For a considerable amount of time, I've been trying to identify ways in
which MIDI can be made a bit more user-friendly.

Up until now, I've just hacked together bits of code that work for the
equipment I use (not a lot, to be honest.)

I realise that a lot of MIDI equipment these days have USB ports, and that
they appear to a host computer as a separate individual MIDI interface.
But I'm sure there's plenty of existing equipment out there sporting the
traditional 5-pin DIN interface, and other MIDI accessories. So the ideas
within this message apply mostly to users of such equipment.

The name I coined for this project was "MAL" - "MIDI Abstraction Layer".
Loosely based on the "hardware abstraction layer" concept, this basically
abstracts the MIDI protocol and provides an API which can deal with MIDI
messages and provide a standard and easy way to manage patch lists,
controller settings, etc.

What's all this got to do with ALSA? Well I think this would benefit ALSA
more than if it were just a stand-alone project of my own. (I will still
refer to these ideas as "MAL" in this message, to attempt to avoid
confusion.)

So to start with, you have your MIDI interfaces. These are typically
hardware ports, or they might be an internal device or software synth. In
many cases, this is where the story ends - one MIDI device is attached to
one MIDI interface.

Some musicians may have several MIDI devices connected to a single
interface (port.) In this case, the user would be able to specify which
device(s) listen or send on each channel. Some users may have more than
one device listening to a channel.

Each device has a patch list, possibly organised into categories. If a
particular channel on an interface is shared between multiple devices,
somehow the patch lists for each device could be merged, or displayed in
such a way that the user can clearly see what sounds they can expect to
hear if they select a particular patch.

This may be as follows:
"Grand Piano / Soft Strings"
(the latter being a non-standard MIDI patch that has the same patch number
as Grand Piano for the 2nd device.)

Additionally, each device may respond to different controllers, and may
ignore some completely. In this case, a "controller map" would be useful.
The most basic implementation would simply map a meaningful name to a
controller ID, whilst more advanced methods might take into account SysEx
messages (such as those employed by Yamaha XG devices) and possibly
indicating how to represent the MIDI controller data (eg: decibels.)

If you wish for the MIDI devices to be ultimately tweakable, ideally the
patch and controller mapping would be handled by a script of some form.
But it could also work just as a compiled library - a rather basic driver.

The idea is that the MAL API talks to such drivers, which would construct
MIDI messages for MAL to send out to MIDI devices.

To actually use a channel, it would need allocating first. This would
ensure that one channel is exclusively "owned" by an application. But it
would be pretty nice to be able to allow the user to just say "give me a
melody channel" and have one picked from the available melody channels, or
"give me a rhythm channel".

It'd be nice to dynamically reallocate channels on an "on-demand" basis.
The problem with that though, is that there might be some interruption in
performance as controller values are copied over from one channel to
another and notes stop/start, etc. (The controller values would somehow
need to be cached in order for this to work.)

Then there are the more advanced features such as SoundFont loading,
sample dumping (SDS), sequencer control, etc. Some of these may be handled
by the MAL API directly (particularly the sequenceer control.)

These are "auxiliary" functions, and would most likely require a user
interface of some form. So perhaps a good solution would be to implement
the functionality in a library, and the devices that make use of such
features can link to the library and make use of it. The GUIs for such
things would probably be best as a separate program/library, and called up
by the program being used.

For MIDI input, I haven't got that far with the design yet...

In summary, it's pretty much "MIDI Mapper" from the older versions of
Windows, but with a lot more flexibility.


The only problem I can see with this, is that - as I said earlier -
traditional MIDI devices and accessories are being replaced by USB
versions, which defeats most of the point of MAL.

But with that taken into account, it would still be nice for there to be a
standardized way in which applications could find out about what patches
and controllers are implemented by MIDI devices.


Thanks for reading. It's my hope that these ideas may be of value to the
ALSA developer community, and also the developers and users of music
applications on Linux.

If anyone wants further information, feel free to ask here or contact me
privately by email.

And if it's a completely pointless idea, let me know also ;)


Regards


Andrew Greenwood

Re: Ideas - Support for multiple MIDI devices on a single interface

[Michael Gerdau]

[snipped]
> And if it's a completely pointless idea, let me know also ;)

Ok, you asked for it... ;)

I'm sorry to say that but I personally think it's a completely
pointless idea.

- the raw count of external MIDI equipment used in professional
  music productions has passed its high watermark years ago. Most
  external gear is replaced by softsynths these days [this is to
  say the requirement for large racks of external gear which needs
  to be controlled via MIDI is diminishing]
- IMO if you are interested in tight MIDI timing you use a multiport
  MIDI interface and won't chain snyths on a single port. Cost is not
  an issue because multiport interfaces are cheap these days (or at
  least WAY cheaper than decent external synths or other gear).
- why would there be demand to switch channels dynamically in the
  first place anyway ?
  Ignoring the additional delays (and the resulting timing issues)
  introduced by the suggested switching procedure I don't see why
  you'd need to dynamically reallocate ports and channels.
  A single port gives you 16 channel, 2-/4-/8-port interfaces give
  you 32/64/128 channel for external MIDI.
  How much equipment are you going to connect ?
  And how complex will your music be that this isn't sufficient ?
  Last not least why don't you daisychain two or more of the better
  8-port interfaces ? -- w/r to tight timing a better idea anyway !

Last not least I never used the Windows MIDI mapper and to the day
I think it is useful only for very special cases.

Best,
Michael
-- 
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@technosis.de
 GPG-keys available on request or at public keyserver

Re: Ideas - Support for multiple MIDI devices on a single interface

[Andrew "Silver Blade" Greenwood]

Well I'm glad I asked now! Rather than waste (more) time I can move on 
to something else instead.

Personally I only use MIDI for input (and use soft-synths), but I do 
know of people who have loads of MIDI gear. Thus it would be quite 
difficult for me to test.

I guess it's one of those ideas I've had where I think "wow, this would 
be cool", when in fact it's just me wanting to be over-complicated ;)

-Andrew


Michael Gerdau wrote:
> [snipped]
>> And if it's a completely pointless idea, let me know also ;)
> 
> Ok, you asked for it... ;)
> 
> I'm sorry to say that but I personally think it's a completely
> pointless idea.
> 
> - the raw count of external MIDI equipment used in professional
>   music productions has passed its high watermark years ago. Most
>   external gear is replaced by softsynths these days [this is to
>   say the requirement for large racks of external gear which needs
>   to be controlled via MIDI is diminishing]
> - IMO if you are interested in tight MIDI timing you use a multiport
>   MIDI interface and won't chain snyths on a single port. Cost is not
>   an issue because multiport interfaces are cheap these days (or at
>   least WAY cheaper than decent external synths or other gear).
> - why would there be demand to switch channels dynamically in the
>   first place anyway ?
>   Ignoring the additional delays (and the resulting timing issues)
>   introduced by the suggested switching procedure I don't see why
>   you'd need to dynamically reallocate ports and channels.
>   A single port gives you 16 channel, 2-/4-/8-port interfaces give
>   you 32/64/128 channel for external MIDI.
>   How much equipment are you going to connect ?
>   And how complex will your music be that this isn't sufficient ?
>   Last not least why don't you daisychain two or more of the better
>   8-port interfaces ? -- w/r to tight timing a better idea anyway !
> 
> Last not least I never used the Windows MIDI mapper and to the day
> I think it is useful only for very special cases.
> 
> Best,
> Michael