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