[PD-dev] Re: [PD] midiout broken

[Jamie Bullock]

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 at iem.at
> http://lists.puredata.info/listinfo/pd-dev