It looks like you may experiencing another thing that i've complained about... pd's alsa midi connects to all MIDI inputs and outputs that it can.. this includes alsa's MIDI through.. so everything that you send out gets echoed back into the input.. SUPER annoying.
run aconnect [or easier, though not great, aconnectgui] and see if that is the case for you.. disconnect pd from the alsa through port.
-Alex
2009/7/7 András Murányi muranyia@gmail.com:
2009/7/8 Alex x37v.alex@gmail.com
- sysex gets fragmented (also when nothing is sent out meanwhile by
other objects). It is always properly terminated with '247' but the content is often truncated. Is this a bug/feature...? What is your best recommendation knowing that my patch is full of sysex outs (+envelopes on some of them!)
- sysex just magically does not work on the target machine ;o) I have no
clue why except for this thing with being truncated but it *never* works even if the message seems to go out intact. Even more interesting that the machine shows me that it is recieving sysex! Tried with the mpu-401 of an Audigy and with a MOTU 828 mkII through Jack and a2jmidid (jack-alsa midi bridge).
I haven't actually tested sysex out limits, but sysex in is limited to something like 24 byte messages..
here is a thread where i talk about it: http://lists.puredata.info/pipermail/pd-list/2009-01/067372.html
It is hard coded into the source. You can modify the source to change the hard coded limit.. i have a diff on that thread which shows how i did it.
Thanks Alex, it's an important thing to know. My sysex is shorter than 24B it's just broken. What we shall see repeating is 240 67 16 73 8 16 19 (knobvalue) 247
Instead I'm having this grinded mess coming back on physical loopback:
print: 240 print: 67 print: 16 print: 247 print: 240 print: 67 print: 247 print: 240 print: 67 print: 16 print: 247 print: 240 print: 67 print: 16 print: 73 print: 247 print: 240 print: 67 print: 16 print: 73 print: 8 print: 247 print: 240 print: 67 print: 16 print: 73 print: 247 print: 240 print: 67 print: 16 print: 247 print: 240 print: 67 print: 16 print: 247 print: 240 print: 67 print: 16 print: 73 print: 8 print: 247 print: 240 print: 67 print: 16 print: 247 print: 240 print: 67 print: 16 print: 73 print: 247 print: 240 print: 67 print: 16 print: 73 print: 247 print: 240 print: 67 print: 16 print: 73 print: 247
This makes me think I'm trying to send too much data in too short intervals...? Is there a handy way to limit the density of my output? (i think its not not [drip] as it has to stay realtime) I'm not very experienced, sorry if this traces back to something very obvious!
-- Muranyi Andras
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list