Subject: Re: [linux-audio-user] restricting MIDI channels
From: Mark Knecht (mknecht_AT_controlnet.com)
Date: Tue Apr 06 2004 - 18:39:59 EEST
Florian Schmidt wrote:
> On Tue, 6 Apr 2004 10:29:55 +0200
> Frank Barknecht <fbar_AT_footils.org> wrote:
>
>
>>Hallo,
>>Mark Knecht hat gesagt: // Mark Knecht wrote:
>>
>>
>>>Wouldn't it be a nice feature in kaconnnect or qjackctl to one day
>>>add MIDI filtering?
>>
>>There are various ways to do midi filtering already. Matthias Nagorni
>>wrote a tool for that whose name I don't remember currently, and it's
>>very easy to create even complex filtering rules in Pd/jMax.
>>
>>Personally I don't think this belongs into a patch bay.
>
>
> Midi tradition is that a device decides itself for which channel
> messages it wants to listen. Every external midi device [except for very
> old ones] i had under my fingers had some sort of mechanism to specify
> which channels to listen to..
>
> The reason for this is in the nature of normal external midi setups. It
> is very common to hook up more than 2 instruments [though there is an
> upper imit because of latencies] to a single midi port.. All midi
> devices get the same midi stream so now they need to know which data is
> for which device. This is done via the channels.
>
> Breaking this concept would confuse many musicians, i suppose.. I know
> in the case of internal midi routing with ALSA where you have
> point2point connections between midi apps this doesn't relly make sense
> anymore, because usually every midi app just gets the data it needs.
>
> But still in the case of a dedicated computer that only runs softsynths
> and has a single midi interface which is connected to a sequencer [be it
> an external one or another computer] the channel selection method again
> makes very much sense..
>
> It is just part of how midi works..
>
> Flo
>
>
Florian,
Hi. You an Frank make good points, but in my opinion the points are
stronger with older style MIDI hardware devices and less so with some of
the more interesting things going on with MIDI today under different
environments.
Personally I think it does make sense to consider MIDI filtering,
translation of one channel to multiple channels, velocity curve
remapping, customized keyboard splits, and easily 5-10 more features,
and how all of this maps to multiple MIDI interfaces (hardware and
virtual) all within the confines of a single MIDI patch bay app. It's
easier to do complex mappings in a single app vs. telling different
synths to do special things. It's far easier to save settings in a
single app than trying to save and restore 5 separate soft and hard synths.
When I started working with more advanced sample libraries, such as
Garritan, Dan Dean, etc., I found more and more use for these sorts of
features. Since sometimes I'm taking a specific MIDI line and driving
multiple synths, but driving them in different ways, and then mixing
audio all done live. It's good (IMO) to have tools that encourage and
support these sorts of capabilites.
Anyway, just my thoughts. If some developer finds them interesting
then maybe one day they'll undertake to develop them. If not then I
suppose they weren't important for users of MIDI under Linux.
Thanks,
Mark
This archive was generated by hypermail 2b28 : Tue Apr 06 2004 - 18:38:33 EEST