Hello, I'm on windows 8.1, I've not tested this on other windows versions but I'm not able to make work this object, I've tried to send comma separate messages but every number is preceded by a number and followed by a 0. There's something that I'm missing.? No one needs to send SysEx messages under windows?

@Patcher88 Hello again,
http://lists.puredata.info/pipermail/pd-list/2005-04/027340.html
for a "workaround",
David.

@Patcher88 Hi, I've done extensive SysEx programming in Pd, but mostly under Linux. I have tested my patches in OSX (works fine, despite other problems with Pd OSX midi) and had one brief chance to test them with a windows 8.1 box. That computer was lent to me because the owner wanted me to remove windows 8.1 and replace it with - as they said - "absolutely anything else... please!"

I thought I might as well test my patches in W8.1 before I honored their request. Trying to deal with W8.1 showed me why they were in such a hurry. I know I got as far as installing the latest windows version of Pd vanilla (0.46) from Millers' site and the proprietary driver for my midi interface. I might have also got the patches running once but after I shut down the first time I was not able to get Pd to run properly again, possibly due to a corrupt config listing or file somewhere. I had too many other problems with W8.1 to find the source of the problem, assuming it was a Pd problem and not W8.1. I haven't had the chance to test other windows versions.

All my output patches use the standard simple method of a message box with individual SysEx bytes followed by a comma and separated by a space to form the complete string. These are connected directly to a midiout object. For input I use the (sysexin) object with some port filtering and the Sysex2list patch http://www.mail-archive.com/pd-list%40iem.at/msg23400.html

It is true that Pd midi implementation has been neglected particularly on the OSX and windows platforms. Some of the reason for this neglect has to do with the devs falling into an understandably hopeful delusion that OSC was going to take over the world and midi was just going to fade away. This hasn't happened for a number of reasons and problem reports on the Pd list from people who need midi functionality have reflected this. The devs have said that these issues will be addressed but not until v0.47 at the soonest as a major overhaul of the current Mac and Windows midi code is required.

One quick follow up: There have been some improvements made since the last version of extended, so if anyone with midi problems is using that it might be worth trying the latest Pd vanilla instead.

http://msp.ucsd.edu/software.html

Thank you very much, I will try it and let you know. A pd-extended version is in work? Where I can find even an alpha or beta version of pd-extended?

The last version of Pd-Extended that I know of is the experimental 44.0 Alpha release from 2013.

http://puredata.info/downloads/pd-extended

As I understand it, the Pd-extended project is no longer active as it depended too much on the available free time of a single maintainer. Many users have just switched to vanilla and are loading up the extensions they need manually.

I've downloaded the latest pd version, the [midiin] is displaying channel messages without problems, but nothing happens with SysEx messages, even with [sysexin]. [midiout] instead isn't working at all, it gives only an error on the pd console...

I've tried it on OSX and it works fine, so the newer pd Vanilla releases haven't fixed the [midiin], [midiout], and [sysexin] objects under Windows

I've directly written to Miller Puckette, he has addressed the bug and he told me that he will try to fix it in about a month and to use pd-044.3 downloadable from here for a temporary fix of MIDI in Windows, I hope that this could be useful to other people using MIDI SysEx in Windows