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