I'm belatedly looking at this to try to figure out what if any policy is happening here...
Objects like "noteon" should report MIDI "channel" 1-16 for the first port, 17-32 for the second one, and so on. The only MIDI input objects that don't have a channel are the byte-by-byte ones, and so these get an outlet to specify port. This should be 1 for the first open MIDI port, etc. For some damn reason, the MIDI port numbers have started at 2 and not 1, probably since the dawn of Pd. I think it's worth fixing this - it's a bug and I think device numbers have been sliding around so much already that any notion of port-number compatibility is specious anyhow. I think thought that I should do this for the upcoming 0.45 and not any new 0.44 bugfix releases. cheers Miller On Tue, Jan 08, 2013 at 01:06:41PM -0800, Miller Puckette wrote: > I _think_ it would be safe to change this... anyone know of any way that > would break compatibility? > > thanks > M > > On Tue, Jan 08, 2013 at 02:58:41PM -0500, Peter Brinkmann wrote: > > Hi, > > I've been revisiting the MIDI support of libpd, and I noticed that the > > functions inmidi_byte and inmidi_sysex add one to the port number before > > passing the message on to the midiin/sysexin object. Is this the desired > > behavior? If so, why? If not, is it too late to change it? > > > > I also don't understand the output I'm getting from my Korg nanoKey: If I > > push a key on the keyboard, then [notein] outputs MIDI events for channel > > 1, while [midiin] outputs bytes for port 2. How to channel numbers and port > > numbers fit together? > > Thanks, > > Peter > > > _______________________________________________ > > Pd-dev mailing list > > Pd-dev@iem.at > > http://lists.puredata.info/listinfo/pd-dev > > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev