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@lists.iem.at] Im Auftrag von IOhannes m zmoelnig Gesendet: Montag, 25. August 2014 12:52 An: pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list