I know someone mentioned this about a week ago, but I just wanted to add myself to the list of people for whom [midiout] is broken.
In Miller's version 0.39-1 on Linux, [midiout] works fine with default- MIDI, but when switching over to ALSA-MIDI midiout simply outputs nothing.
Does this need to filed as a bug report somewhere?
I'm not sure what to do about this... I patched the ALSA MIDI support from the "devel" version and can't tell, looking at the CVS log, who wrote it. It looks like alsa's MIDI implementation is wrong-headed (insists that outgoing MIDI be formatted by the application) and would be a pain to work around to get midiout to work correctly.
Probably the thing I should do right now is to print out a warning message about it when people try to use it...
cheers Miller
On Fri, Nov 11, 2005 at 04:00:00PM +0000, Jamie Bullock wrote:
I know someone mentioned this about a week ago, but I just wanted to add myself to the list of people for whom [midiout] is broken.
In Miller's version 0.39-1 on Linux, [midiout] works fine with default- MIDI, but when switching over to ALSA-MIDI midiout simply outputs nothing.
Does this need to filed as a bug report somewhere?
-- Regards,
Jamie
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I just checked devel (0.38.4 devel 2) on my machine, and that's exactly what it does. Try to use midiout, and you get:
putmidibyte not implemented, please report as a bug
I have just submitted it as a bug report for devel, should it be submitted for 'official' as well?
Jamie
On Sat, 2005-11-12 at 12:34 -0800, Miller Puckette wrote:
I'm not sure what to do about this... I patched the ALSA MIDI support from the "devel" version and can't tell, looking at the CVS log, who wrote it. It looks like alsa's MIDI implementation is wrong-headed (insists that outgoing MIDI be formatted by the application) and would be a pain to work around to get midiout to work correctly.
Probably the thing I should do right now is to print out a warning message about it when people try to use it...
cheers Miller
On Sun, 13 Nov 2005, Jamie Bullock wrote:
I just checked devel (0.38.4 devel 2) on my machine, and that's exactly what it does. Try to use midiout, and you get:
putmidibyte not implemented, please report as a bug
I have just submitted it as a bug report for devel, should it be submitted for 'official' as well?
FYI the ALSA midi code was contributed by Pablo Martin, I put the warning into the sys_putmidibyte() function, because, as Miller says it seemed to be a pain to implement this function correctly.
Anyhow, steve implemented the function.
Well, so far the history, see
for more. Anyhow if you want to submit a bug report, please do it against the latest version, in this case it would have been important because the code changed and noone is probably going to fix 0.38 devel anymore.
Get the latest version of pd from http://crca.ucsd.edu/~msp/software.html
or the latest from the CVS for the devel branch.
Cheers,
Guenter
Jamie
On Sat, 2005-11-12 at 12:34 -0800, Miller Puckette wrote:
I'm not sure what to do about this... I patched the ALSA MIDI support from the "devel" version and can't tell, looking at the CVS log, who wrote it. It looks like alsa's MIDI implementation is wrong-headed (insists that outgoing MIDI be formatted by the application) and would be a pain to work around to get midiout to work correctly.
Probably the thing I should do right now is to print out a warning message about it when people try to use it...
cheers Miller
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 2005-11-13 at 21:06 +0100, günter geiger wrote:
<snip> > > FYI the ALSA midi code was contributed by Pablo Martin, I put the > warning into the sys_putmidibyte() function, because, as Miller says > it seemed to be a pain to implement this function correctly. > > Anyhow, steve implemented the function. > > Well, so far the history, see > > http://tinyurl.com/ay7qd > > for more. Anyhow if you want to submit a bug report, please do it against > the latest version, in this case it would have been important because the code > changed and noone is probably going to fix 0.38 devel anymore. > Sorry about that. I don't use devel, I just wanted to see if this particular feature was broken in devel as well as Miller's version. It didn't occur to me to use the CVS! The problem still exists in both Miller's latest version, and the latest devel version, so I have re- submitted the bug for devel.
If a bug exists in both devel and Miller, is it best to submit the same report for both, or just one?
Jamie
hi, I am that guy that wrote about that midiout problem.
I'm not sure what to do about this... I patched the ALSA MIDI support from the "devel" version and can't tell, looking at the CVS log, who wrote it.
I am looking at s_midi_alsa.c (http://cvs.sourceforge.net/viewcvs.py/pure-data/pd/src/s_midi_alsa.c?rev=1.1...)
I don't see any changes from my local version. last time I checked midiout functionality with alsa_midi, note and controllers worked ok, but system exclusive were not transmitted. in fact I discovered that sys_alsa_putmidibyte never gets called (!). in addition I am not sure if a message can be sent to alsa byte-per-byte instead of passing the entire buffer, i should look at the docs...
It looks like alsa's MIDI implementation is wrong-headed (insists that outgoing MIDI be formatted by the application) and would be a pain to work around to get midiout to work correctly.
I do not understand this very well. could you write some more details about this?
Probably the thing I should do right now is to print out a warning message about it when people try to use it...
._.
-- ciao Federico
On Sun, 13 Nov 2005, federico wrote:
I don't see any changes from my local version. last time I checked midiout functionality with alsa_midi, note and controllers worked ok, but system exclusive were not transmitted. in fact I discovered that sys_alsa_putmidibyte never gets called (!). in addition I am not sure if a message can be sent to alsa byte-per-byte instead of passing the entire buffer, i should look at the docs...
I fear that in order to make midiout work with ALSA one has to implement a midi parser and send the single events. Thats why Miller says its "wrong-headed".
Somone should really try to figure out how raw midi streams can be sent via the ALSA sequencer interface, maybe there's a way.
Cheers,
Guenter
It looks like alsa's MIDI implementation is wrong-headed (insists that outgoing MIDI be formatted by the application) and would be a pain to work around to get midiout to work correctly.
I do not understand this very well. could you write some more details about this?
Probably the thing I should do right now is to print out a warning message about it when people try to use it...
._.
-- ciao Federico
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Monday 14 November 2005 12:40, günter geiger wrote:
On Sun, 13 Nov 2005, federico wrote:
I don't see any changes from my local version. last time I checked midiout functionality with alsa_midi, note and controllers worked ok, but system exclusive were not transmitted. in fact I discovered that sys_alsa_putmidibyte never gets called (!). in addition I am not sure if a message can be sent to alsa byte-per-byte instead of passing the entire buffer, i should look at the docs...
I fear that in order to make midiout work with ALSA one has to implement a midi parser and send the single events. Thats why Miller says its "wrong-headed".
I think alsa-lib has a build in midi parser that can translate raw bytes to events and vice versa. The api is complicated and under-documented. It is as if the alsa people don't want developers to use it, it is hidden underneath several layers of documentation :) I have used it for midi input, but it should be possible to use it for midi output. http://www.alsa-project.org/alsa-doc/alsa-lib/group___m_i_d_i___event.html
Unfortunately I have no time at the moment to implement this :(
G
Somone should really try to figure out how raw midi streams can be sent via the ALSA sequencer interface, maybe there's a way.
int snd_midi_event_encode_byte ( snd_midi_event_t * dev, int c, snd_seq_event_t * ev)
gÃŒnter geiger wrote:
On Sun, 13 Nov 2005, federico wrote:
I don't see any changes from my local version. last time I checked midiout functionality with alsa_midi, note and controllers worked ok, but system exclusive were not transmitted. in fact I discovered that sys_alsa_putmidibyte never gets called (!). in addition I am not sure if a message can be sent to alsa byte-per-byte instead of passing the entire buffer, i should look at the docs...
Somone should really try to figure out how raw midi streams can be sent via the ALSA sequencer interface, maybe there's a way.
hmm, i had another quick(!) look at the code and federico's observation that sys_alsa_putmidibyte() never get's called seems to be the more tragic issue than the wrong headed implementation of "raw" midi in the alsa-sequencer. i have committed a fix for this to the patch-tracker at https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1356455...
the actual implementation of raw midi-out is still based on the sysex-hack, but is now seems at least to work correctly. (but i have no possibility to test whether it works exactly like oss-[midiout])
mfg.asd.r IOhannes
On Mon, 14 Nov 2005, IOhannes m zmoelnig wrote:
hmm, i had another quick(!) look at the code and federico's observation that sys_alsa_putmidibyte() never get's called seems to be the more tragic issue than the wrong headed implementation of "raw" midi in the alsa-sequencer. i have committed a fix for this to the patch-tracker at https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1356455...
the actual implementation of raw midi-out is still based on the sysex-hack, but is now seems at least to work correctly. (but i have no possibility to test whether it works exactly like oss-[midiout])
There is also a memory leak in the sys_alsa_putmidibyte() implementation, so enabling it might be a bad idea. Someone should dig into the ALSA doc and fix it for real. (I would if I had the time)
Cheers,
Guenter
günter geiger ha scritto:
On Sun, 13 Nov 2005, federico wrote:
I don't see any changes from my local version. last time I checked midiout functionality with alsa_midi, note and controllers worked ok, but system exclusive were not transmitted. in fact I discovered that sys_alsa_putmidibyte never gets called (!). in addition I am not sure if a message can be sent to alsa byte-per-byte instead of passing the entire buffer, i should look at the docs...
I fear that in order to make midiout work with ALSA one has to implement a midi parser and send the single events. Thats why Miller says its "wrong-headed".
Somone should really try to figure out how raw midi streams can be sent via the ALSA sequencer interface, maybe there's a way.
this patch was submitted time ago. what does tries to fix? it simply parses for system exclusive messages (they begin with 0xf0 and end with 0xf7) so we put everithing that comes between 0xf0...0xf7 in a buffer, and when receiving the 0xf7 byte (end-of-sysex) we send the entire buffer to alsa. this should be the right way of doing it. since note&controllers worked, i think it is okay sending them like we actually do.
however when I tried this didn't work because sys_alsa_putmidibyte doesn't gets called. how do I re-enable it?
--- pd-0.39-1.orig/src/s_midi_alsa.c 2005-08-20 01:25:19.000000000 +0200 +++ pd-0.39-1/src/s_midi_alsa.c 2005-10-24 21:17:27.000000000 +0200 @@ -163,20 +163,39 @@ void sys_alsa_putmidimess(int portno, in
void sys_alsa_putmidibyte(int portno, int byte) { +#define dataptr_sz 1024
- static unsigned int dataptr_pos = 0;
- static unsigned char dataptr[dataptr_sz];
- fprintf(stderr, "midi byte: 0x%2,2X\n");
snd_seq_ev_clear(&ev); if (portno >= 0 && portno < alsa_nmidiout) {snd_seq_event_t ev;
// repack into 1 byte char and put somewhere to point atunsigned char data = (unsigned char)byte;unsigned char *dataptr = malloc(1);memcpy(dataptr,&byte,1);snd_seq_ev_set_sysex(&ev,1,dataptr); //...set_variable *should*
have worked but didn't
snd_seq_ev_set_direct(&ev);snd_seq_ev_set_subs(&ev);snd_seq_ev_set_source(&ev,alsa_midioutfd[portno]);snd_seq_event_output_direct(midi_handle,&ev);
- if(dataptr_pos < dataptr_sz) {
// store sysex (from xf0 to xf7) in a buffer...if(dataptr_pos == 0 && byte != 0xf0) return; // drop unexpeted
result
dataptr[dataptr_pos++] = (unsigned char)byte;if(byte != 0xf7) return; // wait til xf7- } else {
// overflow: drop the msgdataptr_pos = 0;return;- }
- int i;
- fprintf(stderr, "sending sysex (len=%d)", dataptr_pos);
- for(i=0; i<dataptr_pos; i++) fprintf(stderr, " 0x%.2X", dataptr[i]);
- fprintf(stderr, "\n");
- if(dataptr_pos > 0) {
snd_seq_ev_set_sysex(&ev,dataptr_pos,dataptr);snd_seq_ev_set_direct(&ev);snd_seq_ev_set_subs(&ev);snd_seq_ev_set_source(&ev,alsa_midioutfd[portno]);snd_seq_event_output_direct(midi_handle,&ev);- } }
}
On Mon, 14 Nov 2005, federico wrote:
this patch was submitted time ago.
Did you submit it to the patches tracker ?
Guenter
what does tries to fix? it simply parses for system exclusive messages (they begin with 0xf0 and end with 0xf7) so we put everithing that comes between 0xf0...0xf7 in a buffer, and when receiving the 0xf7 byte (end-of-sysex) we send the entire buffer to alsa. this should be the right way of doing it. since note&controllers worked, i think it is okay sending them like we actually do.
however when I tried this didn't work because sys_alsa_putmidibyte doesn't gets called. how do I re-enable it?
--- pd-0.39-1.orig/src/s_midi_alsa.c 2005-08-20 01:25:19.000000000 +0200 +++ pd-0.39-1/src/s_midi_alsa.c 2005-10-24 21:17:27.000000000 +0200 @@ -163,20 +163,39 @@ void sys_alsa_putmidimess(int portno, in
void sys_alsa_putmidibyte(int portno, int byte) { +#define dataptr_sz 1024
- static unsigned int dataptr_pos = 0;
- static unsigned char dataptr[dataptr_sz];
- fprintf(stderr, "midi byte: 0x%2,2X\n");
snd_seq_event_t ev;
// repack into 1 byte char and put somewhere to point atunsigned char data = (unsigned char)byte;unsigned char *dataptr = malloc(1);memcpy(dataptr,&byte,1);snd_seq_ev_set_sysex(&ev,1,dataptr); //...set_variable *should*have worked but didn't
snd_seq_ev_set_direct(&ev);snd_seq_ev_set_subs(&ev);snd_seq_ev_set_source(&ev,alsa_midioutfd[portno]);snd_seq_event_output_direct(midi_handle,&ev);
- if(dataptr_pos < dataptr_sz) {
// store sysex (from xf0 to xf7) in a buffer...if(dataptr_pos == 0 && byte != 0xf0) return; // drop unexpetedresult
dataptr[dataptr_pos++] = (unsigned char)byte;if(byte != 0xf7) return; // wait til xf7- } else {
// overflow: drop the msgdataptr_pos = 0;return;- }
- int i;
- fprintf(stderr, "sending sysex (len=%d)", dataptr_pos);
- for(i=0; i<dataptr_pos; i++) fprintf(stderr, " 0x%.2X", dataptr[i]);
- fprintf(stderr, "\n");
- if(dataptr_pos > 0) {
snd_seq_ev_set_sysex(&ev,dataptr_pos,dataptr);snd_seq_ev_set_direct(&ev);snd_seq_ev_set_subs(&ev);snd_seq_ev_set_source(&ev,alsa_midioutfd[portno]);snd_seq_event_output_direct(midi_handle,&ev);- } }
}
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
federico -
günter geiger -
IOhannes m zmoelnig -
Jamie Bullock -
Miller Puckette -
vanDongen/Gilcher