hello,

I have a problem. I am attempting to place PD in between my wx5 wind controller and everything else(windows xp sp2 running PD 0.42.5 extended), which includes fl studio as synth host. my goal is to re interpret the wind controller data before it gets to the other programs, and modify that data. for instance, gestural transposition using touch osc, and using certain note combinations to trigger events.

the problem is, from what i can ascertain, that the breath control data(cc#2) and the lip conrol data(cc#18) are very densely packed and it "seems" to be confusing PD. I have been trying to split them but it doesnt seem to be working. the value of the cc#18 data sometimes intersects with the cc#2 data and controls it, and vice versa.

even when i connect [midiin]->[midiout] directly, pd isnt sending all the midi data and it is not going thru to the synth host. it shows midi activity, but doesnt send any data to the synths or that data is jumbled and the notes come out in spurts. does anyone have any idea why this is happening and what i could do to possibly fix it?

onyx

Can you post an example patch? Then we can see if it's a patching issue or something else.

sorry it took so long to get back. (tour). thank you for taking the time.

i just have [ctlin] going to [ctlout]. but after a few minutes ofplaying, i see lip(cc#18) controlling cc#2 data and cc#2 sending nothing not returning to 0 and notes hanging. my wind controller seems to be working properly. itworks with everything else.

I really appreciate it.

-----begin-------

#N canvas 0 0 450 300 10;
#X floatatom 70 224 5 0 0 0 - - -;
#X floatatom 135 224 5 0 0 0 - - -;
#X text 69 240 pitch;
#X text 134 241 velocity;
#X text 152 194 note on messages;
#X floatatom 503 179 5 0 0 0 - - -;
#X floatatom 678 178 5 0 0 0 - - -;
#X text 539 178 program change;
#X text 723 179 pitch bend;
#X obj 75 296 -;
#X floatatom 101 272 5 0 0 0 - - -;
#X floatatom 75 324 5 0 0 0 - - -;
#X obj 188 270 s vel;
#X obj 75 354 noteout;
#X obj 503 280 pgmout;
#X obj 678 282 bendout;
#X obj 75 134 notein;
#X obj 505 142 pgmin;
#X obj 678 147 bendin;
#X floatatom 866 -38 5 0 0 0 - - -;
#X floatatom 923 -40 5 0 0 0 - - -;
#X text 864 -23 value;
#X text 922 -21 ctrl nr;
#X text 908 -180 controller messages;
#X obj 868 -122 f;
#X obj 870 -154 t b f;
#X obj 868 -92 pack f f;
#X obj 866 -66 unpack f f;
#X obj 359 -220 ctlin 2 1;
#X obj 344 -139 ctlout 2 1;
#X floatatom 353 -185 5 0 0 0 - - -;
#X floatatom 245 -187 5 0 0 0 - - -;
#X obj 251 -222 ctlin 18 1;
#X obj 236 -141 ctlout 18 1;
#X floatatom 454 -180 5 0 0 0 - - -;
#X floatatom 549 -182 5 0 0 0 - - -;
#X floatatom 636 -179 5 0 0 0 - - -;
#X floatatom 722 -178 5 0 0 0 - - -;
#X obj 460 -215 ctlin 16 1;
#X obj 445 -134 ctlout 16 1;
#X obj 555 -217 ctlin 17 1;
#X obj 540 -136 ctlout 17 1;
#X obj 642 -214 ctlin 80 1;
#X obj 627 -133 ctlout 80 1;
#X obj 728 -213 ctlin 81 1;
#X obj 713 -132 ctlout 81 1;
#X connect 0 0 9 0;
#X connect 1 0 12 0;
#X connect 1 0 13 1;
#X connect 5 0 14 0;
#X connect 6 0 15 0;
#X connect 9 0 11 0;
#X connect 10 0 9 1;
#X connect 11 0 13 0;
#X connect 16 0 0 0;
#X connect 16 1 1 0;
#X connect 17 0 5 0;
#X connect 18 0 6 0;
#X connect 24 0 26 0;
#X connect 25 0 24 0;
#X connect 25 1 26 1;
#X connect 26 0 27 0;
#X connect 27 0 19 0;
#X connect 27 1 20 0;
#X connect 28 0 30 0;
#X connect 30 0 29 0;
#X connect 31 0 33 0;
#X connect 32 0 31 0;
#X connect 34 0 39 0;
#X connect 35 0 41 0;
#X connect 36 0 43 0;
#X connect 37 0 45 0;
#X connect 38 0 34 0;
#X connect 40 0 35 0;
#X connect 42 0 36 0;
#X connect 44 0 37 0;

------end--------

Well, it doesn't look like anything could be wrong with the patch. Just curious, though, have you tried connecting [ctlin] to [ctlout] without the number boxes? The gui in Pd can slow things down, and I wonder if sending the data through a gui object is what's causing the problem.

Thank you for getting back to me.

I just deleted all number boxes and it happened again. It seems that after about 3-4 minutes of fast playing which consists almost entirely of cc2(breath) and cc18(lip/pitch data), something "flips" and all of a sudden cc2 won't return to zero and other cc's (16, 17, which are on a thumb lever on the rear of the horn) are now sending jumbled cc2 msg's.

Also, would it be ok to use send and recieve objects to see the data at the points rather than inline number objects? Or will it not really matter.

Thank you

onyx

I should probably also mention that I am attempting to send the wx5!data thru pure data into fl studio using two midi yoke ports like this:

|touchosc| |wx5|
|. |

|midiyoke1| |hardwaremidiport|(in)
| |

| PureData |

|midiyoke1| |midiyoke2| (out)

| Fl studio |

I just added midiyoke 2 in hopes of having a dedicated port for the wx. Could that be part of the problem? Maybe a feedback loop I'm not aware of ? Are there better midi routers than midiyoke?

Onyx

Ok, I just tested something else.

Everything except pure data is off and I am playing into the test audio and midi window. Although it's a bit slow for some reason, none of the data is getting jumbled although when I set the midi ports to hardware in and hardware out, the noteout was stuck at 60-pitch and 64-velocity. I then turned off the midi out port and that problem went away so it "seems" that there is a midi feedback with pd even when it is just the hardware in and out ports connected and nothing else.

It seems that you can have in OR out but not both. Is there any known way to solve this?

I think it's a midi overflow problem in pure data. I set up everything to be as simple as possible now. Wind controller -> pure data -> host with no multiple port configs. What seems to happen is some midi buffer gets too full after a few minutes of playing. Because the jumbled notes that are coming out seem to be a mixed up sequence of what I had just played according to what I am hearing and what I see in the number boxes (which are there for debugging only. Data is going "to" not "thru" them). After a few moments everything seems to return to somewhat normal.

Any ideas on what this is and or how to minimize it?

Fixed but not solved.

For some reason, opening midi-ox in the background fixed the problem with no added latency. I don't know why that solution works and right now I don't care. As long as it keeps working. Just thought I'd share. Onyx

Scratch that. Didn't work

the only thing i can think to call this phenomena is data cross pollination. some where in there the cc data from one cc# starts controlling a different cc#. in this case, 2 and 18. 16 and 17 as well, when i attempt to use those. any insight? anything

well,for finality, i figured out the problem. i was using the integrated midi on my M-audio firewire audiophile and that was the culprit. i attached my windcontroller to my m-audio UNO interface, problem solved. i figured i'd post the results just in case anyone looks for this error in the future.