(moving this thread to pd-dev where i think it belongs)
federico wrote:
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?
look at the patch i have submitted yesterday to the patch-tracker. it does exactly this: enable that calling of sys_alsa_putmidibyte() from within [midiout] (depending on which midi-api is used)
however, i am not totally convinced of wrapping [midiout] into "real" sysex-blocks. for this i would suggest a separate [sysexout]-object.
the old code does work fine (_if_ sys_alsa_putmidibyte() gets called!) the memory leak, gÃŒnter was referring too, could be fixed by just _not_ allocating dataptr without freeing it.
the attached stupid little patch seems to work here (again i just tested it with aconnecting the pd's midiout with pd's midiin)
mfg.asd.r IOhannes
Index: s_midi_alsa.c =================================================================== RCS file: /cvsroot/pure-data/pd/src/s_midi_alsa.c,v retrieving revision 1.4 diff -r1.4 s_midi_alsa.c 172,173d171 < unsigned char *dataptr = malloc(1); < memcpy(dataptr,&byte,1); 175c173 < snd_seq_ev_set_sysex(&ev,1,dataptr); //...set_variable *should* have worked but didn't ---
snd_seq_ev_set_sysex(&ev,1,&data); //...set_variable *should* have worked but didn't
I just applied both patches, and tested with external MIDI hardware, sending sysex in real time and it works fine. Thanks!
One observation is that valgrind throws up this:
==8036== Conditional jump or move depends on uninitialised value(s) ==8036== at 0x1B9A7C10: snd_seq_event_input_pending (in /lib/libasound.so.2.0.0) ==8036== by 0x80F6AB2: sys_alsa_poll_midi (s_midi_alsa.c:195)
Which seems a bit strange since surely there shouldn't be any pending ALSA events when PD starts up.
Jamie
On Tue, 2005-11-15 at 10:01 +0100, IOhannes m zmoelnig wrote:
(moving this thread to pd-dev where i think it belongs)
federico wrote:
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?
look at the patch i have submitted yesterday to the patch-tracker. it does exactly this: enable that calling of sys_alsa_putmidibyte() from within [midiout] (depending on which midi-api is used)
however, i am not totally convinced of wrapping [midiout] into "real" sysex-blocks. for this i would suggest a separate [sysexout]-object.
the old code does work fine (_if_ sys_alsa_putmidibyte() gets called!) the memory leak, günter was referring too, could be fixed by just _not_ allocating dataptr without freeing it.
the attached stupid little patch seems to work here (again i just tested it with aconnecting the pd's midiout with pd's midiin)
mfg.asd.r IOhannes plain text document attachment (midiout_alsa.patch) Index: s_midi_alsa.c =================================================================== RCS file: /cvsroot/pure-data/pd/src/s_midi_alsa.c,v retrieving revision 1.4 diff -r1.4 s_midi_alsa.c 172,173d171 < unsigned char *dataptr = malloc(1); < memcpy(dataptr,&byte,1); 175c173
< snd_seq_ev_set_sysex(&ev,1,dataptr); //...set_variable *should* have worked but didn't
snd_seq_ev_set_sysex(&ev,1,&data); //...set_variable *should* have worked but didn't
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Jamie Bullock wrote:
I just applied both patches, and tested with external MIDI hardware, sending sysex in real time and it works fine. Thanks!
great.
One observation is that valgrind throws up this:
==8036== Conditional jump or move depends on uninitialised value(s) ==8036== at 0x1B9A7C10: snd_seq_event_input_pending (in /lib/libasound.so.2.0.0) ==8036== by 0x80F6AB2: sys_alsa_poll_midi (s_midi_alsa.c:195)
Which seems a bit strange since surely there shouldn't be any pending ALSA events when PD starts up.
you could try and initialize midi_handle (and while you are there: mididev) to 0 at the beginning of s_midi.alsa.c this should fix this problem (though i haven't tested)
mfg.ads.r IOhannes
On Tue, 2005-11-15 at 11:45 +0100, IOhannes m zmoelnig wrote: <snip>
One observation is that valgrind throws up this:
==8036== Conditional jump or move depends on uninitialised value(s) ==8036== at 0x1B9A7C10: snd_seq_event_input_pending (in /lib/libasound.so.2.0.0) ==8036== by 0x80F6AB2: sys_alsa_poll_midi (s_midi_alsa.c:195)
<snip>
you could try and initialize midi_handle (and while you are there: mididev) to 0 at the beginning of s_midi.alsa.c this should fix this problem (though i haven't tested)
mfg.ads.r IOhannes
Just tried, and that doesn't fix it. I'm a bit clueless about this one i'm afraid.