[PD] max midi in devices

Miller Puckette msp at ucsd.edu
Tue Aug 26 01:08:56 CEST 2014


I'm learning that the world of MIDI applications is a lot more complicated
than I thought...

I don't think using 'OSS MIDI' that there's any way to prevent having
the order of the devices switch around - and there seems to be no way to
get meaningful names for them either.

I've been hacking on the ASA MIDI code in Pd too, and found the situation
highly confusing.  Apparently in Pd the first ALSA midi device is 'default'
and ones after that are virtual ports that Pd creates (there's other mail
in this thread somewhere about that).  I'm just now trying to figure it out.

Meanwhile, I hope you can just get the very latest Pd from git and try

pd -alsamidi -mididev 1,2,3,4,5

to make Pd open the 'defaul' plus 4 virtual ports for connecting to stuff.

(in fact, I see the ports open but can't figure out how to do anything with
them just yet.)

cheers
Miller

On Mon, Aug 25, 2014 at 02:05:44PM +0200, Ingo wrote:
> 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
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



More information about the Pd-list mailing list