Hi,
I am hoping someone can give me advise on getting my Ubuntu box to send sysex message over MIDI.
Some questions..
What is the proper format for messages to go into [midiout] or [sysexout]?
Do I make a list of numbers such as [247 NN .. .. .. NN 240<
or do I need to serialize them as [sysexin] receives each byte as individual messages?
Previous posts on the same topic were a bit too vague for me to catch up with. Although I use Debian & Ubuntu daily, unfortunately I am not fluent in developing practices enough to design my own workarounds (at least not yet).
The closest I could get was the understanding that there is no method to get Sysex output to work other than patching Pd so a different kind of function in ALSA-API will be used. (also that the current releases have a 20 byte limit. This is probably not my case though)
If current pd-extended (which I am comfortable with, either stable or testing) needs patching in order for midiout to work, I would highly appreciate specific procedures on how to get it going, hopefully on a fresh installation of Ubuntu 8.04 or 7.10.
Any type of help appreciated. Thanks.
-- David Shimamoto
Is it out of the question simply to use the OSS MIDI API? That should be the default, and it's much less buggy than the ALSA one. (Apparently, though, there's sometimes a good reason to use teh ALSA one instead, I remember vaguely.)
To put out "sysex" MIDI, theoretically in either ALSA or OSS, send the bytes out serially, as in "247, NN, NN, 240", not in a list as in "247 NN NN 240".
cheers Miller
On Mon, May 26, 2008 at 02:20:19AM +0900, PSPunch wrote:
Hi,
I am hoping someone can give me advise on getting my Ubuntu box to send sysex message over MIDI.
Some questions..
What is the proper format for messages to go into [midiout] or [sysexout]?
Do I make a list of numbers such as [247 NN .. .. .. NN 240<
or do I need to serialize them as [sysexin] receives each byte as individual messages?
Previous posts on the same topic were a bit too vague for me to catch up with. Although I use Debian & Ubuntu daily, unfortunately I am not fluent in developing practices enough to design my own workarounds (at least not yet).
The closest I could get was the understanding that there is no method to get Sysex output to work other than patching Pd so a different kind of function in ALSA-API will be used. (also that the current releases have a 20 byte limit. This is probably not my case though)
If current pd-extended (which I am comfortable with, either stable or testing) needs patching in order for midiout to work, I would highly appreciate specific procedures on how to get it going, hopefully on a fresh installation of Ubuntu 8.04 or 7.10.
Any type of help appreciated. Thanks.
-- David Shimamoto
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, May 25, 2008 at 11:12:24AM -0700, Miller Puckette wrote:
Is it out of the question simply to use the OSS MIDI API? That should be the default, and it's much less buggy than the ALSA one. (Apparently, though, there's sometimes a good reason to use teh ALSA one instead, I remember vaguely.)
I think that the good reason to use ALSA is that OSS is even more deprecated than [namecanvas], in that everyone is switching away from it as fast as possible.
Best,
Chris.
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
On Sun, May 25, 2008 at 11:12:24AM -0700, Miller Puckette wrote:
Is it out of the question simply to use the OSS MIDI API? That should be the default, and it's much less buggy than the ALSA one. (Apparently, though, there's sometimes a good reason to use teh ALSA one instead, I remember vaguely.)
I think that the good reason to use ALSA is that OSS is even more deprecated than [namecanvas], in that everyone is switching away from it as fast as possible.
Pd is not really using the "OSS Midi API" anyway. It's using raw midi devices when started as -oss, and these raw midi devices are available in OSS and in pure ALSA as well, in ALSA they are called e.g. /dev/snd/midiC0D0
"pd -alsa" is using the ALSA sequencer API, the equivalent with OSS would be /dev/sequencer, but Pd never supported that. ALSA sequencer makes interconnecting applications much easier that with raw midi devices. (I once wrote a howto to explain the latter, it's overly complicated.) I've never used sysex, though.
Ciao
Frank Barknecht
Frank Barknecht wrote:
"pd -alsa" is using the ALSA sequencer API, the equivalent with OSS would be /dev/sequencer, but Pd never supported that. ALSA sequencer
the problem is rather, that ALSA sequencer does not support MIDI in a way Pd would like it, mainly: no raw midi.
david,miller: i don't think that the suggested solution [247, NN, NN, 240( will actually work (but i haven't tested, of course) because of the non-existing raw-midi: instead all of your bytes will be encapsulated into separate sysex packages, which is kind of dumb... (at least this is what kmidimon tells me when intercepting the outgoing midi-stream)
fga,sdr IOhannes
IOhannes,
david,miller: i don't think that the suggested solution [247, NN, NN, 240( will actually work (but i haven't tested, of course) because of the non-existing raw-midi: instead all of your bytes will be encapsulated into separate sysex packages, which is kind of dumb... (at least this is what kmidimon tells me when intercepting the outgoing midi-stream)
Do you mean that you can send messages eliminating F7 and F0 to let the API compensate for it?
So far I haven't been able to get kmidimon routed through qjackctl + Alsa-MIDI to respond to anything sent to [midiout].
I did locate your post regarding the mentioned behavior (Thanks to Hans for pointing me)
Can you please tell me if you've done anything special to at least get it recognized by kmidimon?
david,miller: i don't think that the suggested solution [247, NN, NN, 240( will actually work (but i haven't tested, of course) because of the non-existing raw-midi: instead all of your bytes will be encapsulated into separate sysex packages, which is kind of dumb... (at least this is what kmidimon tells me when intercepting the outgoing midi-stream)
Do you mean that you can send messages eliminating F7 and F0 to let the API compensate for it?
I'm looking at the source code in svn, assuming you use [midiout] to send sysex. The midiout object has one method, for floats : midiout_float(), in x_midi.c, line 681. It just calls outmidi_byte() in s_midi.c, line 239. If Pd was compiled with USEAPI_ALSA defined, then outmidi_byte calls sys_alsa_putmidibyte() in s_midi_alsa.c line 234, otherwise it calls sys_putmidibyte() in s_midi_oss.c line 182. These functions just send a single byte. There is no interpretation done, no F0 or F7 are added. Each byte is sent separately through the port without being queued.
Possibly if the bytes of a sysex packet are too far apart in time other software may not receive it correctly? Or if you send the bytes as one message Pd interprets the second byte as an argument for midiout, since midiout has no method for list, the default method will be used. Or maybe you have the status bytes backwards: sysex begins with F0 (240) and ends with F7 (247). All the bytes in between must be less than 128. The example above should be [240, NN, NN, 247(
Martin
Martin,
I'm looking at the source code in svn, assuming you use [midiout] to send sysex. The midiout object has one method, for floats : midiout_float(), in x_midi.c, line 681. It just calls outmidi_byte() in s_midi.c, line 239. If Pd was compiled with USEAPI_ALSA defined, then outmidi_byte calls sys_alsa_putmidibyte() in s_midi_alsa.c line 234, otherwise it calls sys_putmidibyte() in s_midi_oss.c line 182.
Do you mean that theoretically, Pd + ALSA MIDI should be working? hmmm...
According to IOhannes,
the problem is rather, that ALSA sequencer does not support MIDI in a way Pd would like it, mainly: no raw midi.
Also I think one of the recent posts which I cannot locate now, mentioned that it was just a matter of Pd using a function in ALSA API other than what is used at the moment.
Or has this been fixed and is it me not doing things right?
These functions just send a single byte. There is no interpretation done, no F0 or F7 are added. Each byte is sent separately through the port without being queued.
Ooops, I had this wrong. I did have it in the correct order in my patch.
-- David Shimamoto
PSPunch wrote:
Martin,
I'm looking at the source code in svn, assuming you use [midiout] to send sysex. The midiout object has one method, for floats : midiout_float(), in x_midi.c, line 681. It just calls outmidi_byte() in s_midi.c, line 239. If Pd was compiled with USEAPI_ALSA defined, then outmidi_byte calls sys_alsa_putmidibyte() in s_midi_alsa.c line 234, otherwise it calls sys_putmidibyte() in s_midi_oss.c line 182.
Do you mean that theoretically, Pd + ALSA MIDI should be working? hmmm...
Well it looks like it should but I just tried with a scope on the cable and got messages using [noteout] but nothing using [midiout] with alsa midi and jack. I tried sending bytes singly and in comma-separated messages as well as just lists. Nothing comes out.
According to IOhannes,
the problem is rather, that ALSA sequencer does not support MIDI in a way Pd would like it, mainly: no raw midi.
Yes, it looks like the ALSA function being called expects a complete sysex message but instead it's getting one byte at a time. I guess Pd should buffer the message until it gets an F7 (End of Exclusive) and then send the whole thing as one packet. Not too difficult except for anticipating what the the maximum message size is going to be. Maybe a [sysexout] object that takes lists of bytes (and inserts the F0 and F7) is in order...
Also I think one of the recent posts which I cannot locate now, mentioned that it was just a matter of Pd using a function in ALSA API other than what is used at the moment.
Well I think it's better to send a complete sysex packet, otherwise it could be trashed by a noteout or similar that occurs before the F7 goes out. Really Pd should buffer the packet and only then send it to ALSA.
Martin
Does anyone have any opinion on the specs suggested by Martin? Should [sysexout] behave in this manner, or would it be more suitable to make this a new object rather than over write the conventional object for compatibility?
I have no idea if I will be skilled to fix this in the near future, but I really would love to see some of my MIDI controllers in action.
-- David Shimamoto
PSPunch wrote:
Martin,
I'm looking at the source code in svn, assuming you use [midiout] to send sysex. The midiout object has one method, for floats : midiout_float(), in x_midi.c, line 681. It just calls outmidi_byte() in s_midi.c, line 239. If Pd was compiled with USEAPI_ALSA defined, then outmidi_byte calls sys_alsa_putmidibyte() in s_midi_alsa.c line 234, otherwise it calls sys_putmidibyte() in s_midi_oss.c line 182.
Do you mean that theoretically, Pd + ALSA MIDI should be working? hmmm...
Well it looks like it should but I just tried with a scope on the cable and got messages using [noteout] but nothing using [midiout] with alsa midi and jack. I tried sending bytes singly and in comma-separated messages as well as just lists. Nothing comes out.
According to IOhannes,
the problem is rather, that ALSA sequencer does not support MIDI in a way Pd would like it, mainly: no raw midi.
Yes, it looks like the ALSA function being called expects a complete sysex message but instead it's getting one byte at a time. I guess Pd should buffer the message until it gets an F7 (End of Exclusive) and then send the whole thing as one packet. Not too difficult except for anticipating what the the maximum message size is going to be. Maybe a [sysexout] object that takes lists of bytes (and inserts the F0 and F7) is in order...
Also I think one of the recent posts which I cannot locate now, mentioned that it was just a matter of Pd using a function in ALSA API other than what is used at the moment.
Well I think it's better to send a complete sysex packet, otherwise it could be trashed by a noteout or similar that occurs before the F7 goes out. Really Pd should buffer the packet and only then send it to ALSA.
Martin
So I tried [240, 1, 247( | [midiout] on Pd 0-42-0test1 and the message shows up on the MIDI plug. It also works to send one byte at a time. But with Pd0.40.3-extended20080324 it doesn't work, although [noteout] and [ctlout] work fine. This is with ALSA-MIDI and Jack. Martin
PSPunch wrote:
Does anyone have any opinion on the specs suggested by Martin? Should [sysexout] behave in this manner, or would it be more suitable to make this a new object rather than over write the conventional object for compatibility?
I have no idea if I will be skilled to fix this in the near future, but I really would love to see some of my MIDI controllers in action.
-- David Shimamoto
PSPunch wrote:
Martin,
I'm looking at the source code in svn, assuming you use [midiout] to send sysex. The midiout object has one method, for floats : midiout_float(), in x_midi.c, line 681. It just calls outmidi_byte() in s_midi.c, line 239. If Pd was compiled with USEAPI_ALSA defined, then outmidi_byte calls sys_alsa_putmidibyte() in s_midi_alsa.c line 234, otherwise it calls sys_putmidibyte() in s_midi_oss.c line 182.
Do you mean that theoretically, Pd + ALSA MIDI should be working? hmmm...
Well it looks like it should but I just tried with a scope on the cable and got messages using [noteout] but nothing using [midiout] with alsa midi and jack. I tried sending bytes singly and in comma-separated messages as well as just lists. Nothing comes out.
According to IOhannes,
the problem is rather, that ALSA sequencer does not support MIDI in a way Pd would like it, mainly: no raw midi.
Yes, it looks like the ALSA function being called expects a complete sysex message but instead it's getting one byte at a time. I guess Pd should buffer the message until it gets an F7 (End of Exclusive) and then send the whole thing as one packet. Not too difficult except for anticipating what the the maximum message size is going to be. Maybe a [sysexout] object that takes lists of bytes (and inserts the F0 and F7) is in order...
Also I think one of the recent posts which I cannot locate now, mentioned that it was just a matter of Pd using a function in ALSA API other than what is used at the moment.
Well I think it's better to send a complete sysex packet, otherwise it could be trashed by a noteout or similar that occurs before the F7 goes out. Really Pd should buffer the packet and only then send it to ALSA.
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Martin,
Thank you so much for the info. I have confirmed this using kmidimon, and getting ready to send actual messages to my hardware with one hand while I type with the other.
Now I am curious, if this was fixed by a recently posted patch, how come it was not mentioned earlier?
Maybe I am just not fully aware of how CVS or SVN work.
-- David Shimamoto
So I tried [240, 1, 247( | [midiout] on Pd 0-42-0test1 and the message shows up on the MIDI plug. It also works to send one byte at a time. But with Pd0.40.3-extended20080324 it doesn't work, although [noteout] and [ctlout] work fine. This is with ALSA-MIDI and Jack. Martin
PSPunch wrote:
Does anyone have any opinion on the specs suggested by Martin? Should [sysexout] behave in this manner, or would it be more suitable to make this a new object rather than over write the conventional object for compatibility?
I have no idea if I will be skilled to fix this in the near future, but I really would love to see some of my MIDI controllers in action.
-- David Shimamoto
PSPunch wrote:
Martin,
I'm looking at the source code in svn, assuming you use [midiout] to send sysex. The midiout object has one method, for floats : midiout_float(), in x_midi.c, line 681. It just calls outmidi_byte() in s_midi.c, line 239. If Pd was compiled with USEAPI_ALSA defined, then outmidi_byte calls sys_alsa_putmidibyte() in s_midi_alsa.c line 234, otherwise it calls sys_putmidibyte() in s_midi_oss.c line 182.
Do you mean that theoretically, Pd + ALSA MIDI should be working? hmmm...
Well it looks like it should but I just tried with a scope on the cable and got messages using [noteout] but nothing using [midiout] with alsa midi and jack. I tried sending bytes singly and in comma-separated messages as well as just lists. Nothing comes out.
According to IOhannes,
the problem is rather, that ALSA sequencer does not support MIDI in a way Pd would like it, mainly: no raw midi.
Yes, it looks like the ALSA function being called expects a complete sysex message but instead it's getting one byte at a time. I guess Pd should buffer the message until it gets an F7 (End of Exclusive) and then send the whole thing as one packet. Not too difficult except for anticipating what the the maximum message size is going to be. Maybe a [sysexout] object that takes lists of bytes (and inserts the F0 and F7) is in order...
Also I think one of the recent posts which I cannot locate now, mentioned that it was just a matter of Pd using a function in ALSA API other than what is used at the moment.
Well I think it's better to send a complete sysex packet, otherwise it could be trashed by a noteout or similar that occurs before the F7 goes out. Really Pd should buffer the packet and only then send it to ALSA.
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, May 25, 2008 at 11:12:24AM -0700, Miller Puckette wrote:
Is it out of the question simply to use the OSS MIDI API? That should be the default, and it's much less buggy than the ALSA one. (Apparently, though, there's sometimes a good reason to use teh ALSA one instead, I remember vaguely.)
To put out "sysex" MIDI, theoretically in either ALSA or OSS, send the bytes out serially, as in "247, NN, NN, 240", not in a list as in "247 NN NN 240".
OSS has, IIRC, been deprecated for many years now.
ALSA should be the correct one to use on Linux.
And, also, for the past year or so there's been a new JACK MIDI API which is a lot cleaner (and strongly-timed) than ALSA, although it of course uses ALSA for transmission to actual MIDI devices.
-ken
Ken,
OSS has, IIRC, been deprecated for many years now.
ALSA should be the correct one to use on Linux.
Deprecated in terms of people abandoning it, or is it literally not functioning any more?
To be specific, what I am trying to get working is a Korg padKontrol which is basically a USB-MIDI device. As soon at it is connected to my Ubuntu box, it is recognized as an Alsa-MIDI device. When routing this to Pd, only Sysex messages are dropped. (No response when routing directly to kmidimon either)
Since Miller had suggested its usage, I was hoping OSS to work but not quite yet. I understand that this classic API takes a different approach from ALSA and expects applications to route directly to each other. The list of MIDI devices that Pd offers to connect to is simply blank. Is there such thing as a wrapper that lets Alsa-MIDI devices be recognized as OSS devices?
-- David Shimamoto
And, also, for the past year or so there's been a new JACK MIDI API which is a lot cleaner (and strongly-timed) than ALSA, although it of course uses ALSA for transmission to actual MIDI devices.
-ken
I'm still curious why the "raw" MIDI doesn't work for you. I need to find someone with a similar USB MIDI device to try to figure this out. I did recently find out that the raw interface has a bug that prevents it from opening /dev/midi for reading only and for writing only; the only operation that works is for both reading and writing. I've got a fix for that (s_midi_oss.c; change two occurrences of "devno == 1" to "devno == 0").
But this wouldn't help if, as I read your letter, you simply don't see any input or output devices at all, for instance in the midi settings dialog. That sounds like a different problem from the one I was having.
cheers Miller
On Mon, May 26, 2008 at 10:11:53PM +0900, PSPunch wrote:
Ken,
OSS has, IIRC, been deprecated for many years now.
ALSA should be the correct one to use on Linux.
Deprecated in terms of people abandoning it, or is it literally not functioning any more?
To be specific, what I am trying to get working is a Korg padKontrol which is basically a USB-MIDI device. As soon at it is connected to my Ubuntu box, it is recognized as an Alsa-MIDI device. When routing this to Pd, only Sysex messages are dropped. (No response when routing directly to kmidimon either)
Since Miller had suggested its usage, I was hoping OSS to work but not quite yet. I understand that this classic API takes a different approach from ALSA and expects applications to route directly to each other. The list of MIDI devices that Pd offers to connect to is simply blank. Is there such thing as a wrapper that lets Alsa-MIDI devices be recognized as OSS devices?
-- David Shimamoto
And, also, for the past year or so there's been a new JACK MIDI API which is a lot cleaner (and strongly-timed) than ALSA, although it of course uses ALSA for transmission to actual MIDI devices.
-ken
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi, Miller,
Yes, it is a USB-MIDI device which currently appears only under the list of "ALSA-MIDI" devices.
However, the same behaviors I've seen apply also to the application kmidimon. I think that if there is a way to get kmidimon to appear as an OSS MIDI device, theoretically the same procedure should work with my hardware.
Does anyone know of methods, or perhaps wrappers that may get this going?
-- David Shimamoto
I'm still curious why the "raw" MIDI doesn't work for you. I need to find someone with a similar USB MIDI device to try to figure this out. I did recently find out that the raw interface has a bug that prevents it from opening /dev/midi for reading only and for writing only; the only operation that works is for both reading and writing. I've got a fix for that (s_midi_oss.c; change two occurrences of "devno == 1" to "devno == 0").
But this wouldn't help if, as I read your letter, you simply don't see any input or output devices at all, for instance in the midi settings dialog. That sounds like a different problem from the one I was having.
cheers Miller
On Mon, May 26, 2008 at 10:11:53PM +0900, PSPunch wrote:
Ken,
OSS has, IIRC, been deprecated for many years now.
ALSA should be the correct one to use on Linux.
Deprecated in terms of people abandoning it, or is it literally not functioning any more?
To be specific, what I am trying to get working is a Korg padKontrol which is basically a USB-MIDI device. As soon at it is connected to my Ubuntu box, it is recognized as an Alsa-MIDI device. When routing this to Pd, only Sysex messages are dropped. (No response when routing directly to kmidimon either)
Since Miller had suggested its usage, I was hoping OSS to work but not quite yet. I understand that this classic API takes a different approach from ALSA and expects applications to route directly to each other. The list of MIDI devices that Pd offers to connect to is simply blank. Is there such thing as a wrapper that lets Alsa-MIDI devices be recognized as OSS devices?
-- David Shimamoto
And, also, for the past year or so there's been a new JACK MIDI API which is a lot cleaner (and strongly-timed) than ALSA, although it of course uses ALSA for transmission to actual MIDI devices.
-ken
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Chris McCormick -
Frank Barknecht -
IOhannes m zmoelnig -
Ken Restivo -
Martin Peach -
Miller Puckette -
PSPunch