[PD] max midi in devices

[Ingo]

For me Pd handles it like your second case anyway whether you have a single
or multiple interfaces. At least I'm receiving normal MIDI messages that way
(using OSS MIDI). If there is another way I'd be interested in finding out.
Alsa MIDI was causing problems here recognizing multi in/out MIDI interfaces
in a reproducable order.

Whether you need more than one physical MIDI cable/interface depends on the
amount of traffic that you are generating. And also on the timing precision
needed.

I'm working mostly with wind controllers like the EWI that can send up to
600 midi messages (breath, pitchbend, modulation, etc.) per second. Sending
MIDI from two of those on one physical MIDI bus will already create a bus
overflow since the MIDI bus can only handle roughly 1000 CCs per second. A
merger would be useless in this case. Timing gets absolutely unpredictable
for the player at this point. It could even go as far as making the
interface unresponsive or causing delays of several seconds caused by the
full MIDI buffer.

Playing this renaissance 4 part brass quartett from a sequencer needs 2 MIDI
interfaces going to Pd. Otherwise the timing is way off or the MIDI
interface even stops working altogether and needs to be disconnected from
power to reset the buffer:
www.dynasample.com/demos/XPression-Brass_(Dowland).mp3
(This only works on two only cables because there is no pitchbending used.
For Jazz with much more bending we'd be looking at MIDI overflows already.)

Since different MIDI controllers like an EWI, a keyboard and a MIDI guitar
have to be able to be set up at the same time (in "my" particular case) and
usable in parallel multiple physical MIDI ports are necessary to avoid
timing problems with realtime (traditional) MIDI intrument playing while
expecting a usable timing. That said MIDI over USB can handle multiple MIDI
busses at the same time. So a USB interface with multiple ins will work. My
OSS MIDI doesn't seem to be able to see these multiple ports, though. I
might have to give ALSA MIDI another try maybe. But until now I got the best
results with OSS MIDI and single USB2MIDI interfaces.

This is of course totally different in a situation where CC messages are
much more spaced out or you're not using timing critical sensors
simultaneously. Like when using only a couple of switches, note triggers,
etc.

Ingo


> -----Ursprüngliche Nachricht-----
> Von: Pd-list [mailto:pd-list-bounces at lists.iem.at] Im Auftrag von IOhannes
> m zmoelnig
> Gesendet: Montag, 25. August 2014 12:52
> An: pd-list at lists.iem.at
> Betreff: Re: [PD] max midi in devices
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 2014-08-25 12:00, Ingo wrote:
> [...]
> >
> > Now that many manufacturers are building MIDI controllers (apart
> > from keyboards, MIDI guitars, wind controllers, etc.) like a single
> > foot pedal, a single foot switch or gesture control using a full
> > MIDI interface over USB the number will be growing again. I'm
> > pretty sure of that.
> >
> > Instead of connecting one arduino that can handle 30-40 sensors
> > each controller uses its own MIDI interface.
> >
> 
> agreed to all of it.
> 
> my question was somewhat different: is it necessary to have Pd provide
> MIDI-ports for each device, or is it better/simpler/... to have all
> those devices appear on a *few* ports.
> 
> let's have an example, connecting a footswitch, a keyboard and a
> BCF2000 (in some 3-input mode).
> 
> if we have each of these assigned to a separate port, the
> MIDI-messages will appear in Pd as:
> - - footswitch: channels 1..16
> - - keyboard: channels 17..32
> - - BCF2000: channels 33..80
> obviously this only works if we get the device order correct (that is:
> persistent across reboots).
> 
> using a MIDI-merger and proper device setup we might as well have all
> of them come through a single port:
> - - footswitch: channel 1; CC 64
> - - keyboard: channels 1..16; noteon/off
> - - BCF2000: channels 1; CC1..16; channels 17..32 for other ports
> this will work regardless of whether Pd (or the system) is able to
> keep the device order consistent.
> 
> i do think that the 2nd method is superior.
> obviously, it is easy to construct use cases where this setup is not
> enough.
> but i think these are edge-case, and we should not reserve too much
> screen estate for things that will hardly ever be used. (however, it
> should/must be possible to handle these things in an *advanced* mode
> (e.g. via cmdline args)
> 
> 
> fgmad
> IOhannes
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQIcBAEBCAAGBQJT+xVjAAoJELZQGcR/ejb4LuMP/Asj3jrpFDMf4r/alFaeBNMC
> RtqicWZxe/5OTLKtAbTSeT7+j8WXsKIChABkF8kWRpoJaAuT9/L9weYl7Ocr2WBD
> N26K1UFZ/FyP3hctwvyKMVHKq/czBVvIPwUzNS2nEO0f+w50bWGqClUmqOkfnhxi
> DJ70yERjLs8xcVC4ZIiGnqVwl9Rm4zWXv8RdjAnW9CxbzTDK4txjrMy0BtCAu5yY
> dXWQ8md1xmjrRCLIJzGwa1nfnC4e6eZOr0bWafvN6fClrYXVRTrQtJ+mwk17lwEx
> FU2gWKtqK/FVAyE6Wkro2MiAYIoUCpa/cbE4Ru+v4K4jILKs+IIl9BLmb5pMsl93
> F0UhXfGIgL1m+vxtPHWNWv0YjZe41VV3YkGj4Jp6X2bfkVgD5aS2i5T/R/eyWhMO
> +gMB6ZtJ+QX30qzXph1BUrfkoq9qA7l1H1vVACEvdRdR5vKVCIgYlX/7dXGGNlr4
> a3RfUHuwuszS5ZfEdw3XZ7umT5ircz80J25IW9tkXGoqXUI6hk29qsJ9Mh03B2uJ
> IXzPI0AiyrnxzExj3YDJFLNB37NVcuNj82AGVMH7G4i2Vl8EdzWNXeD7QR8xJFMK
> PC2XPr6FeDXJHt0SxhnfwWZPMSbRG6a5P/BlrHCqNjXjoOrErk76QC9pZ1WhV1xw
> tBuEGUmCp9EXS/V7ZDHj
> =sFD/
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list