So it's a USB(ugh!) driver problem then...why am I not surprised...
Nicholas Ward wrote:
Okay getting somewhere, It works fine if I plug the bcf2000 into my midi interface with midi cables (why didnt i try that earlier!). It doesnt work for NRPN if i use the USB connection to connect the BCF2000 directly to the computer. hmmmm? buffers?
On 7 Jul 2005, at 19:41, Martin Peach wrote:
What if you send it the four messages manually in sequence instead of all at once? e.g. make a patch that uses ctlout and plug your MIDI out to your MIDI in. All I can think of is the usual culprits: buffer overflow or running status, neither of which should be a problem with recent pd versions. Martin
Nicholas Ward wrote:
yep, Thats what i did. it prints nothing for an nrpn and fine for ctrlin and yet i can see the nrpn data fine in midi monitor! baffling
On 7 Jul 2005, at 18:56, Martin Peach wrote:
The source code for the ctlin object is in s_midi.c and x_midi.c, all it does is list whatever cc message comes its way. There is no difference between cc98 and cc3 as far as [ctlin] is concerned. No other filtering is done inside pd. If you open the nrpnin abstraction that David attached you'll see that it contains a [ctlin] and is otherwise made of standard pd objects that all work on OSX. I would make a simple patch like this (the first part of the $0-nrpnin-guts subpatch): [ctlin] | | | [pack f f f] | [print] ...and have a look at what it prints.
Martin
Nicholas Ward wrote:
No the abstraction is fine. Its ctlin thats the problem.. NRPNs are (as far as i understand) just four controller messages in a row. cc99 , cc98, specifying the parameter to affect and cc6 and cc38 specifying the value. looking at plumstone output (a java extension for OS X with a tester app that shows incoming midi) I see this is the case. e.g.
time ch cc data 9567000 [11:4 99 0] 9567000 [11:4 98 4] 9567000 [11:4 6 10] 9567000 [11:4 38 27]
so thats why i dont see why ctlin has a problem with them. If i send a cc99 message to ctlin it has no problem.
Is nrpn just not supported by ctlin on os x?
Nick
On 7 Jul 2005, at 17:01, Martin Peach wrote:
Checking http://www.borg.com/~jglatt/tech/midispec/nrpn.htm it seems that nrpns _are_ standard cc messages: they're 98 and 99. If your [ctlin] outputs those then the problem is with the nrpn abstraction.
Nicholas Ward wrote:
> Hi David, > The problem is with ctlin. I attached a print to a ctlin. Loads > of numbers for standard cc messages. Not a sausage for nrpn! > Any other ideas out there? > Thanks > Nick > > > On 7 Jul 2005, at 06:32, David NG McCallum wrote: > >> Nick, >> >> I've actually updated the abstractions but haven't bothered to >> upload >> them (I think). I've attached them here, hope no one minds. The >> logic >> hasn't changed at all, it's just a little more elegant (maybe). >> >> Not sure about your problem, though... Are you having problems >> with >> [nrpnin], or just getting *any* data from [ctlin] when using >> the nrpn >> controllers? >> >> Let me know if you have problems with the newer [nrpnin]. I've >> never >> actually tested them on nrpn hardware. I still have no idea why >> I spent >> the time working on them. :) But I've been told they work. >> >> cheers, >> David >> __ _ _ _ _ __ ___ _ ___ __ _ _ _ ____ __ >> Music wants to be free http://sintheta.org >> >> Nicholas Ward wrote: >> >>> Hello, >>> Im trying to get 14bit midi messages into pd. This was >>> discussed a few >>> months ago and I've got an abstraction nrpnin to parse the >>> output from >>> a ctlin from David McCallum's site >>> http://www.mentalfloss.ca/sintheta/html/downloads.html >>> >>> Im using a behringer bcf2000 controller. >>> >>> The problem is Ctlin doesnt output anything if i send an nrpn >>> message. >>> It happily works for standard CC. Is this normal? Im on os x >>> 10.3.9 and >>> pd.app 0.38-4RC0. >>> >>> Any ideas ? >>> >>> Thanks >>> >>> Nicky >>> >>> >>> Ive installed midi monitor and can see that the bcf is >>> outputting the >>> midi message fine, below is the output for one complete message. >>> >>> 01:37:22.548 From BCF2000 Control 5 Non-Registered >>> Parameter >>> MSB 0 >>> 01:37:22.548 From BCF2000 Control 5 Non-Registered >>> Parameter >>> LSB 10 >>> 01:37:22.548 From BCF2000 Control 5 Data Entry >>> (coarse) 3 >>> 01:37:22.548 From BCF2000 Control 5 Data Entry >>> (fine) 105 >> >> >> >> >> #N canvas 11 85 454 460 10; >> #X text 116 168 Data comes in as:; >> #X text 115 187 Parameter MSB: Ctl 99; >> #X text 115 199 Parameter LSB: Ctl 98; >> #X text 114 212 Value MSB: Ctl 6; >> #X text 114 224 Value LSB: Ctl 38; >> #X text 156 337 value; >> #X text 214 316 parameter; >> #X obj 110 335 outlet; >> #X obj 167 313 outlet; >> #X obj 224 290 outlet; >> #X text 273 289 channel; >> #N canvas 458 0 656 592 1001-nrpnin_guts 0; >> #X obj 120 26 ctlin; >> #X text 166 530 value; >> #X text 220 499 parameter; >> #X obj 120 49 pack f f f; >> #X msg 120 72 $3 $2 $1; >> #X obj 120 97 route $2; >> #X obj 171 120 spigot; >> #X obj 208 28 loadbang; >> #X obj 208 49 f $2; >> #X obj 208 70 sel 0; >> #X msg 208 92 1; >> #X text 257 60 if no midi channel specified , omni; >> #X obj 171 363 spigot; >> #X obj 208 275 loadbang; >> #X obj 208 317 sel 0; >> #X msg 208 339 1; >> #X obj 120 249 route $1; >> #X msg 171 147 $2 $3; >> #X obj 208 296 f $1; >> #X obj 120 528 outlet; >> #X obj 171 496 outlet; >> #X msg 220 147 $1; >> #X obj 171 386 unpack f f; >> #X obj 221 463 outlet; >> #X text 270 462 channel; >> #X text 265 305 since Pd defaults lack of argument to 0 I can't >> think >> of a way to get this to separate parameter 0 properly. So 0 >> becomes >> omni. Sorry!; >> #N canvas 518 368 751 539 1001-filter_proper_input 0; >> #X obj 37 19 inlet; >> #X obj 37 419 outlet; >> #X obj 37 294 glue; >> #X obj 85 292 nop; >> #X obj 37 42 route 99; >> #X obj 37 72 t f b; >> #X obj 37 330 route 38; >> #X msg 67 207 list; >> #X obj 37 376 route 6; >> #X obj 37 397 route 98; >> #X msg 37 353 $2 $4 $6 $5 $3 $1; >> #X text 251 10 Okay , cleaner than before.; >> #X text 239 358 Reorder them with controllers followed by values; >> #X text 239 386 If the controllers route properly , it's an NRPN! >> ; >> #X obj 213 241 sel; >> #X obj 127 192 route list float; >> #X obj 127 216 route 98 6 38; >> #X obj 229 262 bang; >> #X text 243 43 When CC 99 comes in , append the next four CC >> controllers. >> [glue]; >> #X text 274 206 Um , this part made more sense before , >> basically >> make sure the [glue] doesn't fill up with crap if the CCs >> aren't NRPN. >> ; >> #X connect 0 0 4 0; >> #X connect 2 0 3 0; >> #X connect 2 0 6 0; >> #X connect 2 0 15 0; >> #X connect 3 0 2 1; >> #X connect 4 0 5 0; >> #X connect 4 1 2 0; >> #X connect 5 0 2 0; >> #X connect 5 1 7 0; >> #X connect 6 0 10 0; >> #X connect 7 0 2 1; >> #X connect 8 0 9 0; >> #X connect 9 0 1 0; >> #X connect 10 0 8 0; >> #X connect 14 1 17 0; >> #X connect 15 0 16 0; >> #X connect 15 1 14 1; >> #X connect 16 3 14 0; >> #X connect 17 0 7 0; >> #X restore 120 186 pd $0-filter_proper_input; >> #N canvas 0 0 568 312 1001-MSB_and_LSB 0; >> #X obj 79 78 unpack f f f f; >> #X obj 131 149 +; >> #X obj 79 148 +; >> #X obj 79 114 * 128; >> #X obj 131 113 * 128; >> #X obj 79 180 pack f f; >> #X obj 79 47 inlet; >> #X obj 79 250 outlet; >> #X text 218 82 All that's left is the MSB and LSB values for >> the parameter >> , and the parameter value. These are used to calculate the >> parameter >> and parameter value; >> #X connect 0 0 3 0; >> #X connect 0 1 2 1; >> #X connect 0 2 4 0; >> #X connect 0 3 1 1; >> #X connect 1 0 5 1; >> #X connect 2 0 5 0; >> #X connect 3 0 2 0; >> #X connect 4 0 1 0; >> #X connect 5 0 7 0; >> #X connect 6 0 0 0; >> #X restore 120 214 pd $0-MSB_and_LSB; >> #X text 192 247 pick the right NRPN controller; >> #X connect 0 0 3 0; >> #X connect 0 1 3 1; >> #X connect 0 2 3 2; >> #X connect 3 0 4 0; >> #X connect 4 0 5 0; >> #X connect 5 0 26 0; >> #X connect 5 1 6 0; >> #X connect 6 0 17 0; >> #X connect 6 0 21 0; >> #X connect 7 0 8 0; >> #X connect 8 0 9 0; >> #X connect 9 0 10 0; >> #X connect 10 0 6 1; >> #X connect 12 0 22 0; >> #X connect 13 0 18 0; >> #X connect 14 0 15 0; >> #X connect 15 0 12 1; >> #X connect 16 0 19 0; >> #X connect 16 1 12 0; >> #X connect 17 0 26 0; >> #X connect 18 0 14 0; >> #X connect 21 0 23 0; >> #X connect 22 0 20 0; >> #X connect 22 1 19 0; >> #X connect 26 0 27 0; >> #X connect 27 0 16 0; >> #X restore 110 264 pd $0-nrpnin_guts; >> #X text 18 95 Notes: Parameter 0 will make the object omni. >> This has >> to do with Pd defaulting absent arguments to 0 Sorry!; >> #X text 17 71 Arguments: NRPN parameter , MIDI channel - just >> like >> [ctlin]; >> #X obj 147 19 cnv 15 15 15 empty empty nrpnin 0 8 1 14 -262144 >> -99865 >> 0; >> #X text 28 394 David McCallum , 2004 - sintheta.org; >> #X connect 11 0 7 0; >> #X connect 11 1 8 0; >> #X connect 11 2 9 0; >> #N canvas 322 460 507 349 10; >> #X obj 178 12 cnv 15 15 15 empty empty nrpnout 0 8 1 14 -262144 >> -66577 >> 0; >> #N canvas 0 0 745 436 1004-nrpnout_guts 0; >> #X obj 130 20 inlet; >> #X obj 80 150 mod 128; >> #X obj 155 150 div 128; >> #X obj 130 115 t f f; >> #X obj 216 20 inlet; >> #X obj 216 150 mod 128; >> #X obj 278 150 div 128; >> #X obj 216 115 t f f; >> #X obj 142 258 f; >> #X obj 203 258 f; >> #X obj 265 258 f; >> #X obj 80 178 t f b b b; >> #X obj 265 378 ctlout 99; >> #X obj 203 378 ctlout 98; >> #X obj 142 378 ctlout 6; >> #X obj 80 378 ctlout 38; >> #X obj 228 48 loadbang; >> #X obj 228 72 f $1; >> #X obj 303 294 loadbang; >> #X obj 289 344 sel 0; >> #X obj 289 320 f $2; >> #X obj 289 274 inlet; >> #X text 354 316 because absent arguments in Pd default to 0 I >> can't >> parse parameter 0 properly. So zero becomes omni. Yikes!; >> #X connect 0 0 3 0; >> #X connect 1 0 11 0; >> #X connect 2 0 8 1; >> #X connect 3 0 1 0; >> #X connect 3 1 2 0; >> #X connect 4 0 7 0; >> #X connect 5 0 9 1; >> #X connect 6 0 10 1; >> #X connect 7 0 5 0; >> #X connect 7 1 6 0; >> #X connect 8 0 14 0; >> #X connect 9 0 13 0; >> #X connect 10 0 12 0; >> #X connect 11 0 15 0; >> #X connect 11 1 8 0; >> #X connect 11 2 9 0; >> #X connect 11 3 10 0; >> #X connect 16 0 17 0; >> #X connect 17 0 7 0; >> #X connect 18 0 20 0; >> #X connect 19 1 12 2; >> #X connect 19 1 13 2; >> #X connect 19 1 14 2; >> #X connect 19 1 15 2; >> #X connect 20 0 19 0; >> #X connect 21 0 20 0; >> #X restore 141 246 pd $0-nrpnout_guts; >> #X obj 141 170 inlet; >> #X obj 201 197 inlet; >> #X obj 262 224 inlet; >> #X text 190 165 value; >> #X text 299 224 channel; >> #X text 242 194 parameter; >> #X text 51 68 Arguments: NRPN parameter , MIDI channel - just >> like >> [ctlout]; >> #X text 49 97 Notes: funny stuff with parameter 0 Has to do >> with Pd >> defaulting absent arguments to 0 Just avoid 0; >> #X text 87 306 David McCallum , 2004 - sintheta.org; >> #X connect 2 0 1 0; >> #X connect 3 0 1 1; >> #X connect 4 0 1 2; > > > > > > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list