Re: [PD] [midiin] doesn't recognize SYSTEM COMMON or SYSTEM REALTIME messages
Thanx a lot, Andreas! [midirealtimein] is working perfectly! I really can't understand why these things are not findable in the help files. Not even a search through the entire program folder of Pd (windows) searching for midi* came up with this object. Where is it? Is this somewhere hidden inside some other object? Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von András Murányi Gesendet: Sonntag, 21. November 2010 18:42 An: PD List Betreff: Re: [PD] [midiin] doesn't recognize SYSTEM COMMON or SYSTEM REALTIME messages Does anybody know how to receive SYSTEM COMMON or SYSTEM REAL TIME messages? The [midiin] object only outputs 0xF0 (sysex start), 0xF7 (sysex end) and 0xF6 (tune request). Anything else between 0xF0 and 0xFF is being ignored. [sysexin] doesn't do it either. I really need 0xFA and 0xFC ( = start / stop ) as well as 0xFE ( = active sensing ) to communicate with the standard transport buttons, etc. on normal keyboards. How would you sync to midi clock if 0xF8 ( = midi timing clock) is being ignored? Does anybody know how to get this to work? Is there any other object that can receive raw midi? Ingo Hello Ingo, take a look at [midirealtimein], i can recieve 0xFA, 0xFC and 0xF8 with it, hopefully the others as well. Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] if within a range of numbers then true
You could use [expr] [expr $f1=11 $f1=20] Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ben Carney Gesendet: Dienstag, 23. November 2010 02:37 An: pd-list@iem.at Betreff: [PD] if within a range of numbers then true Hello all, I have become rusty in pure data. It seems as if I used to know the answer to this. I would like to beable to output a 1 if a number is within a certain range example: [number box\ | | [If between 11 and 20] | | | [X] I thought this would be easier to come up with a solution than it has been thanks in advance. -- benfcarney www.benfcarney.com Chicago, IL ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Simple Subtractive Synth filter envelope
Here's what I would do based on your example. Of course there are many options of using envelope objects. I would also suggest to use something else than [phasor~] because of aliasing problems. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Andrew Faraday Gesendet: Montag, 22. November 2010 23:36 An: pimas...@gmail.com; samueldavidr...@hotmail.co.uk Cc: pd-list@iem.at Betreff: Re: [PD] Simple Subtractive Synth filter envelope hello samuel [vcf~] is probably the way to go. you can also cheat a little using [envgen] which is a graphic envelope generator, currently set between 0 and 1. The documentation isn't perfect, but these are the messages you need to know. [0 50 1 50 ( --- slightly different syntax from [line] or [line~], it goes, target (first one's instant), gap, target, gap etc. [duration 5000( --- changes the duration of your envelope without changing the shape. a bang outputs the messages for [line] or [line~] or [vline~]. you can also draw your envelope manually. This is useful if you don't want to spend much time on sorting out your envelope generator. Oh, and the 0 to 1 problem. In audio you'll have to do some arithmetic, but if you use a signal line you can use [range 0 1 X X] replacing the x's with the upper and lower limit you want for your filters. Hope this helps Andrew P.S. to convert the audio 0 - 1 to a range you want, use [line~] | [*~ (the size of your range)] | [+~ (the lower limit of your range)] Date: Mon, 22 Nov 2010 23:10:47 +0100 From: pimas...@gmail.com To: samueldavidr...@hotmail.co.uk CC: pd-list@iem.at Subject: Re: [PD] Simple Subtractive Synth filter envelope Would this do? You should be aware that there is a difference between message and audio inlets (different color). The sound may be very diffrent depending on the type of inlet an audio object has if you want to change a parameter dynamically. This is particularly relevant for filters. Check the difference between [bp~] and [vcf~]. Pierre 2010/11/22 samuel rowe samueldavidr...@hotmail.co.uk Hi I'm relatively new to PD, but I've been working with hardware synthesizers for years now, and I've used SynC to build synths on my computer, and I'm doing an Audio Technology degree, so I'm not clueless on the subject. However, I'm trying to build a simple subtractive synth where I press a PutBang which triggers an envelope generator with ADSR to alter the filter cutoff, and I just can't work out how to do it. No-one at my university program in pd or max, so I have had to search the internet for help. I've read these two pages http://obiwannabe.co.uk/html/music/6SS/six-simple-synthesisers.html http://en.flossmanuals.net/PureData/SimpleSynth and whilst the vline object on the flossmanuals site is fine when altering the envelope of an overtone in an additive synth, the output will not feed into the argument for a filter cutoff value. I can't even get the attack decay generator on the first site to work, let alone figure out how to alter it's seemingly inefficient design to allow sustain and release. I know this is quite trivial compared to some of the things that get posted in the mailing list, I would really appreciate it if anyone could help me, or point me in the right direction. I've spent too many nights scouring the internet and trying to work it out for myself, but I've simply hit a brick wall. Thank you in advance Samuel p.s. this is the text for the file i have been working on, it's a little bit messy and doesn't seem to work properly. BE CAREFUL, IT MAKES A THUMP WHEN OPENED, TURN OFF COMPUTE AUDIO #N canvas 366 35 610 629 10; #X obj 106 485 dac~; #X obj 94 115 phasor~; #X floatatom 104 77 5 0 0 0 - - -; #X obj 231 154 bng 15 250 50 0 empty empty hit_to_trigger_envelope_and_make_sound 17 7 0 10 -262144 -1 -1; #X obj 152 116 phasor~; #X obj 109 175 +~; #X obj 151 140 -~ 0.5; #X obj 96 140 -~ 0.5; #X obj 167 96 *~; #X floatatom 182 30 5 -25 25 1 osc2_detune - -; #X obj 182 75 +~ 1; #X obj 181 52 /~ 1; #X obj 207 258 del; #X obj 200 321 0 \$1; #X obj 273 324 1 \$1; #X obj 235 357 line; #X floatatom 331 175 5 0 0 1 attack_value? - -; #X floatatom 337 228 5 0 0 1 decay_value? - -; #X obj 110 376 lop~ 3000; #X obj 110 403 lop~ 3000; #X obj 110 427 lop~ 3000; #X obj 110 451 lop~ 3000; #X obj 214 203 t b b; #X obj 254 196 t f f; #X obj 206 288 f 50; #X obj 249 287 f 50; #X obj 217 391 + 20; #X connect 1 0 7 0; #X connect 2 0 1 0; #X connect 2 0 8 0; #X connect 3 0 22 0; #X connect 4 0 6 0; #X connect 5 0 18 0; #X connect 6 0 5 1; #X connect 7 0 5 0; #X connect 8 0 4 0; #X connect 9 0 11 0; #X connect 10 0 8 1; #X connect 11 0 10 0; #X connect 12 0 24 0; #X connect 13 0 15 0; #X connect 14 0 15 0; #X connect 15 0 26 0; #X connect 16 0 23 0; #X connect 17 0 24 1; #X connect 18 0 19 0; #X connect 19 0 20 0; #X connect 20 0 21 0; #X connect 21 0 0 0; #X connect 21 0 0 1; #X connect
[PD] Strange behavior between [phasor~] and [creb/blosc~]
Hi everybody, I just noticed a very strange behaviour concerning [phasor~]. It started when I wanted to replace [phasor~] with [creb/blosc~]. Normally they should sound pretty much the same except for the obvious aliasing problem of [phaser~]. Then I noticed that in some cases they didn't sound the same and in others they did. I finally found out that it had to do with the level going over 1 - only while being doubled. While [creb/blosc~] sounds the same no matter if I boost the levels higher than 1 [phasor~] starts to cancle it's sound. With a single [phasor~] it's no problem but two of them will give you trouble. Since Pd is working with 32 bit float this shouldn't really happen - and doesn't with [creb/blosc~]. Can anybody explain this? I have my test patch attached. Ingo #N canvas 352 362 767 567 10; #X obj 149 177 mtof; #X obj 149 157 +; #X obj 164 110 / 100; #X obj 164 93 nbx 5 14 -50 50 0 1 detune1 empty empty 0 -8 0 10 -204786 -1 -1 -10 256; #X obj 149 66 nbx 5 14 21 108 0 1 note empty empty 0 -8 0 10 -261234 -1 -1 36 256; #X text 206 63 note; #X obj 269 177 mtof; #X obj 269 157 +; #X obj 284 110 / 100; #X obj 284 93 nbx 5 14 -50 50 0 1 detune2 empty empty 0 -8 0 10 -204800 -1 -1 10 256; #X text 222 91 detune1; #X text 342 91 detune2; #X obj 394 491 dac~; #X obj 461 445 hsl 128 15 1 100 1 0 empty empty empty -2 -8 0 10 -262144 -1 -1 12700 1; #X obj 421 444 / 100; #X obj 589 353 == 0; #X obj 254 370 *~; #X obj 364 285 tgl 15 0 empty empty empty 17 7 0 10 -4032 -1 -1 1 1 ; #X msg 359 28 \; pd dsp 1; #X obj 284 11 loadbang; #X obj 164 130 t b f; #X obj 284 130 t b f; #X obj 439 177 mtof; #X obj 439 157 +; #X obj 454 110 / 100; #X obj 454 93 nbx 5 14 -50 50 0 1 empty detune1 empty 0 -8 0 10 -228856 -1 -1 -10 256; #X obj 439 66 nbx 5 14 21 108 0 1 empty note empty 0 -8 0 10 -228856 -1 -1 36 256; #X text 496 63 note; #X obj 559 177 mtof; #X obj 559 157 +; #X obj 574 110 / 100; #X obj 574 93 nbx 5 14 -50 50 0 1 empty detune2 empty 0 -8 0 10 -228856 -1 -1 10 256; #X text 512 91 detune1; #X text 632 91 detune2; #X obj 544 370 *~; #X obj 454 130 t b f; #X obj 574 130 t b f; #X obj 149 197 phasor~; #X obj 439 197 creb/blosc~ saw; #X obj 559 197 creb/blosc~ saw; #X obj 254 264 +~; #X obj 269 197 phasor~; #X obj 544 264 +~; #X obj 79 51 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 79 180 0; #X text 76 162 all off; #X text 97 49 on; #X obj 394 444 *~; #X obj 538 398 loadbang; #X msg 538 418 25; #X text 593 443 volume; #X floatatom 421 463 5 0 0 0 - - -; #X text 371 253 on = phasor~; #X msg 79 210 0.5; #X msg 109 210 1; #X obj 149 227 *~ 0.5; #X obj 269 227 *~ 0.5; #X obj 439 227 *~ 0.5; #X obj 559 227 *~ 0.5; #X obj 254 320 *~ 1; #X text 26 205 multiply; #X text 26 215 volume; #X text 26 298 multiply; #X text 26 308 volume; #X obj 544 320 *~ 1; #X msg 79 303 1; #X msg 109 303 2; #X obj 26 265 bng 15 250 50 0 empty empty normal_(=*1) 17 7 0 10 -4034 -1 -1; #X obj 119 265 bng 15 250 50 0 empty empty messed_up_(=*4) 17 7 0 10 -260097 -1 -1; #X obj 596 430 bng 15 250 50 0 empty empty set_vol_to_max! 17 7 0 10 -258113 -1 -1; #X text 371 268 off = creb/blosc~; #X text 39 447 creb/blosc~ can handle a total audio level of 4; #X text 39 492 Phasor~ cannot go over audio level of 1; #X text 132 275 (because of 2 osc); #X obj 12 9 bng 15 250 50 0 empty empty set_vol_to_max_first! 17 7 0 10 -258113 -1 -1; #X text 9 22 then switch between phasor~ and blosc~; #X text 39 462 creb/blosc~ sounds the same no matter what level; #X text 39 507 Phasor~ starts to drop level; #X connect 0 0 37 0; #X connect 1 0 0 0; #X connect 2 0 20 0; #X connect 3 0 2 0; #X connect 4 0 1 0; #X connect 4 0 7 0; #X connect 6 0 41 0; #X connect 7 0 6 0; #X connect 8 0 21 0; #X connect 9 0 8 0; #X connect 13 0 14 0; #X connect 14 0 47 1; #X connect 14 0 51 0; #X connect 15 0 34 1; #X connect 16 0 47 0; #X connect 17 0 16 1; #X connect 17 0 15 0; #X connect 19 0 18 0; #X connect 19 0 4 0; #X connect 19 0 3 0; #X connect 19 0 9 0; #X connect 19 0 17 0; #X connect 20 0 1 0; #X connect 20 1 1 1; #X connect 21 0 7 0; #X connect 21 1 7 1; #X connect 22 0 38 0; #X connect 23 0 22 0; #X connect 24 0 35 0; #X connect 25 0 24 0; #X connect 26 0 23 0; #X connect 26 0 29 0; #X connect 28 0 39 0; #X connect 29 0 28 0; #X connect 30 0 36 0; #X connect 31 0 30 0; #X connect 34 0 47 0; #X connect 35 0 23 0; #X connect 35 1 23 1; #X connect 36 0 29 0; #X connect 36 1 29 1; #X connect 37 0 55 0; #X connect 38 0 57 0; #X connect 39 0 58 0; #X connect 40 0 59 0; #X connect 41 0 56 0; #X connect 42 0 64 0; #X connect 43 0 4 0; #X connect 44 0 37 0; #X connect 44 0 41 0; #X connect 44 0 38 0; #X connect 44 0 39 0; #X connect 47 0 12 0; #X connect 47 0 12 1; #X connect 48 0 49 0; #X connect 49 0 13 0; #X connect 53 0 55 1; #X connect 53 0 56 1; #X connect 53 0 57 1; #X connect 53 0 58 1; #X connect 54 0 55 1; #X connect 54 0 56 1; #X connect 54 0 57 1; #X connect 54 0 58 1; #X connect 55 0 40 0; #X connect 56 0 40 1; #X
Re: [PD] Strange behavior between [phasor~] and [creb/blosc~]
The thing I'm really afraid of is: Do subpatches with several [phasor~] used as a audiosignals produce a different result as intended without summing up in total over 1. Especially as in my cases where I'm using lots of [phasor~] mostly for amplitude modulation and most of the time they are not turned down in level. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ingo Gesendet: Dienstag, 23. November 2010 10:42 An: pd-list@iem.at Betreff: [PD] Strange behavior between [phasor~] and [creb/blosc~] Hi everybody, I just noticed a very strange behaviour concerning [phasor~]. It started when I wanted to replace [phasor~] with [creb/blosc~]. Normally they should sound pretty much the same except for the obvious aliasing problem of [phaser~]. Then I noticed that in some cases they didnt sound the same and in others they did. I finally found out that it had to do with the level going over 1 - only while being doubled. While [creb/blosc~] sounds the same no matter if I boost the levels higher than 1 [phasor~] starts to cancle its sound. With a single [phasor~] its no problem but two of them will give you trouble. Since Pd is working with 32 bit float this shouldnt really happen and doesnt with [creb/blosc~]. Can anybody explain this? I have my test patch attached. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Strange behavior between [phasor~] and [creb/blosc~]
Hi Derek, that's it !!! I just subtracted 0.5 from the [phasor~] outlet and now it behaves as expected. Thank you! Now I have to find all the [phasor~] objects in my patches und change it there. Using [blosc~] is just too expensive for simply producing some slight dirt modulations. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Derek Holzer Gesendet: Dienstag, 23. November 2010 14:49 An: pd-list@iem.at Betreff: Re: [PD] Strange behavior between [phasor~] and [creb/blosc~] Did you try graphing the output of the combined [phasor~] objects? To me, it seems likely that the lack of a zero-crossing in the [phasor~] waveform would create a large amount of DC offset, and perhaps that is what you are hearing. [creb/blosc~], [osc~] and pretty much any other audio waveform generator all have mostly equal amounts of positive and negative energy in their waveforms. Only [phasor~] is the weird exception and wasn't even designed to be used as signal source anyways. I'm quite sure it was mainly intended for use in driving [tabread~] objects. D. On 11/23/10 2:40 PM, Ingo wrote: Do subpatches with several [phasor~] used as a audiosignals produce a different result as intended without summing up in total over 1. -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 113: Make a blank valuable by putting it in an exquisite frame ___ 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
Re: [PD] Strange behavior between [phasor~] and [creb/blosc~]
Yes, Derek, that formula makes absolutely sense. The funny thing is that the level with the - 0.5 was identical with [creb/blosc~]. It should have been half the level. Strange! Ingo -Ursprüngliche Nachricht- Von: Derek Holzer [mailto:de...@umatic.nl] Gesendet: Dienstag, 23. November 2010 19:08 An: Ingo Cc: pd-list@iem.at Betreff: Re: AW: [PD] Strange behavior between [phasor~] and [creb/blosc~] Have a look here: http://en.flossmanuals.net/PureData/DCOffset My basic formula is [*~ 2] | [-~ 1] Best! D. On 11/23/10 3:18 PM, Ingo wrote: Hi Derek, that's it !!! I just subtracted 0.5 from the [phasor~] outlet and now it behaves as expected. Thank you! Now I have to find all the [phasor~] objects in my patches und change it there. Using [blosc~] is just too expensive for simply producing some slight dirt modulations. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Derek Holzer Gesendet: Dienstag, 23. November 2010 14:49 An: pd-list@iem.at Betreff: Re: [PD] Strange behavior between [phasor~] and [creb/blosc~] Did you try graphing the output of the combined [phasor~] objects? To me, it seems likely that the lack of a zero-crossing in the [phasor~] waveform would create a large amount of DC offset, and perhaps that is what you are hearing. [creb/blosc~], [osc~] and pretty much any other audio waveform generator all have mostly equal amounts of positive and negative energy in their waveforms. Only [phasor~] is the weird exception and wasn't even designed to be used as signal source anyways. I'm quite sure it was mainly intended for use in driving [tabread~] objects. D. On 11/23/10 2:40 PM, Ingo wrote: Do subpatches with several [phasor~] used as a audiosignals produce a different result as intended without summing up in total over 1. -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 113: Make a blank valuable by putting it in an exquisite frame ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 101: It is simply a matter of work ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Simple Subtractive Synth filter envelope
Hi Samuel, as an alternative to [phasor~] you could try either [creb/blosc~ saw] or the one Roman Haefeli just suggested: If you're after a cheap band-limited saw generator, check this out: https://github.com/reduzent/pd-bloscabs It's pure vanilla and cpu-wise not much more expensive than [tabosc4~]. Ingo Von: samuel rowe [mailto:samueldavidr...@hotmail.co.uk] Gesendet: Mittwoch, 24. November 2010 00:39 An: i...@miamiwave.com Betreff: RE: AW: [PD] Simple Subtractive Synth filter envelope Hi Ingo Thanks for the help, I've been a bit busy today, but I will try your idea tomorrow and let you know how I get along with it I was wondering if there was a different sawtooth to phasor, it does sound terribly artificial Thank you Samuel From: i...@miamiwave.com To: jbtur...@hotmail.com; pimas...@gmail.com; samueldavidr...@hotmail.co.uk CC: pd-list@iem.at Subject: AW: [PD] Simple Subtractive Synth filter envelope Date: Tue, 23 Nov 2010 07:32:48 +0100 Here's what I would do based on your example. Of course there are many options of using envelope objects. I would also suggest to use something else than [phasor~] because of aliasing problems. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Andrew Faraday Gesendet: Montag, 22. November 2010 23:36 An: pimas...@gmail.com; samueldavidr...@hotmail.co.uk Cc: pd-list@iem.at Betreff: Re: [PD] Simple Subtractive Synth filter envelope hello samuel [vcf~] is probably the way to go. you can also cheat a little using [envgen] which is a graphic envelope generator, currently set between 0 and 1. The documentation isn't perfect, but these are the messages you need to know. [0 50 1 50 ( --- slightly different syntax from [line] or [line~], it goes, target (first one's instant), gap, target, gap etc. [duration 5000( --- changes the duration of your envelope without changing the shape. a bang outputs the messages for [line] or [line~] or [vline~]. you can also draw your envelope manually. This is useful if you don't want to spend much time on sorting out your envelope generator. Oh, and the 0 to 1 problem. In audio you'll have to do some arithmetic, but if you use a signal line you can use [range 0 1 X X] replacing the x's with the upper and lower limit you want for your filters. Hope this helps Andrew P.S. to convert the audio 0 - 1 to a range you want, use [line~] | [*~ (the size of your range)] | [+~ (the lower limit of your range)] Date: Mon, 22 Nov 2010 23:10:47 +0100 From: pimas...@gmail.com To: samueldavidr...@hotmail.co.uk CC: pd-list@iem.at Subject: Re: [PD] Simple Subtractive Synth filter envelope Would this do? You should be aware that there is a difference between message and audio inlets (different color). The sound may be very diffrent depending on the type of inlet an audio object has if you want to change a parameter dynamically. This is particularly relevant for filters. Check the difference between [bp~] and [vcf~]. Pierre 2010/11/22 samuel rowe samueldavidr...@hotmail.co.uk Hi I'm relatively new to PD, but I've been working with hardware synthesizers for years now, and I've used SynC to build synths on my computer, and I'm doing an Audio Technology degree, so I'm not clueless on the subject. However, I'm trying to build a simple subtractive synth where I press a PutBang which triggers an envelope generator with ADSR to alter the filter cutoff, and I just can't work out how to do it. No-one at my university program in pd or max, so I have had to search the internet for help. I've read these two pages http://obiwannabe.co.uk/html/music/6SS/six-simple-synthesisers.html http://en.flossmanuals.net/PureData/SimpleSynth and whilst the vline object on the flossmanuals site is fine when altering the envelope of an overtone in an additive synth, the output will not feed into the argument for a filter cutoff value. I can't even get the attack decay generator on the first site to work, let alone figure out how to alter it's seemingly inefficient design to allow sustain and release. I know this is quite trivial compared to some of the things that get posted in the mailing list, I would really appreciate it if anyone could help me, or point me in the right direction. I've spent too many nights scouring the internet and trying to work it out for myself, but I've simply hit a brick wall. Thank you in advance Samuel p.s. this is the text for the file i have been working on, it's a little bit messy and doesn't seem to work properly. BE CAREFUL, IT MAKES A THUMP WHEN OPENED, TURN OFF COMPUTE AUDIO #N canvas 366 35 610 629 10; #X obj 106 485 dac~; #X obj 94 115 phasor~; #X floatatom 104 77 5 0 0 0 - - -; #X obj 231 154 bng 15 250 50 0 empty empty
Re: [PD] midiin
I had the same problem. András Murànyi recommended [midirealtimein]. It's working perfectly here. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Laurent Willkomm Gesendet: Samstag, 11. Dezember 2010 12:15 An: Pd-list@iem.at Betreff: [PD] midiin Hello list, Using pd-extended 0.42.5 on Ubuntu Maverick 64 bit with alsamidi, I notice that [midiin] does not deliver MIDI Clock/Start/Stop/Continue messages. MTC, Sysex, End of Sysex are working. Kmidimon can see the clocks, so it's no alsa problem. Is this known/intended/bug ? L.Willkomm Noise Watchers Luxembourg ___ 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
Re: [PD] Pd-extended 0.42.5 Lucid - Audio Settings / Delay - not working!
No Bernardo, I get the same or even better latencies. Down to 6 ms with a very complex patch. Alsa is giving me more problems like digital A/D/A sync errors. As far as I know alsa is using oss anyway. Don't know if I'm wrong here. Ingo -Ursprüngliche Nachricht- Von: Bernardo Barros [mailto:bernardobarr...@gmail.com] Gesendet: Freitag, 18. Februar 2011 17:14 An: Ingo Scherzinger Cc: tim vets; pd-list@iem.at Betreff: Re: [PD] Pd-extended 0.42.5 Lucid - Audio Settings / Delay - not working! Ingo, I think OSS can offer you just very high latency. You can't get realtime with it. Did you test this 8ms latency, is that actually waht happens? I get latencies as low as 5~10 ms with alsa and jack. Besides, if you configure your system right with ALSA and JACK, you don't need to run PD as root. Don't run programs as root, this is not safe. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.42.5 Lucid - Audio Settings / Delay - notworking!
No Bernardo, I get the same or even better latencies. Down to 5-6 ms (pd audio sttings display) with a very complex patch. Alsa is giving me more problems like digital A/D/A sync errors. As far as I know alsa is using oss anyway. Not sure if I'm wrong here. Anyway, I just figured out what the problem was. I had a -blocksize 64 flag set when starting the patch. Changing this blocksize to a higher value like 512 did the trick. Now higher delay settings have an effect. Seems a bit strange to me as the actual blocksize doesn't seem to change but the maximum buffer size is increasing. It also like it's giving me a slightly lower cpu consumption (10-20%). I'll have to try different values in order to see what seems to be the best setting. Ingo -Ursprüngliche Nachricht- Von: Bernardo Barros [mailto:bernardobarr...@gmail.com] Betreff: Re: [PD] Pd-extended 0.42.5 Lucid - Audio Settings / Delay - not working! Ingo, I think OSS can offer you just very high latency. You can't get realtime with it. Did you test this 8ms latency, is that actually waht happens? I get latencies as low as 5~10 ms with alsa and jack. Besides, if you configure your system right with ALSA and JACK, you don't need to run PD as root. Don't run programs as root, this is not safe. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-extended 0.42.5 Lucid - Audio Settings / Delay - not working!
Besides the audio I sometimes need to run some [shell] commands that require root rights. No way to run it without being root. Ingo Besides, if you configure your system right with ALSA and JACK, you don't need to run PD as root. Don't run programs as root, this is not safe. i couldn't have said that better. gamdsr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] thanks for Pduino!
Ive just noticed there is an error in the digital ins. The digital ins 1 and 2 dont get added up correctly to the 8-bit number. So every time you switch between the fir two and the other digital ins you have an address of 0 for the first value. Took me half a day to find the error. There is a different status byte for these ins. Hans, if you are reading this you should take a look at it. I had it happen to me in the testing patch. Also there is a new and old behaviour for switching on the analogue ins. The new one only works for some of them. I had to switch back to the old message to turn them all on. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Richie Cyngler Gesendet: Dienstag, 1. März 2011 09:34 An: PD-List Betreff: [PD] thanks for Pduino! Hi all, Just wanted to say thanks to Hans and everyone involved in putting Pduino together. I am having a ball with it! So, thanks! -- shiny Rich ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] iemlib low pass filters exhibiting jitter?
I'm having the same problem. It's like a zipper noise that you can't avoid no matter what interpolation time you set. If you set it to 150 ms or above it works. But how can you have fast attacks like that? At the moment I am changing interpolation times after the initial attack time of the envelope generator. So I got rid of most of it. But still some noise during the attack period. Moog filter has audio ins. That one works a lot better but has a rather fixed, predefined (but good) sound. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Luka Princic // Nova deViator Gesendet: Mittwoch, 2. März 2011 17:26 An: pd-list@iem.at Betreff: [PD] iemlib low pass filters exhibiting jitter? hi, just a quick question, is it normal or somewhat on purpose that all versions of low pass filters in iemlib (from lp2 - lp10 and cheb, butt, bess and crit) exhibit slight high pitched jitter when cutoff frequency is being dynamicly changed? is it a nature of such filter or just a type of implementation that somewhat doesn't take care of interpolation (if interpolation is a problem at all)? any thoughts welcome... is there a way i could avoid that jitter with these filters? is there some other high-pole low pass filter in some other library i could use? sure, i can always use series of [lop~] .. best, luka -- sujet est machinique! Nova deViator ¤ http://deviator.si ¤ http://skylined.org ¤ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Patch for Akai EWI (was Reading and writing binary files)
Hi David, here's a full EWI-USB editor. However, it only works one way! Pd - EWI-USB. It cannot retrieve data from the EWI. If you want to save your data you should specify a path (marked with red bangs) twice for loading and saving and you need to set the midi port. Nothing else to do. I have tested it with Linux (Ubuntu). Not sure if it works on any other OS. Hope it's useful for some people! Cheers Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von David Gesendet: Dienstag, 8. März 2011 03:07 An: pd-list@iem.at; muran...@gmail.com Betreff: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) Thanks. I'm not sure I understand what you mean when you say you don't really need sysex, though. I have to send a 6 byte NRPN message, followed by a 14 byte SysEx message. I think I understand how to send the NRPN message, but I'm still confused about the SysEx message. Would I use [midiout] to do that? According to the help file in PD, this object is still undocumented and is only supported on Linux. Is that still true? And it only has two inlets, which I'm guessing would be an arbitrary 1 byte value and a channel number, but I'm not sure. Unfortunately, none of these messages are documented in the owner's manual or on their web site, but someone has reverse-engineered the messages and posted his findings here: http://www.ewiusb.com/sysex_page1 http://www.ewiusb.com/sysex_page2 The whole stream (an NRPN, a 14 byte SysEx, the same NRPN again, another 19 byte SysEx, and a final NRPN) would look like this, for example: // sysex enable : 63 01 62 04 06 20 // sysex message : F0 47 7F 6D 00 00 06 40 40 40 40 08 7F F7 // sysex enable : 63 01 62 04 06 20 // sysex message : F0 F7 7F 6D 02 00 0B 00 00 40 20 02 00 00 7F 00 7C 7D F7 // sysex done : 63 01 62 04 06 10 David. Message: 1 Date: Sun, 6 Mar 2011 18:07:59 +0100 From: Andr?s Mur?nyi muran...@gmail.com Subject: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) To: PD List pd-list@iem.at Message-ID: aanlktimf2tztoeqgx38blvs_rphk5yqli6nnfnb2u...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 NRPNS are interestingly made up of CC messages so you don't really need sysex. Attached [nrpnout] (original version by David McCallum) and [nrpnout- yamaha] where CC numbers are modified according to Yamaha specs. You may need to match two of the four CC numbers with your gear (the other two are always the same), and check if your gear needs MSB and LSB address or just one NRPN number. Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 84 54 391 514 10; #X obj 106 8 table ewi-usb_settings 17; #X msg 16 28 \; ewi-usb_settings read settings/ewi-usb_settings; #X obj 16 8 loadbang; #N canvas 0 0 1172 370 send_sysex 0; #X obj 420 328 midiout; #X obj 420 248 t l b; #X obj 57 141 tabread ewi-usb_settings; #X obj 30 121 t f f; #X obj 30 181 pack; #X obj 30 86 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 30 315 midiout; #X obj 30 248 t l b; #X text 94 294 set midi out port; #X text 484 307 set midi out port; #X msg 420 268 240 \, 71 \, 127 \, 109 \, 2 \, 0 \, 11 \, \$1 \, \$2 \, \$3 \, \$4 \, \$5 \, \$6 \, \$7 \, \$8 \, \$9 \, \$10 \, \$11 \, 247; #X obj 447 141 tabread ewi-usb_settings; #X obj 420 121 t f f; #X obj 420 181 pack; #X obj 420 228 pack f f f f f f f f f f f; #X msg 459 308 1; #X msg 69 295 1; #X msg 30 268 240 \, 71 \, 127 \, 109 \, 0 \, 0 \, 6 \, \$1 \, \$2 \, \$3 \, \$4 \, \$5 \, \$6 \, 247; #X obj 159 180 cnv 15 200 86 empty empty empty 20 12 0 14 -233017 -66577 0; #X text 166 177 \$1 = Breath Gain (0-127) 64; #X text 166 192 \$2 = Bite Gain (0-127) 64; #X text 166 207 \$3 = Bite AC Gain (0-127) 64; #X text 166 222 \$4 = Pitch Bend Gain (0-127) 64; #X text 166 252 \$6 = ? (?) 127; #X text 166 237 \$5 = Key Delay (0-15) 7; #X obj 420 86 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 246 28 inlet; #X msg 246 55 set \$1; #X obj 30 69 r \$0-bang_parameter_0-5; #X obj 420 69 r \$0-bang_parameter_6-16; #N canvas 1600 700 310 423 count_16-6 0; #X obj 86 46 inlet; #X obj 130 375 outlet; #X obj 98 282 f; #X msg 210 172 stop; #X obj 86 84 t b b; #X text 87 28 start; #X obj 210 216 metro 1; #X obj 113 180 + 1; #X obj 130 282 - 1; #X msg 113 160 16; #X obj 22 222 sel 6; #X connect 0 0 4 0; #X connect 2 0 8 0; #X connect 3 0 6 0; #X connect 4 0 6 0; #X connect 4 1 9 0; #X connect 6 0 2 0; #X connect 7 0 2 1; #X connect 8 0 2 1; #X connect 8 0 1 0; #X connect 8 0 10 0; #X connect 9 0 7 0; #X connect 10 0 3 0; #X connect 10 0 9 0; #X restore 420 101 pd count_16-6; #X obj 420 201 route 6 7 8 9 10 11 12 13 14 15 16; #X obj 30 201 route 0 1 2 3 4 5; #N canvas 1600 700 310 423 count_5-0 0; #X obj 86 46 inlet; #X
Re: [PD] Patch for Akai EWI (was Reading and writing binary files)
Oops, I just loaded the patch on a Windows XP machine. Looks like [midiout] is not working here. I guess the way to go would be NRPN on Windows. Unless there is another object that could handle SysEx that I am not aware of. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ingo Gesendet: Dienstag, 8. März 2011 18:35 An: 'David'; pd-list@iem.at Betreff: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) Hi David, here's a full EWI-USB editor. However, it only works one way! Pd - EWI-USB. It cannot retrieve data from the EWI. If you want to save your data you should specify a path (marked with red bangs) twice for loading and saving and you need to set the midi port. Nothing else to do. I have tested it with Linux (Ubuntu). Not sure if it works on any other OS. Hope it's useful for some people! Cheers Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von David Gesendet: Dienstag, 8. März 2011 03:07 An: pd-list@iem.at; muran...@gmail.com Betreff: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) Thanks. I'm not sure I understand what you mean when you say you don't really need sysex, though. I have to send a 6 byte NRPN message, followed by a 14 byte SysEx message. I think I understand how to send the NRPN message, but I'm still confused about the SysEx message. Would I use [midiout] to do that? According to the help file in PD, this object is still undocumented and is only supported on Linux. Is that still true? And it only has two inlets, which I'm guessing would be an arbitrary 1 byte value and a channel number, but I'm not sure. Unfortunately, none of these messages are documented in the owner's manual or on their web site, but someone has reverse-engineered the messages and posted his findings here: http://www.ewiusb.com/sysex_page1 http://www.ewiusb.com/sysex_page2 The whole stream (an NRPN, a 14 byte SysEx, the same NRPN again, another 19 byte SysEx, and a final NRPN) would look like this, for example: // sysex enable : 63 01 62 04 06 20 // sysex message : F0 47 7F 6D 00 00 06 40 40 40 40 08 7F F7 // sysex enable : 63 01 62 04 06 20 // sysex message : F0 F7 7F 6D 02 00 0B 00 00 40 20 02 00 00 7F 00 7C 7D F7 // sysex done : 63 01 62 04 06 10 David. Message: 1 Date: Sun, 6 Mar 2011 18:07:59 +0100 From: Andr?s Mur?nyi muran...@gmail.com Subject: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) To: PD List pd-list@iem.at Message-ID: aanlktimf2tztoeqgx38blvs_rphk5yqli6nnfnb2u...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 NRPNS are interestingly made up of CC messages so you don't really need sysex. Attached [nrpnout] (original version by David McCallum) and [nrpnout- yamaha] where CC numbers are modified according to Yamaha specs. You may need to match two of the four CC numbers with your gear (the other two are always the same), and check if your gear needs MSB and LSB address or just one NRPN number. Andras ___ 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
Re: [PD] Patch for Akai EWI (was Reading and writing binary files)
Hi David, I looked at your code, and I think I understand it, more or less. But I couldn't see where you're sending the 6-byte NRPN message before and after the SysEx message. Isn't it necessary? No! SysEx doesn't require any NRPN message to get enabled. I have no idea what the Aria software is sending out but it is definitely not necessary. There are a lot of strange things with the Garritan / Plogue software. I got this information from a web site created by someone who reverse-engineered the SysEx messages for the EWI USB: http://www.ewiusb.com/ According to him, you have to send the '63 01 62 04 06 20' before each SysEx, and '63 01 62 04 06 10' after the last one. You're not doing that? I haven't tested any of this stuff yet, I'm a little paranoid about screwing up my EWI. I can probably recover just by pressing the reset button if something goes wrong, but I'd rather not take the chance. I had double checked my information with that website. It turned out that there are several things that are wrong in this article. I wrote the guy from ewiusb.com an email and told him about the errors but never got any answer. He never corrected anything either. It doesn't look like the site is active anymore. BTW, you cannot break anything by sending sysex messages to an instrument. I am using this editor daily with no problem. I don't know which reason you have to trust one guy more than any other one? However I did discover an error in the patch this morning when I transferred a modified version into my hardware machine. Pitchbend down doesn't get restored correctly from the file. So there is a fixed version attached. It also writes the 6th value of the shorter sysex strings into the file which was ignored before. Just in case it would have any undocumented (ha, ha, ha) meaning. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ingo Gesendet: Dienstag, 8. März 2011 18:35 An: 'David'; pd-list@iem.at Betreff: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) Hi David, here's a full EWI-USB editor. However, it only works one way! Pd - EWI-USB. It cannot retrieve data from the EWI. If you want to save your data you should specify a path (marked with red bangs) twice for loading and saving and you need to set the midi port. Nothing else to do. I have tested it with Linux (Ubuntu). Not sure if it works on any other OS. Hope it's useful for some people! Cheers Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von David Gesendet: Dienstag, 8. März 2011 03:07 An: pd-list@iem.at; muran...@gmail.com Betreff: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) Thanks. I'm not sure I understand what you mean when you say you don't really need sysex, though. I have to send a 6 byte NRPN message, followed by a 14 byte SysEx message. I think I understand how to send the NRPN message, but I'm still confused about the SysEx message. Would I use [midiout] to do that? According to the help file in PD, this object is still undocumented and is only supported on Linux. Is that still true? And it only has two inlets, which I'm guessing would be an arbitrary 1 byte value and a channel number, but I'm not sure. Unfortunately, none of these messages are documented in the owner's manual or on their web site, but someone has reverse-engineered the messages and posted his findings here: http://www.ewiusb.com/sysex_page1 http://www.ewiusb.com/sysex_page2 The whole stream (an NRPN, a 14 byte SysEx, the same NRPN again, another 19 byte SysEx, and a final NRPN) would look like this, for example: // sysex enable : 63 01 62 04 06 20 // sysex message : F0 47 7F 6D 00 00 06 40 40 40 40 08 7F F7 // sysex enable : 63 01 62 04 06 20 // sysex message : F0 F7 7F 6D 02 00 0B 00 00 40 20 02 00 00 7F 00 7C 7D F7 // sysex done : 63 01 62 04 06 10 David. Message: 1 Date: Sun, 6 Mar 2011 18:07:59 +0100 From: Andr?s Mur?nyi muran...@gmail.com Subject: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) To: PD List pd-list@iem.at Message-ID: aanlktimf2tztoeqgx38blvs_rphk5yqli6nnfnb2u...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 NRPNS are interestingly made up of CC messages so you don't really need sysex. Attached [nrpnout] (original version by David McCallum) and [nrpnout- yamaha] where CC numbers are modified according to Yamaha specs. You may need to match two of the four CC numbers with your gear (the other two are always the same), and check if your gear needs MSB and LSB address or just one NRPN number. Andras
Re: [PD] Patch for Akai EWI (was Reading and writing binary files)
Hi David, just out of curiosity I checked the dump requests in order to see if there is any reason for transmission of these NRPN controllers. There is absolutely no reason for them! I've attached my updated SysEx chart for the EWI-USB in case you want to mess around with anything. BTW the NRPN controllers are only being sent when there is a dump request from the Aria software to the EWI. Not when data is being sent to the EWI. After the dump is transmitted to the EWI the software sends another full (3 part) dump request and everything on page 1 of the chart is repeated. To me it looks like Plogue - who wrote the software - simply forgot to take out the NRPNs. This got me confused in the beginning, too. It's just a general problem when people like ewi-usb.com put some incorrect information on the web and don't correct this information anymore after it turns out to be wrong. Then guys like you and many others get confused. Ingo -Ursprüngliche Nachricht- Von: David [mailto:dfket...@gmail.com] Gesendet: Mittwoch, 9. März 2011 20:00 An: Ingo Cc: pd-list@iem.at Betreff: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) See below. On Wed, Mar 9, 2011 at 1:36 PM, Ingo i...@miamiwave.com wrote: Hi David, I looked at your code, and I think I understand it, more or less. But I couldn't see where you're sending the 6-byte NRPN message before and after the SysEx message. Isn't it necessary? No! SysEx doesn't require any NRPN message to get enabled. I have no idea what the Aria software is sending out but it is definitely not necessary. There are a lot of strange things with the Garritan / Plogue software. Thanks. I agree, the software is a little weird. For example, when you save the settings, why does it save them in two different files? I assumed at first that all the settings would be saved in a single file. It doesn't explain that anywhere, I just discovered it by poking around and opening the files in a text editor that can handle binary files. I got this information from a web site created by someone who reverse-engineered the SysEx messages for the EWI USB: http://www.ewiusb.com/ According to him, you have to send the '63 01 62 04 06 20' before each SysEx, and '63 01 62 04 06 10' after the last one. You're not doing that? I haven't tested any of this stuff yet, I'm a little paranoid about screwing up my EWI. I can probably recover just by pressing the reset button if something goes wrong, but I'd rather not take the chance. I had double checked my information with that website. It turned out that there are several things that are wrong in this article. I wrote the guy from ewiusb.com an email and told him about the errors but never got any answer. He never corrected anything either. It doesn't look like the site is active anymore. I think you're right, I sent him an email a couple of weeks ago and never got a reply. BTW, you cannot break anything by sending sysex messages to an instrument. I am using this editor daily with no problem. I don't know which reason you have to trust one guy more than any other one? Sorry, I didn't mean any offense. I was only erring on the side of caution. I was just afraid of bricking my EWI. However I did discover an error in the patch this morning when I transferred a modified version into my hardware machine. Pitchbend down doesn't get restored correctly from the file. So there is a fixed version attached. It also writes the 6th value of the shorter sysex strings into the file which was ignored before. Just in case it would have any undocumented (ha, ha, ha) meaning. Thanks again. Ingo EWI-USB_SysEx.pdf Description: Adobe PDF document ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Patch for Akai EWI (was Reading and writing binary files)
Hi David, Again, sorry if I caused offense, I didn't mean to. That's no offense at all. I am just a little annoyed with other people like ewi-usb.com (and more of them) who put up information on shiny looking websites (I have one, too, BTW) but publish wrong information and don't seem to care about it. Or companies like Akai who give you no information at all about their products! I'm happy if the patch is helping you. I needed to finish this anyway right now because I am putting the editor into a hardware machine at the moment. Cheers Ingo -Ursprüngliche Nachricht- Von: David [mailto:dfket...@gmail.com] Gesendet: Donnerstag, 10. März 2011 14:45 An: Ingo Betreff: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) Thanks. I tested my patch last night, without sending the NRPN, and you're right, it seems to work. Maybe there was a modification to the firmware at some point that eliminated the requirement, I'm just guessing. The info on the web site is a little dated. David. On Thu, Mar 10, 2011 at 5:53 AM, Ingo i...@miamiwave.com wrote: Hi David, just out of curiosity I checked the dump requests in order to see if there is any reason for transmission of these NRPN controllers. There is absolutely no reason for them! I've attached my updated SysEx chart for the EWI-USB in case you want to mess around with anything. BTW the NRPN controllers are only being sent when there is a dump request from the Aria software to the EWI. Not when data is being sent to the EWI. After the dump is transmitted to the EWI the software sends another full (3 part) dump request and everything on page 1 of the chart is repeated. To me it looks like Plogue - who wrote the software - simply forgot to take out the NRPNs. This got me confused in the beginning, too. It's just a general problem when people like ewi-usb.com put some incorrect information on the web and don't correct this information anymore after it turns out to be wrong. Then guys like you and many others get confused. Ingo -Ursprüngliche Nachricht- Von: David [mailto:dfket...@gmail.com] Gesendet: Mittwoch, 9. März 2011 20:00 An: Ingo Cc: pd-list@iem.at Betreff: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) See below. On Wed, Mar 9, 2011 at 1:36 PM, Ingo i...@miamiwave.com wrote: Hi David, I looked at your code, and I think I understand it, more or less. But I couldn't see where you're sending the 6-byte NRPN message before and after the SysEx message. Isn't it necessary? No! SysEx doesn't require any NRPN message to get enabled. I have no idea what the Aria software is sending out but it is definitely not necessary. There are a lot of strange things with the Garritan / Plogue software. Thanks. I agree, the software is a little weird. For example, when you save the settings, why does it save them in two different files? I assumed at first that all the settings would be saved in a single file. It doesn't explain that anywhere, I just discovered it by poking around and opening the files in a text editor that can handle binary files. I got this information from a web site created by someone who reverse-engineered the SysEx messages for the EWI USB: http://www.ewiusb.com/ According to him, you have to send the '63 01 62 04 06 20' before each SysEx, and '63 01 62 04 06 10' after the last one. You're not doing that? I haven't tested any of this stuff yet, I'm a little paranoid about screwing up my EWI. I can probably recover just by pressing the reset button if something goes wrong, but I'd rather not take the chance. I had double checked my information with that website. It turned out that there are several things that are wrong in this article. I wrote the guy from ewiusb.com an email and told him about the errors but never got any answer. He never corrected anything either. It doesn't look like the site is active anymore. I think you're right, I sent him an email a couple of weeks ago and never got a reply. BTW, you cannot break anything by sending sysex messages to an instrument. I am using this editor daily with no problem. I don't know which reason you have to trust one guy more than any other one? Sorry, I didn't mean any offense. I was only erring on the side of caution. I was just afraid of bricking my EWI. However I did discover an error in the patch this morning when I transferred a modified version into my hardware machine. Pitchbend down doesn't get restored correctly from the file. So there is a fixed version attached. It also writes the 6th value of the shorter sysex strings into the file which was ignored before. Just in case it would have any undocumented (ha, ha, ha) meaning. Thanks again. Ingo
Re: [PD] Patch for Akai EWI (was Reading and writing binary files)
Are there any changes you've made from my original patch? Looks pretty much identical to me. Ingo -Ursprüngliche Nachricht- Von: David [mailto:dfket...@gmail.com] Gesendet: Montag, 14. März 2011 03:55 An: Ingo Cc: pd-list@iem.at Betreff: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) Here's the finished patch. Any feedback is welcome. I don't have a web site of my own, but if anyone knows of a suitable repository for puredata code, let me know. David. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Patch for Akai EWI (was Reading and writing binary files)
Sorry, I was looking at the wrong patch. Ingo -Ursprüngliche Nachricht- Von: Ingo [mailto:i...@miamiwave.com] Gesendet: Montag, 14. März 2011 11:04 An: 'David'; 'Ingo' Cc: pd-list@iem.at Betreff: AW: [PD] Patch for Akai EWI (was Reading and writing binary files) Are there any changes you've made from my original patch? Looks pretty much identical to me. Ingo -Ursprüngliche Nachricht- Von: David [mailto:dfket...@gmail.com] Gesendet: Montag, 14. März 2011 03:55 An: Ingo Cc: pd-list@iem.at Betreff: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) Here's the finished patch. Any feedback is welcome. I don't have a web site of my own, but if anyone knows of a suitable repository for puredata code, let me know. David. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Patch for Akai EWI (was Reading and writing binary files)
Hi David, I have not tested your patch so far but: Your default midi channel is 0 ??? Your velocity default is 32 instead of 120 default for breath_cc2 should be aftertouch and not 0 default key delay should be 7 (not that this matters at all) but... pitchbend up / down needs to be 127 and not 124 / 125 as stated by www.ewi-usb.com. Didn't I mention there were errors on that website? Although I told that some of the stuff is incorrect and provided you the correct information you simply copy this wrong information and want to publish it somewhere else with your own copyright??? Come on! Ingo -Ursprüngliche Nachricht- Von: Ingo [mailto:i...@miamiwave.com] Gesendet: Montag, 14. März 2011 11:07 An: 'Ingo'; 'David' Cc: pd-list@iem.at Betreff: AW: [PD] Patch for Akai EWI (was Reading and writing binary files) Sorry, I was looking at the wrong patch. Ingo -Ursprüngliche Nachricht- Von: Ingo [mailto:i...@miamiwave.com] Gesendet: Montag, 14. März 2011 11:04 An: 'David'; 'Ingo' Cc: pd-list@iem.at Betreff: AW: [PD] Patch for Akai EWI (was Reading and writing binary files) Are there any changes you've made from my original patch? Looks pretty much identical to me. Ingo -Ursprüngliche Nachricht- Von: David [mailto:dfket...@gmail.com] Gesendet: Montag, 14. März 2011 03:55 An: Ingo Cc: pd-list@iem.at Betreff: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) Here's the finished patch. Any feedback is welcome. I don't have a web site of my own, but if anyone knows of a suitable repository for puredata code, let me know. David. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Patch for Akai EWI (was Reading and writing binary files)
Hi David, P.S. Did you mean midi channel or midi port? The inlet to EWI-send is for the midi port. The midi port depends on your hardware. That cannot be known. The midi channel is 1 (like in Pd) however the EWI needs numbers between 0 and 15 while the common use of midi channels goes from 1-16 (like in Pd). So the patch needs to show 1 while it is transmitting 0 to the EWI. As far as the default values in general: Only a few of them are important to be set to a specific value. Two of them are the pitchbend settings which need to be set to 127. They do nothing at 124 or 125. I thought you tested this? (Although I have to admit that I have not updated the firmware or software within the last 6 months.) Ingo -Ursprüngliche Nachricht- Von: David [mailto:dfket...@gmail.com] Gesendet: Montag, 14. März 2011 13:35 An: Ingo Cc: pd-list@iem.at Betreff: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) On Mon, Mar 14, 2011 at 8:23 AM, David dfket...@gmail.com wrote: See below. On Mon, Mar 14, 2011 at 7:36 AM, Ingo i...@miamiwave.com wrote: Hi David, I have not tested your patch so far but: Your default midi channel is 0 ??? Your velocity default is 32 instead of 120 default for breath_cc2 should be aftertouch and not 0 default key delay should be 7 (not that this matters at all) but... pitchbend up / down needs to be 127 and not 124 / 125 as stated by www.ewi-usb.com. Didn't I mention there were errors on that website? Yes, you did tell me there were errors, but you didn't say what they all were. The only error you mentioned specifically was the need to send the NRPN message (and thanks for that). However, I looked at the files produced by the Garritan software, and they seemed to agree with the defaults on that web site, as far as I can remember. Maybe it depends on which version of the firmware and which version of the Garritan software you're using, I don't really know. In any case, they can be overridden, that's the whole purpose of writing this patch in the first place. As for the Midi channel, I'm not sure whether the first midi channel is supposed to be 0 or 1. It's just the default anyway, it's going to have to be changed, depending on how many midi devices you have attached, and in what order. Although I told that some of the stuff is incorrect and provided you the correct information you simply copy this wrong information and want to publish it somewhere else with your own copyright??? The copyright isn't on the information from his web site (which I'm not reproducing anyway), it's on my PureData code, so I don't really understand what you're complaining about. Come on! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Patch for Akai EWI (was Reading and writing binary files)
Same here. Ingo -Ursprüngliche Nachricht- Von: David [mailto:dfket...@gmail.com] Gesendet: Dienstag, 15. März 2011 01:00 An: Ingo Cc: pd-list@iem.at Betreff: Re: [PD] Patch for Akai EWI (was Reading and writing binary files) By the way, it seems I also have version 1 of the firmware, if you can believe what it says in the EWI configuration panel. I'm not sure how it would know that, unless there's a SysEx or NRPN message to query the version number. As for the software, I have v1005 (?!) of the Akai EWI USB software and v1.066 of the Aria software, for Windows x64. Is that what you have? On Mon, Mar 14, 2011 at 7:12 PM, David dfket...@gmail.com wrote: I made the changes to the default values that you recommended (if there are any more that are wrong, let me know). And I fixed the Midi channel problem. That was just a dumb mistake on my part. Although I set the range to be from 1 to 16 in the number box, I was initializing it to zero! Hope you like this version a little better. David. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Midi note handling for monophonic synth
I am using a [coll] object to store all notes being played and not yet released. When the current note is released it recalls the last note that was stored from the [coll] list by sending something like [end, bang( to [coll]. You can play as many notes as you want and it will always go back to the last note played. When releasing a note (that may not even sound ATM) it gets erased from [coll] by using [remove $1(. To separate note on / off I use [nroute 0 2]. Note priority in this case is last which is all I personally ever need. (I suppose other priorities can be set by using some sorting options within [coll].) In order to avoid other notes cutting off the current note I find the easiest (monophonic) solution is to add [poly 1 1] right before sound generation. This sends a note off to the last note played before starting the new one and avoids double note offs. I am using this in a rather complex patch. Ill see if I can extract just this single part of it if you can't get it to work correctly. Although I dont think Ill be able get to it until next week. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Joe White Gesendet: Donnerstag, 21. April 2011 13:48 An: pd-list@iem.at Betreff: [PD] Midi note handling for monophonic synth Hi all, I'm implementing a synth in Pd using midi/notein as an input. One problem I keep coming up against is handling note off messages. This guy's blog post describes the issue - http://kemptonmooney.com/2010/09/pure-data-midi-note-off-solution/ However, I think his solution is not exactly what I'm looking for. The synths I use in Logic have note priority methods and remember all held down notes (or at least 10). I wondering if anyone has managed to implement something like this in Pd or might know where I can find out more about it. ddg.mono from Max (http://www.cycling74.com/docs/max5/refpages/m4l-ref/ddg.mono.html) looks similar to what I want - but I don't use Max and I don't think I can access the source. Any ideas? Thanks, Joe ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Midi note handling for monophonic synth
Yes, I can extract a small patch with just that functionality. But I'm afraid you'll have to mess with it for a while if you want to use it with Vanilla. I'll get back to you after Easter. Ingo Von: Joe White [mailto:white.j...@gmail.com] Gesendet: Donnerstag, 21. April 2011 14:47 An: Ingo Cc: pd-list@iem.at Betreff: Re: [PD] Midi note handling for monophonic synth Hi Ingo, Thanks for the reply, [coll] and [poly] definitely look useful. However, I forget to mention I'm using Pd Vanilla :( The information you provided is really helpful though, I'm thinking if I can try and replicate the functionality of [coll], maybe using tables or something similar. I tried a while ago but it ended up getting messy. If you can extract your method from your patch that'd be much appreciated. Thanks, Joe On 21 April 2011 13:36, Ingo i...@miamiwave.com wrote: I am using a [coll] object to store all notes being played and not yet released. When the current note is released it recalls the last note that was stored from the [coll] list by sending something like [end, bang( to [coll]. You can play as many notes as you want and it will always go back to the last note played. When releasing a note (that may not even sound ATM) it gets erased from [coll] by using [remove $1(. To separate note on / off I use [nroute 0 2]. Note priority in this case is last which is all I personally ever need. (I suppose other priorities can be set by using some sorting options within [coll].) In order to avoid other notes cutting off the current note I find the easiest (monophonic) solution is to add [poly 1 1] right before sound generation. This sends a note off to the last note played before starting the new one and avoids double note offs. I am using this in a rather complex patch. Ill see if I can extract just this single part of it if you can't get it to work correctly. Although I dont think Ill be able get to it until next week. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Joe White Gesendet: Donnerstag, 21. April 2011 13:48 An: pd-list@iem.at Betreff: [PD] Midi note handling for monophonic synth Hi all, I'm implementing a synth in Pd using midi/notein as an input. One problem I keep coming up against is handling note off messages. This guy's blog post describes the issue - http://kemptonmooney.com/2010/09/pure-data-midi-note-off-solution/ However, I think his solution is not exactly what I'm looking for. The synths I use in Logic have note priority methods and remember all held down notes (or at least 10). I wondering if anyone has managed to implement something like this in Pd or might know where I can find out more about it. ddg.mono from Max (http://www.cycling74.com/docs/max5/refpages/m4l-ref/ddg.mono.html) looks similar to what I want - but I don't use Max and I don't think I can access the source. Any ideas? Thanks, Joe ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] which object to use to resolve my problem?
How about this: #N canvas 0 0 445 233 10; #X obj 40 31 inlet; #X obj 40 95 t b b; #X obj 67 160 spigot 1; #X msg 132 143 0; #X obj 40 58 sel \$1 0; #X msg 112 113 1; #X obj 67 187 outlet; #X text 101 34 number 0 does a reset; #X text 101 19 1st argument is the number that sends one single bang ; #X connect 0 0 4 0; #X connect 1 0 3 0; #X connect 1 1 2 0; #X connect 2 0 6 0; #X connect 3 0 2 1; #X connect 4 0 1 0; #X connect 4 1 5 0; #X connect 5 0 2 1; Hope that's what you're looking for! Cheers, Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von FernandoG Gesendet: Sonntag, 5. Juni 2011 08:49 An: pd-list@iem.at Betreff: [PD] which object to use to resolve my problem? Hello I need a object or an abstraction that send a unique and single bang when a incoming number reach certain defined value and do nothing while this incoming number varies in proximities of the desired value, but when incoming number return to 0 the process is reset and start again. By the way, my incoming number is an analog input from arduino board. anybody knows if there is and object to do that, or wich object i can use to build a patch to do it? thanks! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
With the latest version, the only way I've found that actually works to enable analog input pins are the so-called old messages analogIns npin 1/0 /listinfo/pd-list I was mentioning that before. I had the same problem. There is another problem with the digital ins 1 and 2. I got myself a workaround. Unfortunately I don't remember anymore what it was exactly. It happened when you went from pin 1 or 2 to another one and back. The first value came out as a 0 instead of the correct version. I think it had to do with the fact that pins 1-8 should form a 8-bit number but 1+2 are part of another 8-bit number or something like that. It happens somewhere in the part of the mapping. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
The exact same thing that Matteo mentioned about the old analogue method is happening here, too. Tested with Diecimila and Duemilanove. I was also using the test patch as a starting patch. My workaraound was simply to use the old method (after for searching for quite some time). I need to find the other problem with the digital Ins 1+2 giving wrong values will first. I will post a patch to reproduce it asap but it might take a couple of days to look for it. I had a workaround for it already but I do not know if this workaround could still be applied with other boards like the mega. As far as I remember it was a problem of the firmata sending wrong data rather than the pd patch doing something wrong. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Matteo Sisti Sette Gesendet: Dienstag, 14. Juni 2011 16:26 An: Roman Haefeli Cc: 'PD List' Betreff: Re: [PD] pduino test patch: old analog/digital controls On 06/13/2011 09:09 PM, Roman Haefeli wrote: @Ingo and Matteo I'm also quite interested in having the [arduino] working properly. I didn't find any bugs recently, though. However, if you provide a step-by-step guide about how to reproduce a problem, I (and probably Olsen also) might be able to help, Ok, the problem is that in my case I'm not sure whether I'm experiencing an issue, an incorrectness in the test patch, or just my lack of knowledge of how it is _expected_ to behave. With both old and new versions of the StandardFirmata firmware the following message enables analog input from pin A0 (i.e. pin 14): analogIns 0 1 (0 means A0 and 1 means on) But in the test patch this is enclosed in a subpatch calles old analog/digital controls so is it supposed to be obsolete? The only other way I've seemed to find to enable input from analog pin A0 is: pinMode 14 analog which seems to be the suggested way in the test patch (offered with the pink grid on the upper-right part of the patch), but this only works with OLD versions of StandardFirmata. So it looks like either: a. there is a third, current, non-obsolete, recommended way of doing that which I don't know b. the suggested way is the old one and the one documented as old is actually the new one (but I don't think so, that's not what Chris said) c. something isn't working right The same happens with both Arduino 2009 (with the StandardFirmata sketch) and with an Arduino UNO (with the StandardFirmata_2_2_for_UNO_0_3). Both sketches are those that ship with the latest package of the Arduino IDE for Debian sid. The older StandardFirmata sketch where the pinMode N analog message worked were taken from an older version of the arduino package for Ubuntu from the official repository, but I don't remember the version number. ___ 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
Re: [PD] Pd performance at TED
Yep, he's been building this controller with Pd for a couple of years now. A great step up from using his Yamaha WX5 wind controller playing more or less mainstream stuff. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Hans-Christoph Steiner Gesendet: Sonntag, 19. Juni 2011 06:45 An: pd-list@iem.at Betreff: [PD] Pd performance at TED I just wanted this performance by Onyx Ashanti as part of the TED Talks stuff. Its quite a nice performance using live sensor control of Pd: http://www.ted.com/talks/onyx_ashanti_this_is_beatjazz.html It looks like you can even see Pd on the screen behind him. .hc ___ 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
Re: [PD] Pd performance at TED
I absolutely agree with you, Hans! Onyx is doing great live playing with traditional rhythms and phrasings using his own custom built wind controller and Pd. I'm not sure what would classify music with no rhythmical elements and scales and chords as being more artistic? Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Hans-Christoph Steiner Gesendet: Sonntag, 19. Juni 2011 17:32 An: Mathieu Bouchard Cc: pd-list@iem.at; Marco Donnarumma Betreff: Re: [PD] Pd performance at TED On Jun 19, 2011, at 9:50 AM, Mathieu Bouchard wrote: On Sun, 19 Jun 2011, Marco Donnarumma wrote: it seems quite sad to me that the first performance with pd at ted has to be this. With all the respect due to Onyx, but using control sensor to play as a dj seems a technological parody. Besides, the whole system looks a bit clunky, doesn't it? Does it ? Do you care to explain yourself ? What's a « technological parody » ? And what's that thing you call a « dj » ? You use it in your own name thesaddj. What's your relationship with that word ? I think the key is not what it looks like, but what he does with it. He's making music with it (no ifs, ands, or buts), he clearly has musical skill with his instrument, and is able to keep the musical timing tight. These are all difficult things to do, and from what I've seen 95% of performance with new interfaces for musical expression does not achieve one of those goals solidly. .hc Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick ___ 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
Re: [PD] Pd performance at TED
Sorry Marco, but I can see that you have never played jazz! Ingo Von: Marco Donnarumma [mailto:de...@thesaddj.com] Gesendet: Montag, 20. Juni 2011 13:43 An: Ingo Cc: pd-list@iem.at Betreff: Re: [PD] Pd performance at TED Ingo, thanks for your explanation, I think to understand how he's playing. The movement looks to me secondary - it's more like a dance movement and not too much music control. This might be a very personal take, but if movement is secondary in gestural control, why one uses gestural control at all? I believe that effective and ancillary gestures are what reinforce our perception of an instrument as a musical tool, rather than a mere device. Imho many gestural controllers would benefit of a better focus on this aspect. How would you play such melodic lines (like those jazz licks) - in time - simply with gestural control? Setting an array of preset chords, triggering them with multiple switches, deploying a timeline which holds the trigger until the onset of the next beat or quarter, etc... I guess the list here could come up with many other methods. I'm not saying that's trivial, I only think that it's not the future as it is presented in the video. How would you improvise on scales, pattern or harmonic structures? After all he's a jazz player calling his music beat jazz. What do you call improvisation in this case? How much is he improvising? I can imagine he's improvising with the melodic lines, but playing samples and presets chords doesn't match my own definition of improvisation. cheers, M -- Marco Donnarumma Independent New Media and Sonic Arts Professional, Performer, Instructor ACE, Sound Design MSc by Research (ongoing) The University of Edinburgh, UK ~ Portfolio: http://marcodonnarumma.com Lab: http://www.thesaddj.com | http://cntrl.sourceforge.net | http://www.flx er.net Event: http://www.liveperformersmeeting.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Testing whether a directory is empty without printing error messages if it is
You could first write any kind of file into the directory first. Then get the directory content but ignore the file you just wrote - maybe even delete it afterwards. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Matteo Sisti Sette Gesendet: Montag, 20. Juni 2011 18:37 An: PD-List Betreff: [PD] Testing whether a directory is empty without printing error messages if it is Hi, I'm using [folder_list] to perform the following tasks: - check whether a directory or file exists - get the list of files in a directory (which is an empty list if the directory is empty) However, when the file does not exist or the directory of which I'm getting the list is empty, it prints an error message on the console. The test works, but I need to avoid printing error messages when there's no error to worry about. Is there another way of getting a directory list without printing an error message to the console if the list is empty? Thanks m. ___ 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
Re: [PD] Pd performance at TED
-Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von martin brinkmann Gesendet: Montag, 20. Juni 2011 22:12 An: pd-list@iem.at Betreff: Re: [PD] Pd performance at TED On 06/20/2011 01:43 PM, Marco Donnarumma wrote: Ingo, thanks for your explanation, I think to understand how he's playing. i do not think i do (completely), though i have only watched it twice so far. it seems that everything is based heavily on live-looping. at first i thought he was using some kind of midi/parameter-looping, like recording the chords first, and the filter/fx/whatever parameters in a second pass, but after watching it the second time, i noticed, that the chords (including sound parameters) repeat exactly while he was doing something else, like it would be the case with audio-looping. i can not tell if the chords/melodie are presets triggered with the buttons (thats probably what i would do) or played in a completely open way, maybe using a preset scale or something similar. and i wonder how he managed to sync the drumloop (if it is one, and not something recorded using the buttons/wind controller) to the chord loops recorded earlier. (in-ear) monitor and some kind of metro/click track would of course explain this. All lines are played live. There is no pre-recorded drum loop. He is using audio looping only. The drums are played note by note. He starts out with a HiHat (selected with the fingering of his windcontroller) triggered by the breath controller to play the rhythm. Then he adds the other drum sounds on top of it. Just as you would do when you program a drum pattern with a regular drum computer. He has a visible metronome on his phone that allows him to keep the tempo. Every instrumental line is added by playing it into the audio looper. The chords are fixed chords moving in parallel and are used like a melodic line. There is no sequencing! The looper seems to have several tracks that can be selected and turned on or off by some buttons. This is the reason for the coloured lights. To make an overdub with a specific instrument you need to know which instrument you will be playing. One of the buttons seems to merely toggle through the tracks of the looper. So a visible feedback (coloured LEDs) for the musician is inevitable. There are accelometers fixed to his hands which he uses for filtering. So the point of this is not the gestural control but to simply add some extra controllers as a wind controller is usually limited to a small number of parameters: notes, volume (breath control), pitchbend and maybe one or two more controllers located on the mouthpiece or some special buttons, sliders or pressure sensors that could be used for other things. Using more parts of the body than just the usual woodwind fingerings opens up the sound possibilities while still having the traditional woodwind controls. BTW these take years of practicing! So you don't want to sacrifice your skills by using the standard controls for other things than what they are meant to be in a standard way. That's the real reason for involving the whole body in his playing - to expand the number of available controllers. i think this uncertainty of what is going on 'on stage' is a general problem with electronic music, which was (obviously) not solved with this performance either, since even people who know about this stuff have only vague ideas of what is happening. for an audience with a background in electronic/computer/whatever music, a authentic and satisfying performance might be less challenging though.an obvious example is live coding, where it is totally clear to the audience what is happening. but even a 'laptop gig' becomes less boring, when you can see what is happening on the screen (of course only if there is something happening), for example in a mirror behind the performer. (works very well in very small venues as far as i have experienced) Well, I really don't know why there is a reason fort he audience to know what is going on. Does a violin player - when he plays a Mozart concerto - have to explain what position he is playing on the left hand and which bow stroke he uses? Does it make a difference to the audience if he is using spiccato or ricochet on this particular phrase? Does the audience have to know how a piano was built in order to appreciate and enjoy piano music? There is way too much technical thinking going on in a lot of electronic music. Instead of using technology to make expressive musical applications in the sense of e.g. a flute that has been around for thousands of years people go away from basic, emotional traditional musical expression and put technology first. I do not think that this kind of music can ever replace the empiric musicality that has been around since there is mankind. This might be a very personal take, but if movement is secondary in gestural control, why one uses gestural control at all
Re: [PD] Pd performance at TED
Sorry Marco, but I can see that you have never played jazz! Marco, Unfortunately not Ingo. Would love to. I play regularly electroacoustic free improv. So perphaps we are talking a different language? Definitely! Could you elaborate your answer? If I'm missing something about the innovation of that work I'd be glad to learn :) What I have seen on your videos is very good and interesting but has absolutely nothing to do with jazz - obviously! When playing jazz you want to have control over every note that you are playing in the range of a couple milliseconds. You also want to control the timing, bending, volume, volume changes even within every note (articulation) and the sound of each individual note. In case you are playing with other people (which is not the case in this particular performance) you need to be able to react to other musicians by picking up melodic / rhythmical lines and elaborate on them in the context of the changes of the harmonic structure and build melodies on the fly that make musical, expressive and emotional sense. This cannot be achieved by triggering patterns! You're interface might be able to produce great soundscapes but it cannot get deep enough into the musical microcosms to shape each individual note within a melodic line where every single note may be only 100 ms long. It takes a completely different interface for that. It's much more like playing a saxophone or a violin where every attack, articulation, vibrato, etc counts. The electronic wind controller version has the advantage that you can produce other sounds like drums, synths, do looping and so on while still going for the same musical content. BTW I don't think Pd plays any role in what Onyx Ashanti is doing. He could use Pd for it or he could use a bunch of other boxes to do what he does. However Pd has the advantage of doing everything in one box rather then five of them. In what he is doing he is definitely not showcasing Pd. Today's available wind controllers are very limited! This is why people like Onyx build alternatives. I am experimenting myself with a custom wind controller that could overcome some of the problems that I am having with them. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd performance at TED
Marco's disappointment is understandable (sorry if I misinterpret this Marco). When I watched Top of the pops as a teenager, like many kids of that age I was outraged that the performers mimed. Sometimes you could see their instruments were just props. It is amazing that even most poeple in this list think that this is a playback show by simply triggering loops. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd performance at TED
Onyx, I really appreciate you chiming in here! I just happened to read your blog after I wrote what I've described to the pd-list what you are doing with your controller. Luckily I was 100% right. I have been thinking about a controller very similar to your's since several years. I know exactly what's going on in your mind. I have already built a sound module which is optimized for wind controllers and I do not see any reason for wind controllers to look like a sax or clarinet. There are many limitations with EWIs and WX5s. It was about time somebody went other ways. And I have to say once more that I really appreciate and like your live playing / looping. Ingo -Ursprüngliche Nachricht- Von: Onyx Ashanti [mailto:onyxasha...@gmail.com] Gesendet: Dienstag, 21. Juni 2011 12:39 An: i...@miamiwave.com Betreff: Re: [PD] Pd performance at TED I figured that I would chime in at this point. Every single note you hear, is being played, as in one at a time, as a horn player does, into a looper which I use to layer everything very quickly into an arrangement then deconstruct and reconstruct on a musically relevant trajectory. There was nothing pre recorded or preconceived. Simply a controller, a database of synthesizers and a looper with effects. I am playing every single solitary note. If that sounds like it is hard to do, you're right. As for not seeing how pd is used in this project, The controller is merely 3 arduinos, running hans wonderful firmata/pduino software, connected wirelessly to puredata where I created the wind controller software and gestural systems. Without pd there is no system. It's all documented from day one on my blog. No parodies involved. I would like an elaboration on how the system is clunky if you don't mind. First off, I feel that it is pretty streamlined for a first prototype made of cardboard that is only 3 months old. Two wireless hand units and a mouth unit. If you have suggestions as to how I might improve it at this stage, before my next stage or dev, I would love to hear it. @marco, how would you make this concept more beautiful or efficient? I am always a willing student in these regards. Do you have any examples of said efficiency? Being an instructor, I would have expected that you would have seen the blog link on the Ted profile and researched your position before simply asserting that my concept has no value. @Tyler. You are correct in that I don't care about making it rain granular algorithms (yet), I want to be able to express myself for fully using tools available to me. Hans and others were nice enough to help me with advice and code and it just happened that some people (Ted) other than my immediate fans found it interesting. Even now, I still busk, but this opportunity makes it a bit easier to realize some of these larger goals. The phone is used as a headup display for making sure all my sensors are doing what they are supposed to do. @richie. I have been a pro in electronic music for 15 years. Google it. One thing that I and other alternative controller artists are realizing is that we must be in the audience. Otherwise people can not see that you are actually playing. That is why when I play clubs I play from the dance floor and currently monitor with the club sound system which is hard but allows a flow of ideas that doesn't come from separating ones self from the audience. And from there people can see your fingers and gestures carve the sound. This form of performance blends my desire to connect with my space my music and my movements as intimately but, it should be noted as well, this is a 3 month old prototype so that people are discussing it and I have even moved from beta stage yet, is encouraging. If you would like to hear what is possible with this concept, go to www.onyxashanti.bandcamp.com/album/onyx-Ashanti-full-promotional-package- download-2 Or feel free to ask me. Www.beatjazz.blogspot.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd performance at TED
As Ingo said in a PM to me (sorry my bad on the cc Ingo), Ooops! That wasn't ment to be a private mail. I thought I had it sent to the pd-list, also. I guess I pushed the wrong button! Sorry! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] USB-MIDI not working anymore after installing Realtek sound drivers
Hi everybody, after installing the proprietary sound drivers of a realtek ACM 892 on Ubuntu 10.4 my USB-MIDI drivers stopped working completely. No interface (out of 3) shows up in /proc/asound/cards anymore. Does anybody know how to reinstall USB-MIDI drivers. Thanks, Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Arduino (is drivin me mad
I fixed it by replacing the mapping object by a custom patch which deals with the first two switches seperately. I'll look it up tomorrow and send you my fix. And where does the problem lie? In the board, firmata, or pduino? It suppose fermata since the wrong numbers arrive at pduino. Ingo _ Von: Pierre Massat [mailto:pimas...@gmail.com] Gesendet: Dienstag, 5. Juli 2011 20:41 An: Ingo Scherzinger Cc: Ingo Scherzinger Betreff: Re: [PD] Arduino (is drivin me mad Can we fix that?? Pierre 2011/7/5 Ingo Scherzinger i...@fixitinthemix.de I happens when switching from the first two switches to the others within a 8-bit block. Since the block has the wrong header it will ignore the on message and send the first off. So you have to press the button twice. Once pressed it works until you press another button within that block and return to the first one. Ingo Von: Pierre Massat [mailto:pimas...@gmail.com] Gesendet: Dienstag, 5. Juli 2011 19:56 An: Ingo Scherzinger Betreff: Re: [PD] Arduino (is drivin me mad Glad to know i'm not the only one with this problem! Sorry for starting a new thread. I have problems with inputs 8 and 9, or 9 and 10 (the first two on the second digital input socket). Pierre 2011/7/5 Ingo Scherzinger i...@miamiwave.com This is the same problem I had described several times before. There is an error in the 8-bit block where the digital ins 2+3 are coming in. It can be traced somewhere in the mapping section. I'll try to finally look it up tomorrow. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Pierre Massat Gesendet: Dienstag, 5. Juli 2011 19:36 An: pd-list Betreff: [PD] Arduino (is drivin me mad Hi All, I apologie if this is off-topic. Please let me know if you think it is. I have been working on my arduino-based pedal, and im faced with a peculiar problem right now. I'm using 8 digital inputs ( 6 on the first socket of the board, inputs 2 through 8, and 2 on the second digital socket, inputs 9 and 10). The first 6 inputs work perfectly, but when i want to use any of the last two inputs (9 and 10), i have to trigger them twice before they start working. Then i'm faced with the exact same problem when i get back to the first 6 inputs. I am pretty sure that i used the very same wiring for all 8 inputs. So... I thought that maybe this could be a problem with firmata or pduino (no offense, Hans!). I have been spending the last hour trying to write a simple program in the arduino software in order to print in serial monitor the values of my digital inputs. Now my question... Is the arduino software just really really bad? Or was it just not designed to work on an ubuntu machine? It is randomly very slow at start-up, it randomly disables the serial port menu in Tools, it randomly decides to prevent me from uploading the program in the board, or warns me that serial port dev/ttyACM0 is already in use, or can't be found. The fact that i unplug and replug the board, or change the usb port, or restart the software doesn't seem to make any difference. This is beginning to look more like witchcraft than computer science to me. Please help me, or i'll teach it how to fly out my window. Thank you. Pierre ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Arduino (is drivin me mad
Please tell me that all hope is not lost ... I looked it up and I found my fix. The errors are getting obvious here: Arduino / convert_to_symbolic_commands / digital messages / debyte If you replace debyte with this patch pd debyte it should work although I am not sure if pins higher than 9 were taken care of. If the bytes higher than 9 are still causing problems you might have to set the first moses to a higher number like 8 or so. I am not sure if it can interfere with anything else and I am also not sure if it works with boards other than Diecimila and Duemilanove. The problem is not debyte its the numbers coming in that just get fixed with this workaround! Ingo #N canvas 11 14 450 290 10; #N canvas 252 114 541 378 debyte 0; #X obj 32 161 1; #X obj 82 161 2; #X obj 162 345 outlet; #X obj 32 181 change; #X obj 82 181 change; #X obj 32 20 inlet; #X obj 264 181 change; #X obj 315 181 change; #X obj 366 181 change; #X obj 417 181 change; #X obj 162 181 change; #X obj 213 181 change; #X msg 32 221 0 \$1; #X msg 82 221 1 \$1; #X msg 162 221 2 \$1; #X msg 213 221 3 \$1; #X msg 264 221 4 \$1; #X msg 315 221 5 \$1; #X msg 366 221 6 \$1; #X msg 417 221 7 \$1; #X obj 162 308 unpack; #X obj 205 345 outlet; #X obj 162 161 4; #X obj 213 160 8; #X obj 264 161 16; #X obj 32 201 == 1; #X obj 82 201 == 2; #X obj 162 201 == 4; #X obj 213 201 == 8; #X obj 264 201 == 16; #X obj 315 201 == 32; #X obj 315 160 32; #X obj 366 201 == 64; #X obj 417 201 == 128; #X obj 366 161 64; #X obj 417 160 128; #X obj 32 41 moses 4; #X obj 162 104 trigger float float float float float float; #X obj 71 61 moses 253; #X connect 0 0 3 0; #X connect 1 0 4 0; #X connect 3 0 25 0; #X connect 4 0 26 0; #X connect 5 0 36 0; #X connect 6 0 29 0; #X connect 7 0 30 0; #X connect 8 0 32 0; #X connect 9 0 33 0; #X connect 10 0 27 0; #X connect 11 0 28 0; #X connect 12 0 20 0; #X connect 13 0 20 0; #X connect 14 0 20 0; #X connect 15 0 20 0; #X connect 16 0 20 0; #X connect 17 0 20 0; #X connect 18 0 20 0; #X connect 19 0 20 0; #X connect 20 0 2 0; #X connect 20 1 21 0; #X connect 22 0 10 0; #X connect 23 0 11 0; #X connect 24 0 6 0; #X connect 25 0 12 0; #X connect 26 0 13 0; #X connect 27 0 14 0; #X connect 28 0 15 0; #X connect 29 0 16 0; #X connect 30 0 17 0; #X connect 31 0 7 0; #X connect 32 0 18 0; #X connect 33 0 19 0; #X connect 34 0 8 0; #X connect 35 0 9 0; #X connect 36 0 0 0; #X connect 36 0 1 0; #X connect 36 1 38 0; #X connect 37 0 22 0; #X connect 37 1 23 0; #X connect 37 2 24 0; #X connect 37 3 31 0; #X connect 37 4 34 0; #X connect 37 5 35 0; #X connect 38 0 37 0; #X connect 38 1 0 0; #X connect 38 1 1 0; #X restore 168 99 pd debyte; Von: Pierre Massat [mailto:pimas...@gmail.com] Gesendet: Dienstag, 5. Juli 2011 22:23 An: Hans-Christoph Steiner Cc: Ingo; pd-list@iem.at Betreff: Re: [PD] Arduino (is drivin me mad You tried with your StandardFirmata, to no avail. Please tell me that all hope is not lost, doc... :Pierre 2011/7/5 Pierre Massat pimas...@gmail.com Should I try to upload a older firmata? :Pierre 2011/7/5 Hans-Christoph Steiner h...@at.or.at The Uno board was troublesome back when I first tried it, but that was a while ago. I didn't make that StandardFirmata_2_2_for_Uno_0_3 firmware, so I don't know what changes it has. Is anyone having these problems on boards older than an Uno? .hc On Jul 5, 2011, at 3:32 PM, Pierre Massat wrote: It makes no difference at all. Here's what happens : Inputs 2 through 7 work fine. Inputs 8 and 9 work fine. But if i use any of the inputs within the 2-7 group, and then use any input of the second group (8 and 9), i have to trigger the later twice before i can see something is happening. It goes like this : (in group 2 to 7) First guy : Pushed button 3. Second guy (Pd) : Ok, pushed button 3. First guy : Pushed button 7. Second guy : K, you pushed button 7. First guy : Pushed button 8. Second guy : Come again? First guy : PUSHED BUTTON 8! Second guy : Oh, yeah, button 8... First guy ; Pushed button 3. Second guy : I'm sorry, what button? First guy : BUTTON 3!! Second guy : Yep, button 3. I hope it is clear now what the problem is. Pierre 2011/7/5 Pierre Massat pimas...@gmail.com Ok, I checked in Windows XP, with a custom sketch, and all of my inputs work flawlessly. (The IDE seem to work much better in Windows than in Linux btw). So the problem has to be somewhere between firmata and pduino. I will try with the latest pduino... Thanks for your help! Pierre 2011/7/5 Hans-Christoph Steiner h...@at.or.at It would good to nail down the source of this and fix it. Which version of Firmata are you using? Which firmware? Also, there was a bug like that a while back that was fixed, so make sure you have the latest Pd patch too: http://at.or.at/hans/pd/objects.html#pduino .hc On Jul 5, 2011, at 2:49 PM, Ingo wrote: I fixed it by replacing the mapping object by a custom patch which deals with the first
Re: [PD] Arduino (is drivin me mad
It looks like I changed pin 8 and 9 to be output as pin 0 and 1 for some reason. You should change the two message boxes at the left from [0 $1( [1 $1( to [8 $1( [9 $1( to get the correct pin numbering. Ingo -Ursprüngliche Nachricht- Von: Ingo [mailto:i...@miamiwave.com] Gesendet: Mittwoch, 6. Juli 2011 05:46 An: 'Pierre Massat'; 'Hans-Christoph Steiner' Cc: 'Ingo'; pd-list@iem.at Betreff: AW: [PD] Arduino (is drivin me mad Please tell me that all hope is not lost ... I looked it up and I found my fix. The errors are getting obvious here: Arduino / convert_to_symbolic_commands / digital messages / debyte If you replace debyte with this patch pd debyte it should work although I am not sure if pins higher than 9 were taken care of. If the bytes higher than 9 are still causing problems you might have to set the first moses to a higher number like 8 or so. I am not sure if it can interfere with anything else and I am also not sure if it works with boards other than Diecimila and Duemilanove. The problem is not debyte its the numbers coming in that just get fixed with this workaround! Ingo #N canvas 11 14 450 290 10; #N canvas 252 114 541 378 debyte 0; #X obj 32 161 1; #X obj 82 161 2; #X obj 162 345 outlet; #X obj 32 181 change; #X obj 82 181 change; #X obj 32 20 inlet; #X obj 264 181 change; #X obj 315 181 change; #X obj 366 181 change; #X obj 417 181 change; #X obj 162 181 change; #X obj 213 181 change; #X msg 32 221 0 \$1; #X msg 82 221 1 \$1; #X msg 162 221 2 \$1; #X msg 213 221 3 \$1; #X msg 264 221 4 \$1; #X msg 315 221 5 \$1; #X msg 366 221 6 \$1; #X msg 417 221 7 \$1; #X obj 162 308 unpack; #X obj 205 345 outlet; #X obj 162 161 4; #X obj 213 160 8; #X obj 264 161 16; #X obj 32 201 == 1; #X obj 82 201 == 2; #X obj 162 201 == 4; #X obj 213 201 == 8; #X obj 264 201 == 16; #X obj 315 201 == 32; #X obj 315 160 32; #X obj 366 201 == 64; #X obj 417 201 == 128; #X obj 366 161 64; #X obj 417 160 128; #X obj 32 41 moses 4; #X obj 162 104 trigger float float float float float float; #X obj 71 61 moses 253; #X connect 0 0 3 0; #X connect 1 0 4 0; #X connect 3 0 25 0; #X connect 4 0 26 0; #X connect 5 0 36 0; #X connect 6 0 29 0; #X connect 7 0 30 0; #X connect 8 0 32 0; #X connect 9 0 33 0; #X connect 10 0 27 0; #X connect 11 0 28 0; #X connect 12 0 20 0; #X connect 13 0 20 0; #X connect 14 0 20 0; #X connect 15 0 20 0; #X connect 16 0 20 0; #X connect 17 0 20 0; #X connect 18 0 20 0; #X connect 19 0 20 0; #X connect 20 0 2 0; #X connect 20 1 21 0; #X connect 22 0 10 0; #X connect 23 0 11 0; #X connect 24 0 6 0; #X connect 25 0 12 0; #X connect 26 0 13 0; #X connect 27 0 14 0; #X connect 28 0 15 0; #X connect 29 0 16 0; #X connect 30 0 17 0; #X connect 31 0 7 0; #X connect 32 0 18 0; #X connect 33 0 19 0; #X connect 34 0 8 0; #X connect 35 0 9 0; #X connect 36 0 0 0; #X connect 36 0 1 0; #X connect 36 1 38 0; #X connect 37 0 22 0; #X connect 37 1 23 0; #X connect 37 2 24 0; #X connect 37 3 31 0; #X connect 37 4 34 0; #X connect 37 5 35 0; #X connect 38 0 37 0; #X connect 38 1 0 0; #X connect 38 1 1 0; #X restore 168 99 pd debyte; Von: Pierre Massat [mailto:pimas...@gmail.com] Gesendet: Dienstag, 5. Juli 2011 22:23 An: Hans-Christoph Steiner Cc: Ingo; pd-list@iem.at Betreff: Re: [PD] Arduino (is drivin me mad You tried with your StandardFirmata, to no avail. Please tell me that all hope is not lost, doc... :Pierre 2011/7/5 Pierre Massat pimas...@gmail.com Should I try to upload a older firmata? :Pierre 2011/7/5 Hans-Christoph Steiner h...@at.or.at The Uno board was troublesome back when I first tried it, but that was a while ago. I didn't make that StandardFirmata_2_2_for_Uno_0_3 firmware, so I don't know what changes it has. Is anyone having these problems on boards older than an Uno? .hc On Jul 5, 2011, at 3:32 PM, Pierre Massat wrote: It makes no difference at all. Here's what happens : Inputs 2 through 7 work fine. Inputs 8 and 9 work fine. But if i use any of the inputs within the 2-7 group, and then use any input of the second group (8 and 9), i have to trigger the later twice before i can see something is happening. It goes like this : (in group 2 to 7) First guy : Pushed button 3. Second guy (Pd) : Ok, pushed button 3. First guy : Pushed button 7. Second guy : K, you pushed button 7. First guy : Pushed button 8. Second guy : Come again? First guy : PUSHED BUTTON 8! Second guy : Oh, yeah, button 8... First guy ; Pushed button 3. Second guy : I'm sorry, what button? First guy : BUTTON 3!! Second guy : Yep, button 3. I hope it is clear now what the problem is. Pierre 2011/7/5 Pierre Massat pimas...@gmail.com Ok, I checked in Windows XP, with a custom sketch, and all of my inputs work flawlessly. (The IDE seem to work
Re: [PD] Arduino (is drivin me mad
I assume that the error might be somehow caused by the fact that the digital pins are not offset by two as it should be the case since pin 0 1 ought to be handled separately from the rest of the digital ins. BTW the debyte patch should replace [mapping/debytemask] plus the following message boxes and the [unpack float float] object. Ingo It looks like I changed pin 8 and 9 to be output as pin 0 and 1 for some reason. You should change the two message boxes at the left from [0 $1( [1 $1( to [8 $1( [9 $1( to get the correct pin numbering. Ingo -Ursprüngliche Nachricht- Von: Ingo [mailto:i...@miamiwave.com] Gesendet: Mittwoch, 6. Juli 2011 05:46 An: 'Pierre Massat'; 'Hans-Christoph Steiner' Cc: 'Ingo'; pd-list@iem.at Betreff: AW: [PD] Arduino (is drivin me mad Please tell me that all hope is not lost ... I looked it up and I found my fix. The errors are getting obvious here: Arduino / convert_to_symbolic_commands / digital messages / debyte If you replace debyte with this patch pd debyte it should work although I am not sure if pins higher than 9 were taken care of. If the bytes higher than 9 are still causing problems you might have to set the first moses to a higher number like 8 or so. I am not sure if it can interfere with anything else and I am also not sure if it works with boards other than Diecimila and Duemilanove. The problem is not debyte its the numbers coming in that just get fixed with this workaround! Ingo #N canvas 11 14 450 290 10; #N canvas 252 114 541 378 debyte 0; #X obj 32 161 1; #X obj 82 161 2; #X obj 162 345 outlet; #X obj 32 181 change; #X obj 82 181 change; #X obj 32 20 inlet; #X obj 264 181 change; #X obj 315 181 change; #X obj 366 181 change; #X obj 417 181 change; #X obj 162 181 change; #X obj 213 181 change; #X msg 32 221 0 \$1; #X msg 82 221 1 \$1; #X msg 162 221 2 \$1; #X msg 213 221 3 \$1; #X msg 264 221 4 \$1; #X msg 315 221 5 \$1; #X msg 366 221 6 \$1; #X msg 417 221 7 \$1; #X obj 162 308 unpack; #X obj 205 345 outlet; #X obj 162 161 4; #X obj 213 160 8; #X obj 264 161 16; #X obj 32 201 == 1; #X obj 82 201 == 2; #X obj 162 201 == 4; #X obj 213 201 == 8; #X obj 264 201 == 16; #X obj 315 201 == 32; #X obj 315 160 32; #X obj 366 201 == 64; #X obj 417 201 == 128; #X obj 366 161 64; #X obj 417 160 128; #X obj 32 41 moses 4; #X obj 162 104 trigger float float float float float float; #X obj 71 61 moses 253; #X connect 0 0 3 0; #X connect 1 0 4 0; #X connect 3 0 25 0; #X connect 4 0 26 0; #X connect 5 0 36 0; #X connect 6 0 29 0; #X connect 7 0 30 0; #X connect 8 0 32 0; #X connect 9 0 33 0; #X connect 10 0 27 0; #X connect 11 0 28 0; #X connect 12 0 20 0; #X connect 13 0 20 0; #X connect 14 0 20 0; #X connect 15 0 20 0; #X connect 16 0 20 0; #X connect 17 0 20 0; #X connect 18 0 20 0; #X connect 19 0 20 0; #X connect 20 0 2 0; #X connect 20 1 21 0; #X connect 22 0 10 0; #X connect 23 0 11 0; #X connect 24 0 6 0; #X connect 25 0 12 0; #X connect 26 0 13 0; #X connect 27 0 14 0; #X connect 28 0 15 0; #X connect 29 0 16 0; #X connect 30 0 17 0; #X connect 31 0 7 0; #X connect 32 0 18 0; #X connect 33 0 19 0; #X connect 34 0 8 0; #X connect 35 0 9 0; #X connect 36 0 0 0; #X connect 36 0 1 0; #X connect 36 1 38 0; #X connect 37 0 22 0; #X connect 37 1 23 0; #X connect 37 2 24 0; #X connect 37 3 31 0; #X connect 37 4 34 0; #X connect 37 5 35 0; #X connect 38 0 37 0; #X connect 38 1 0 0; #X connect 38 1 1 0; #X restore 168 99 pd debyte; Von: Pierre Massat [mailto:pimas...@gmail.com] Gesendet: Dienstag, 5. Juli 2011 22:23 An: Hans-Christoph Steiner Cc: Ingo; pd-list@iem.at Betreff: Re: [PD] Arduino (is drivin me mad You tried with your StandardFirmata, to no avail. Please tell me that all hope is not lost, doc... :Pierre 2011/7/5 Pierre Massat pimas...@gmail.com Should I try to upload a older firmata? :Pierre 2011/7/5 Hans-Christoph Steiner h...@at.or.at The Uno board was troublesome back when I first tried it, but that was a while ago. I didn't make that StandardFirmata_2_2_for_Uno_0_3 firmware, so I don't know what changes it has. Is anyone having these problems on boards older than an Uno? .hc On Jul 5, 2011, at 3:32 PM, Pierre Massat wrote: It makes no difference at all. Here's what happens : Inputs 2 through 7 work fine. Inputs 8 and 9 work fine. But if i use any of the inputs within the 2-7 group, and then use any input of the second group (8 and 9), i have to trigger the later twice before i can see something is happening. It goes like this : (in group 2 to 7) First guy : Pushed button 3. Second guy (Pd) : Ok, pushed button 3. First guy : Pushed button
Re: [PD] Arduino (is drivin me mad
It should be here: [arduino] / [pd convert_to_symbolic_commands] / [pd digital messages] / [mapping/debytemask] I was using the Pduino-0.5beta8 arduino-test.pd Ingo Von: Pierre Massat [mailto:pimas...@gmail.com] Gesendet: Mittwoch, 6. Juli 2011 19:01 An: Ingo Cc: Hans-Christoph Steiner; pd-list@iem.at Betreff: Re: [PD] Arduino (is drivin me mad Thank you Ingo. Unfortunately I can't even locate the mapping/debytemask object to be replaced... Pierre 2011/7/6 Ingo i...@miamiwave.com I assume that the error might be somehow caused by the fact that the digital pins are not offset by two as it should be the case since pin 0 1 ought to be handled separately from the rest of the digital ins. BTW the debyte patch should replace [mapping/debytemask] plus the following message boxes and the [unpack float float] object. Ingo It looks like I changed pin 8 and 9 to be output as pin 0 and 1 for some reason. You should change the two message boxes at the left from [0 $1( [1 $1( to [8 $1( [9 $1( to get the correct pin numbering. Ingo -Ursprüngliche Nachricht- Von: Ingo [mailto:i...@miamiwave.com] Gesendet: Mittwoch, 6. Juli 2011 05:46 An: 'Pierre Massat'; 'Hans-Christoph Steiner' Cc: 'Ingo'; pd-list@iem.at Betreff: AW: [PD] Arduino (is drivin me mad Please tell me that all hope is not lost ... I looked it up and I found my fix. The errors are getting obvious here: Arduino / convert_to_symbolic_commands / digital messages / debyte If you replace debyte with this patch pd debyte it should work although I am not sure if pins higher than 9 were taken care of. If the bytes higher than 9 are still causing problems you might have to set the first moses to a higher number like 8 or so. I am not sure if it can interfere with anything else and I am also not sure if it works with boards other than Diecimila and Duemilanove. The problem is not debyte its the numbers coming in that just get fixed with this workaround! Ingo #N canvas 11 14 450 290 10; #N canvas 252 114 541 378 debyte 0; #X obj 32 161 1; #X obj 82 161 2; #X obj 162 345 outlet; #X obj 32 181 change; #X obj 82 181 change; #X obj 32 20 inlet; #X obj 264 181 change; #X obj 315 181 change; #X obj 366 181 change; #X obj 417 181 change; #X obj 162 181 change; #X obj 213 181 change; #X msg 32 221 0 \$1; #X msg 82 221 1 \$1; #X msg 162 221 2 \$1; #X msg 213 221 3 \$1; #X msg 264 221 4 \$1; #X msg 315 221 5 \$1; #X msg 366 221 6 \$1; #X msg 417 221 7 \$1; #X obj 162 308 unpack; #X obj 205 345 outlet; #X obj 162 161 4; #X obj 213 160 8; #X obj 264 161 16; #X obj 32 201 == 1; #X obj 82 201 == 2; #X obj 162 201 == 4; #X obj 213 201 == 8; #X obj 264 201 == 16; #X obj 315 201 == 32; #X obj 315 160 32; #X obj 366 201 == 64; #X obj 417 201 == 128; #X obj 366 161 64; #X obj 417 160 128; #X obj 32 41 moses 4; #X obj 162 104 trigger float float float float float float; #X obj 71 61 moses 253; #X connect 0 0 3 0; #X connect 1 0 4 0; #X connect 3 0 25 0; #X connect 4 0 26 0; #X connect 5 0 36 0; #X connect 6 0 29 0; #X connect 7 0 30 0; #X connect 8 0 32 0; #X connect 9 0 33 0; #X connect 10 0 27 0; #X connect 11 0 28 0; #X connect 12 0 20 0; #X connect 13 0 20 0; #X connect 14 0 20 0; #X connect 15 0 20 0; #X connect 16 0 20 0; #X connect 17 0 20 0; #X connect 18 0 20 0; #X connect 19 0 20 0; #X connect 20 0 2 0; #X connect 20 1 21 0; #X connect 22 0 10 0; #X connect 23 0 11 0; #X connect 24 0 6 0; #X connect 25 0 12 0; #X connect 26 0 13 0; #X connect 27 0 14 0; #X connect 28 0 15 0; #X connect 29 0 16 0; #X connect 30 0 17 0; #X connect 31 0 7 0; #X connect 32 0 18 0; #X connect 33 0 19 0; #X connect 34 0 8 0; #X connect 35 0 9 0; #X connect 36 0 0 0; #X connect 36 0 1 0; #X connect 36 1 38 0; #X connect 37 0 22 0; #X connect 37 1 23 0; #X connect 37 2 24 0; #X connect 37 3 31 0; #X connect 37 4 34 0; #X connect 37 5 35 0; #X connect 38 0 37 0; #X connect 38 1 0 0; #X connect 38 1 1 0; #X restore 168 99 pd debyte; Von: Pierre Massat [mailto:pimas...@gmail.com] Gesendet: Dienstag, 5. Juli 2011 22:23 An: Hans-Christoph Steiner Cc: Ingo; pd-list@iem.at Betreff: Re: [PD] Arduino (is drivin me mad You tried with your StandardFirmata, to no avail. Please tell me that all hope is not lost, doc... :Pierre 2011/7/5 Pierre Massat pimas...@gmail.com Should I try to upload a older firmata? :Pierre 2011/7/5 Hans-Christoph Steiner h...@at.or.at The Uno board was troublesome back when I first tried it, but that was a while ago. I didn't make that StandardFirmata_2_2_for_Uno_0_3 firmware, so I don't know what changes it has. Is anyone having these problems on boards older than
Re: [PD] Arduino (is drivin me mad
Sorry Pierre! Im surprised that it didnt work. It's surely working here. But then again you might have the arduino set up differently than I do and something else might interfere with the (replaced) numbers. Try to check out how the numbers change before they go into the [mapping/debytemask] by sending them to [print]. They shouldn't produce lists that start with 0 or 1 or 2 or 3 as far as I recall. Ingo Von: Pierre Massat [mailto:pimas...@gmail.com] Gesendet: Mittwoch, 6. Juli 2011 20:48 An: Ingo Cc: Hans-Christoph Steiner; pd-list@iem.at Betreff: Re: [PD] Arduino (is drivin me mad Ok, i replaced mapping/debytemask and the rest as you suggested, but it didn't work. Then i replaced 0 and 1 in the debyte object by 8 and 9, to no avail. I'm afraid I can't find a fix alone, as i have no idea what the incoming data from the board looks like. Anyway, thanks for helping me. Pierre 2011/7/6 Ingo i...@miamiwave.com It should be here: [arduino] / [pd convert_to_symbolic_commands] / [pd digital messages] / [mapping/debytemask] I was using the Pduino-0.5beta8 arduino-test.pd Ingo Von: Pierre Massat [mailto:pimas...@gmail.com] Gesendet: Mittwoch, 6. Juli 2011 19:01 An: Ingo Cc: Hans-Christoph Steiner; pd-list@iem.at Betreff: Re: [PD] Arduino (is drivin me mad Thank you Ingo. Unfortunately I can't even locate the mapping/debytemask object to be replaced... Pierre 2011/7/6 Ingo i...@miamiwave.com I assume that the error might be somehow caused by the fact that the digital pins are not offset by two as it should be the case since pin 0 1 ought to be handled separately from the rest of the digital ins. BTW the debyte patch should replace [mapping/debytemask] plus the following message boxes and the [unpack float float] object. Ingo It looks like I changed pin 8 and 9 to be output as pin 0 and 1 for some reason. You should change the two message boxes at the left from [0 $1( [1 $1( to [8 $1( [9 $1( to get the correct pin numbering. Ingo -Ursprüngliche Nachricht- Von: Ingo [mailto:i...@miamiwave.com] Gesendet: Mittwoch, 6. Juli 2011 05:46 An: 'Pierre Massat'; 'Hans-Christoph Steiner' Cc: 'Ingo'; pd-list@iem.at Betreff: AW: [PD] Arduino (is drivin me mad Please tell me that all hope is not lost ... I looked it up and I found my fix. The errors are getting obvious here: Arduino / convert_to_symbolic_commands / digital messages / debyte If you replace debyte with this patch pd debyte it should work although I am not sure if pins higher than 9 were taken care of. If the bytes higher than 9 are still causing problems you might have to set the first moses to a higher number like 8 or so. I am not sure if it can interfere with anything else and I am also not sure if it works with boards other than Diecimila and Duemilanove. The problem is not debyte its the numbers coming in that just get fixed with this workaround! Ingo #N canvas 11 14 450 290 10; #N canvas 252 114 541 378 debyte 0; #X obj 32 161 1; #X obj 82 161 2; #X obj 162 345 outlet; #X obj 32 181 change; #X obj 82 181 change; #X obj 32 20 inlet; #X obj 264 181 change; #X obj 315 181 change; #X obj 366 181 change; #X obj 417 181 change; #X obj 162 181 change; #X obj 213 181 change; #X msg 32 221 0 \$1; #X msg 82 221 1 \$1; #X msg 162 221 2 \$1; #X msg 213 221 3 \$1; #X msg 264 221 4 \$1; #X msg 315 221 5 \$1; #X msg 366 221 6 \$1; #X msg 417 221 7 \$1; #X obj 162 308 unpack; #X obj 205 345 outlet; #X obj 162 161 4; #X obj 213 160 8; #X obj 264 161 16; #X obj 32 201 == 1; #X obj 82 201 == 2; #X obj 162 201 == 4; #X obj 213 201 == 8; #X obj 264 201 == 16; #X obj 315 201 == 32; #X obj 315 160 32; #X obj 366 201 == 64; #X obj 417 201 == 128; #X obj 366 161 64; #X obj 417 160 128; #X obj 32 41 moses 4; #X obj 162 104 trigger float float float float float float; #X obj 71 61 moses 253; #X connect 0 0 3 0; #X connect 1 0 4 0; #X connect 3 0 25 0; #X connect 4 0 26 0; #X connect 5 0 36 0; #X connect 6 0 29 0; #X connect 7 0 30 0; #X connect 8 0 32 0; #X connect 9 0 33 0; #X connect 10 0 27 0; #X connect 11 0 28 0; #X connect 12 0 20 0; #X connect 13 0 20 0; #X connect 14 0 20 0; #X connect 15 0 20 0; #X connect 16 0 20 0; #X connect 17 0 20 0; #X connect 18 0 20 0; #X connect 19 0 20 0; #X connect 20 0 2 0; #X connect 20 1 21 0; #X connect 22 0 10 0; #X connect 23 0 11 0; #X connect 24 0 6 0; #X connect 25 0 12 0; #X connect 26 0 13 0; #X connect 27 0 14 0; #X connect 28 0 15 0; #X connect 29 0 16 0; #X connect 30 0 17 0; #X connect 31 0 7 0; #X connect 32 0 18 0; #X connect 33 0 19 0; #X connect 34 0 8 0; #X connect 35 0 9 0; #X connect 36 0 0 0; #X connect 36 0 1 0; #X connect 36 1 38 0; #X connect 37 0 22 0; #X
Re: [PD] Comport can't read serial devices when soundcard is plugged in
Similar problem here. I had an Arduino (USB) and a LCD display (RS232) working together very well with two [comport] objects on my old mainboard. With the new board either one by themselves is working fine but both of them connected bidirectional doesn't work. As soon as I connect the serial in from the display (which is supposed to get the keypad of the serial display) I get a lots of crazy data coming in. After a while either [comport] or Pd altogether crashes. The LCD [comport] should only receive digital buttons on/off. While the arduino sends buttons plus four analogue INs from a joystick and two foot pedals. All cables are very short, so the problematic behaviour can't be caused by the cable length. Without connecting the serial out of the display to the serial in of the computer everything works fine. I was also suspecting an error in comport where the data of two instances of two [comport] objects get mixed up. It looks like the analogue data from the arduino board gets forwarded to the second RS232 [comport] of the LCD. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Pierre Massat Gesendet: Samstag, 9. Juli 2011 13:38 An: pd-list Betreff: [PD] Comport can't read serial devices when soundcard is plugged in Hi all! After having had to deal with a bug in pduino (see Arduin is drivin me mad), i wrote a small sketch for the board and a patch using comport. It was working fine until i decided to actually try it with my audio patch. It turns out that my external USB soundcard prevents comport from working properly. It can't open the arduino board, and can't event detect serial devices (devices yields an empty message in the console). As soon as i unplug the soundcard, everything works fine again. I think i'm beginning to realize that a lot of things have to be taken care off, and i know that my patch and sketch are way to simple to take this kind of issue into account (i wish i could switch back to Pduino and firmata). So my question is : is this behaviour normal, or is it bug in comport? Thanks! Pierre ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] problems compiling pd-extended 0.42.5 on natty 64-bit
Hi everybody, I was trying to install pd-extended 0.42.5 from source on a 64-bit Natty machine. I was logged in as root. The unpacked pd-extended archive folder was either at / or /root/. Before starting I did apt-get build-dep puredata gem pd-pdp. But at the end of ./configure prefix=/usr I get this: config.status: creating makefile config.status: WARNING: makefile.in seems to ignore the --datarootdir settings make install seems to be working. Pd-extended itself is running but none of the libraries are installed! I checked the externals/Makefile. The libraries are there! I also tried an alternative way that I found somewhere after searching: aclocal autoconf ./configure make make install This doesn't make any difference. Does anybody have an idea how to fix this? I have not installed pd from source before - so I must be missing something. Thank you Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to tell poly object release time?
You could set a delay to the note offs only that are going into the poly object. Set the delay time to the release time of the envelope. On pd-extended I would do it like this: [notein] | | [pack f f] | (off)[nroute 0 2] (noteon) |\ / \ [mrpeach/pipelist] | \ / \ / \ / \ / [unpack] | | [poly] Problems can occur if the same note is repeating faster than the release time, though. That would require some special treating! For example sending a not off with the same note number to [poly] right before each note on. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ludwig Maes Gesendet: Donnerstag, 11. August 2011 15:21 An: Pd List Betreff: [PD] how to tell poly object release time? to make the poly object more compatible with the ADSR philosophy, it would be nice if you could tell poly the release time (after note-offs) to keep a voice free if its possible. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] problems compiling pd-extended 0.42.5 on natty 64-bit
Thanks a lot Hans! The package version was working a lot better. Unfortunately several external libraries are missing or did not get compiled correctly. This might be a 64-bit problem. After several weeks of trying to get a reliable working 64-bit system together I finally gave up and went back to 32-bit. It simply runs a lot smoother. Thanks anyway! Ingo -Ursprüngliche Nachricht- Von: Hans-Christoph Steiner [mailto:h...@at.or.at] Gesendet: Donnerstag, 11. August 2011 17:55 An: Ingo Cc: 'pd-list' Betreff: Re: [PD] problems compiling pd-extended 0.42.5 on natty 64-bit On Aug 11, 2011, at 7:50 AM, Ingo wrote: Hi everybody, I was trying to install pd-extended 0.42.5 from source on a 64-bit Natty machine. I was logged in as root. The unpacked pd-extended archive folder was either at / or /root/. Before starting I did apt-get build-dep puredata gem pd-pdp. But at the end of ./configure prefix=/usr I get this: config.status: creating makefile config.status: WARNING: makefile.in seems to ignore the --datarootdir settings make install seems to be working. Pd-extended itself is running but none of the libraries are installed! I checked the externals/Makefile. The libraries are there! I also tried an alternative way that I found somewhere after searching: aclocal autoconf ./configure make make install This doesn't make any difference. Does anybody have an idea how to fix this? I have not installed pd from source before - so I must be missing something. Thank you Ingo In packages/linux, run: make install make package Then you'll have a Pd-extended.deb to install, and that will include everything. .hc -- -- If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] natty alsamidi - only one midi in
Hi, ever since I've changed from lucid to natty the default midi is not working anymore. Now I tried to switch to alsamidi but I get only one midi in/out. I checked my lucid system and it's the same with alsamidi. As soon as I assign more than 1 input there is no midi in at all anymore. Any idea? Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] natty 32-bit alsamidi - only one midi in
ever since I've changed from lucid to natty the default midi is not working anymore. Now I tried to switch to alsamidi but I get only one midi in/out. I checked my lucid system and it's the same with alsamidi. As soon as I assign more than 1 input there is no midi in at all anymore. Any idea? Or let's put it in another way: How could I get oss to work in natty 32-bit? I have already installed alsa-oss, alsa-base and alsa-utils on top of the ubuntu-studio command line install and the puredata dependencies. Neither default midi is working nor oss audio. Nothing shows up in the dropdown menus although in /proc/asound/cards the soundcard and midiports show up. The entries in /etc/modprobe.d/alsabase.conf are the same as in the working lucid system. Any help is appreciated! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] control alsamixer from pd?
I am using this when I start up Pd: [loadbang] | [alsactl -f /var/lib/alsa/asound.state restore SB( | [shell] First you need to store the mixer settings with this of course: [alsactl -f /var/lib/alsa/asound.state store SB( | [shell] SB at the end is the name of the onboard Realtek sound card. You might have to change that according to the name in /proc/asound/cards or leave it blank if it works. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von IOhannes m zmoelnig Gesendet: Montag, 22. August 2011 17:24 An: pd-list@iem.at Betreff: Re: [PD] control alsamixer from pd? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-08-22 16:25, tim vets wrote: Hi,when I'm using my internal soundcard, each time I boot, the input setting is too low, forcing me each time to raise it manually in alsamixer. I tried alsactl store, but that didn't work. Is there a way to access this setting from pd, so that it can be set automatically when loading a patch? i once wrote an [amixer] external (to be found in svn:///externals/iem/amixer) that would allow to do those things. i'm not sure however, whether it is in a useable state (mainly i think because alsactl store/restore usually do work :-) fgmard IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ http://enigmail.mozdev.org/ iEYEARECAAYFAk5SdJsACgkQkX2Xpv6ydvSuxACguwko+4aY0NxYSIWApveEvEeV JvEAoN0OJnVwLSIIkx8+hP0WKOMI3unB =/rEI -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] selecting an alsa soundcard at startup
Has anybody had any success with udev? I need to use oss and have tried to create a udev.rule to connect two identical usb midi interfaces and identify them by the usb port. I ended up creating the devices in /dev/ and /dev/snd/ and named them /dev/midi1, /dev/midi2 and/or /dev/snd/midiC1D0, /dev/snd/C2D0. They show up correctly in the folder /dev/ but I don't know how to assign them to anything alsa-base.conf can use. The first one that gets plugged in is always midi1 no matter where I plug it in. If I plug only one of them into the second usb port it will create midi1 and midi2. alsa-base.conf cannot seem to use the udev rules. It looks like something is assigning the soundcard numbers before or after udev. Any ideas? Ingo http://alsa.opensrc.org/MultipleCards should give you a few clues, and there's probably some advice elsewhere specific to your distro. On 3 September 2011 21:33, tim vets timv...@gmail.com wrote: How do I have pd select the correct sound card, regardless of what device numbering it gets from alsa? The problem is now that for some reason, the device listing of my sound cards and midi devices keeps changing quite often. After a reboot, it is often the case that pd tries to connect to the wrong alsa device, and I have to select it manually again. Anyone know a good trick to cope with this? Thanks Tim ___ 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
Re: [PD] selecting an alsa soundcard at startup
That's what I was thinking, too. But it doesn't work like this. The devices I create with udev show up in /dev. But the devices used by /etc/modprobe.d/alsa-base.conf : snd-emu10k1 snd_intel8x0 do not show up in /dev. That means the sound device names are created somewhere else. Names that I create with udev in /dev seem to be ignored by modprobe.d/alsa-base.conf. So the question is where are these sound card IDs generated and how could I create such an ID with udev? Ingo On Sun, Sep 4, 2011 at 14:33, Ingo i...@miamiwave.com wrote: Has anybody had any success with udev? I need to use oss and have tried to create a udev.rule to connect two identical usb midi interfaces and identify them by the usb port. I ended up creating the devices in /dev/ and /dev/snd/ and named them /dev/midi1, /dev/midi2 and/or /dev/snd/midiC1D0, /dev/snd/C2D0. They show up correctly in the folder /dev/ but I don't know how to assign them to anything alsa-base.conf can use. The first one that gets plugged in is always midi1 no matter where I plug it in. If I plug only one of them into the second usb port it will create midi1 and midi2. alsa-base.conf cannot seem to use the udev rules. It looks like something is assigning the soundcard numbers before or after udev. Any ideas? Ingo More than udev it might be a modprobe thing. I have these rules in /etc/modprobe.d/alsa-base.conf : options snd-emu10k1 index=0 options snd_intel8x0 index=1 ...which make my Soundblaster card always be hw:0 and the motherboard sound card be hw:1. Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
I could not open any patch at all! Neither Natty nor Windows XP worked. I am still on Pd-extended 0.42.5. There is a huge list of stuff (not pd library related) missing. So far this doesn't look like it's improving any dependency problem. Ingo buenas tutti roman me did some rewrite on the pduino - citing the README: Pduino - improved - All Pd patches are based on the official Pduino (version 0.5beta8) maintained by Hans-Christoph Steiner. The goals of the improvements are: * Get rid of avoidable dependencies on other external/abstraction libraries * Update help- and test-patches in accordance to current Firmata * Create 'intuitive' and easy-to-understand GOP abstraction Dependencies: * comport * pdstring library from moocow you'll find the patches here: https://github.com/reduzent/pduino the GOP-abstraction is still in tango alpha state aka not useable at all. so basically arduino.pd arduino-help.pd should be of interest. as they went thru some changes - most important the dependencies are reduce to the minimum. check it out report ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
OK, I got it! Downloading the files didn't work (at least not on my Windows computer) but copying the content into a bunch of text files and renaming them did. I'll take a look at it later to see if the problems with the 1st and 2nd digital input as well as my problems with inputs 10 - 13 are gone. Ingo Betreff: Re: [PD] pduino rewrite I could not open any patch at all! Neither Natty nor Windows XP worked. I am still on Pd-extended 0.42.5. There is a huge list of stuff (not pd library related) missing. So far this doesn't look like it's improving any dependency problem. Ingo buenas tutti roman me did some rewrite on the pduino - citing the README: Pduino - improved - All Pd patches are based on the official Pduino (version 0.5beta8) maintained by Hans-Christoph Steiner. The goals of the improvements are: * Get rid of avoidable dependencies on other external/abstraction libraries * Update help- and test-patches in accordance to current Firmata * Create 'intuitive' and easy-to-understand GOP abstraction Dependencies: * comport * pdstring library from moocow you'll find the patches here: https://github.com/reduzent/pduino the GOP-abstraction is still in tango alpha state aka not useable at all. so basically arduino.pd arduino-help.pd should be of interest. as they went thru some changes - most important the dependencies are reduce to the minimum. check it out report ___ 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
Re: [PD] pduino rewrite
Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Ingo Hi Ingo On Fri, 2011-09-09 at 05:47 +0200, Ingo wrote: OK, I got it! Downloading the files didn't work (at least not on my Windows computer) but copying the content into a bunch of text files and renaming them did. Hm.. is this probably due to Windows and Linux using different line breaks (\r\n vs. \n)? I'll take a look at it later to see if the problems with the 1st and 2nd digital input as well as my problems with inputs 10 - 13 are gone. FYI: We haven't tinkered with the protocol. At this stage it's really only a version with some externals kicked out. Anyway, please report back, if you still experience the same problems. Are you testing on a Arduino Mega? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
I forgot to mention: I tested with a Duemilanove. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ingo Gesendet: Freitag, 9. September 2011 10:04 An: 'Roman Haefeli'; 'olsen'; 'pd-list' Betreff: Re: [PD] pduino rewrite Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Ingo Hi Ingo On Fri, 2011-09-09 at 05:47 +0200, Ingo wrote: OK, I got it! Downloading the files didn't work (at least not on my Windows computer) but copying the content into a bunch of text files and renaming them did. Hm.. is this probably due to Windows and Linux using different line breaks (\r\n vs. \n)? I'll take a look at it later to see if the problems with the 1st and 2nd digital input as well as my problems with inputs 10 - 13 are gone. FYI: We haven't tinkered with the protocol. At this stage it's really only a version with some externals kicked out. Anyway, please report back, if you still experience the same problems. Are you testing on a Arduino Mega? Roman ___ 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
Re: [PD] pduino rewrite
I did test it with the Duemilanove. But I also tested Diecimila and Uno. To me the problem looks like unfortunate design in the firmata. The buttons 2-9 don't somehow connect the same 8-bit word. It might simply be a bug in the firmata. Hans hasn't reacted to it the last 2 or 3 times I mentioned it. I have changed my arduino patch to get it to work for what I need with the Diecimila to Uno. I don't like to submit any workarounds if I don't have a mega available. I don't know how the rest of the pins are set up in blocks. It might also break something else since I only use part of the functions. I really think Hans is the one who should look into this problem to determine whether it is a pduino or firmata bug. I am really surprised that so few people have problems with this. Or maybe they do and simply cannot figure out where the problem comes from? Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 9. September 2011 10:49 An: Ingo Cc: 'olsen'; 'pd-list' Betreff: Re: AW: [PD] pduino rewrite On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote: Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Yo, it's very much a work in progress and yet the main goal was not loose any functionality by getting rid of the externals. I did not address any bugs yet, because I didn't experience any. I only have a arduino Diecimila to test here. So, I ask you again: The problem you mentioned with pin 2 and 3, on which arduino board model do you experience it? Also, if the problem is located in the firmware and not in the [arduino] abstraction, I rather don't 'fix' it in the [arduino] abstraction. Since you seem to have a strong interest on making it work for your situation, I suggest to give you commit privileges to that repository. You could send me your public key off-list and I would give you access to that repository. Also, thanks for your other comments. Those are all valid points that need to be addressed. (Actually, 'pduino rewrite' as thread was a bit too much a promise, it should have read 'please test and report back'.) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Upon further testing I have found two bugs so far. On is in the firmata and the second one is in the [debytemask]. This makes fixing it a bit difficult. 1) firmata: instead of sending two values for a digital pin connected or disconnected it sends three. The first one should be the address and the second one the value for the group of 8 pins. There may be a reason why it sends another 0 at the end but that's not too important anyway. The bad thing is that when disconnecting a pin it sends these number five times (sometimes only three times) in a row while going back and forth between the last value and the current one. That's 15 bytes instead of two. (I am using an inc/dec wheel with the arduino and now I know why it doesn't respond like it should.) I havn't checked the analogue ins so far. 2) [debytemask]: there is only one debytemask for all addresses. This means - since there is a [change] object inside - there will be a wrong value when the same button of a different group of pins is pressed or released twice after each other. This could be still correct if all other pins of the group have identical values but creates random numbers if the other pins change. Not sure yet what else gets affected. I am going to try to fix the problem with the [debytemask] but I don't know if the firmata stuff has any big influence on it. I just added another 6 buttons to my remote (using all 12 digital and 6 analogue ins of the Diecimila / Duemilanove now) and the whole thing is going crazy now sending wrong stuff all over the place. Ingo -Ursprüngliche Nachricht- Von: Hans-Christoph Steiner [mailto:h...@at.or.at] Gesendet: Freitag, 9. September 2011 16:41 An: Ingo Cc: 'Roman Haefeli'; 'pd-list' Betreff: Re: [PD] pduino rewrite I basically haven't used an Arduino in 2 years, so I am a poor candidate for debugging this stuff. Roman and Olsen are much better candidates for this job. The digital input pins are reported using the hardware-level ports, the hardware is organized around pins 0-7 being one port, 8-15, another, and 16-23 (analog pins) another. As for the pull-up resistor, you activate them just like you would in an other code for an Atmel AVR chip: switch the pin mode to INPUT then set that pin to HIGH (i.e. output a 1 to that pin). .hc On Fri, 2011-09-09 at 11:34 +0200, Ingo wrote: I did test it with the Duemilanove. But I also tested Diecimila and Uno. To me the problem looks like unfortunate design in the firmata. The buttons 2-9 don't somehow connect the same 8-bit word. It might simply be a bug in the firmata. Hans hasn't reacted to it the last 2 or 3 times I mentioned it. I have changed my arduino patch to get it to work for what I need with the Diecimila to Uno. I don't like to submit any workarounds if I don't have a mega available. I don't know how the rest of the pins are set up in blocks. It might also break something else since I only use part of the functions. I really think Hans is the one who should look into this problem to determine whether it is a pduino or firmata bug. I am really surprised that so few people have problems with this. Or maybe they do and simply cannot figure out where the problem comes from? Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 9. September 2011 10:49 An: Ingo Cc: 'olsen'; 'pd-list' Betreff: Re: AW: [PD] pduino rewrite On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote: Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything
Re: [PD] pduino rewrite
Hi Roman, Olsen and Hans, Here' a replacement object that fixes the behaviour that wrong digital in pins get recognized when more than the first 6 pins are used. I hope there is nothing else interfering with those pins anymore. The object digital_messages inside the patch should be placed here to replace the current object digital messages: Arduino/convert to symbolic commands/ Please test if it is working on other systems! I have no idea if this works with the mega or not since I don't have one to test it. If anyone could check this out it would be great to know! Ingo #N canvas 0 0 450 300 10; #N canvas 702 733 318 273 digital_messages 0; #X obj 43 16 inlet; #X obj 43 237 outlet; #X obj 43 43 route 0 1 2 3 4 5 6; #N canvas 2032 0 534 360 resolve-bits_32-39 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 440 129 mod 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169 change -1; #X obj 200 55 change -1; #X msg 20 196 digital 32 \$1; #X msg 80 216 digital 33 \$1; #X msg 140 196 digital 34 \$1; #X msg 200 216 digital 35 \$1; #X msg 260 196 digital 36 \$1; #X msg 320 216 digital 37 \$1; #X msg 380 196 digital 38 \$1; #X msg 440 216 digital 39 \$1; #X connect 0 0 25 0; #X connect 2 0 16 0; #X connect 3 0 15 0; #X connect 4 0 14 0; #X connect 5 0 13 0; #X connect 6 0 12 0; #X connect 7 0 9 0; #X connect 8 0 17 0; #X connect 9 0 18 0; #X connect 10 0 24 0; #X connect 11 0 10 0; #X connect 12 0 19 0; #X connect 13 0 20 0; #X connect 14 0 21 0; #X connect 15 0 22 0; #X connect 16 0 23 0; #X connect 17 0 26 0; #X connect 18 0 27 0; #X connect 19 0 28 0; #X connect 20 0 29 0; #X connect 21 0 30 0; #X connect 22 0 31 0; #X connect 23 0 32 0; #X connect 24 0 33 0; #X connect 25 0 2 0; #X connect 25 0 3 0; #X connect 25 0 4 0; #X connect 25 0 5 0; #X connect 25 0 6 0; #X connect 25 0 8 0; #X connect 25 0 7 0; #X connect 25 0 11 0; #X connect 26 0 1 0; #X connect 27 0 1 0; #X connect 28 0 1 0; #X connect 29 0 1 0; #X connect 30 0 1 0; #X connect 31 0 1 0; #X connect 32 0 1 0; #X connect 33 0 1 0; #X restore 106 150 pd resolve-bits_32-39; #N canvas 2032 0 534 360 resolve-bits_0-7 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 440 129 mod 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169 change -1; #X obj 200 55 change -1; #X msg 20 196 digital 0 \$1; #X msg 80 216 digital 1 \$1; #X msg 140 196 digital 2 \$1; #X msg 200 216 digital 3 \$1; #X msg 260 196 digital 4 \$1; #X msg 320 216 digital 5 \$1; #X msg 380 196 digital 6 \$1; #X msg 440 216 digital 7 \$1; #X connect 0 0 25 0; #X connect 2 0 16 0; #X connect 3 0 15 0; #X connect 4 0 14 0; #X connect 5 0 13 0; #X connect 6 0 12 0; #X connect 7 0 9 0; #X connect 8 0 17 0; #X connect 9 0 18 0; #X connect 10 0 24 0; #X connect 11 0 10 0; #X connect 12 0 19 0; #X connect 13 0 20 0; #X connect 14 0 21 0; #X connect 15 0 22 0; #X connect 16 0 23 0; #X connect 17 0 26 0; #X connect 18 0 27 0; #X connect 19 0 28 0; #X connect 20 0 29 0; #X connect 21 0 30 0; #X connect 22 0 31 0; #X connect 23 0 32 0; #X connect 24 0 33 0; #X connect 25 0 2 0; #X connect 25 0 3 0; #X connect 25 0 4 0; #X connect 25 0 5 0; #X connect 25 0 6 0; #X connect 25 0 8 0; #X connect 25 0 7 0; #X connect 25 0 11 0; #X connect 26 0 1 0; #X connect 27 0 1 0; #X connect 28 0 1 0; #X connect 29 0 1 0; #X connect 30 0 1 0; #X connect 31 0 1 0; #X connect 32 0 1 0; #X connect 33 0 1 0; #X restore 43 70 pd resolve-bits_0-7; #N canvas 2032 0 534 360 resolve-bits_8-15 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 440 129 mod 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169 change -1; #X obj 200 55 change -1; #X msg 20
Re: [PD] pduino rewrite
There is another thing that I just noticed about the pduino test-patch. The mode buttons are suggesting that you can turn of all functions by selecting NONE. This is not true! These buttons have absolutely NO function and should be replaced with the correct commands. While doing this the option Input-PullUp should be added. The Arduino generally defaults to input. Selecting NONE at the current state leaves it at the last selected option. The analogue ins can actually be turned off by the command analogIns X 0 (where the X stands for the pin number 0-5). The digital input pins need the command digitalIns X 0 (where the X stands for the pin number 0-11). I also think that there should be a separate block for digital an analogue (with the available options only) as beginners might think you could select analog as an option for digital pins, and so on... Ingo BTW with the fix I just submitted in my last email all digital ins now work flawlessly after testing for several hours. I am amazed that hardly anybody noticed this bug for over two years! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Arduino - transmit serial data while running firmata?
Is it possible to transmit serial data from the computer through the serial port of Arduino to a serial lcd display while running firmata? And if yes, how? Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Transposing samples using MIDI numbers
You need to use [mtof] to convert the midi note number to the frequency first. [tabread4~] allows variable readout speed to play back transposed samples. Check the docs for some examples of [tabread4~] and samplers (3.audio.examples/B...). Ingo Is there a way to transpose the sound of a sample [stored in a table] to match a pitch/midi note number? In my project, when a sample is played back [using tabplay~] I would like something to tune that sample to say, midi note 69 or A 440. I would like to be able to send this number to the transposing function via a number box. I am SOO close to realizing an idea, I just need this one crucial part. Thank you for your time, Sebastian ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
The reason why I didn't make an abstraction for the debyte is that I wanted to keep the number of files and dependencies as low as possible. I think this was the original idea of the rewrite, right? Anyway what can be done is add a simple offset number like I did it somewhere on my testing patch. Then you can copy as many instances as needed and offset them. Maybe multiplying by 8 first. But then again it's more objects and calculations than are really necessary. I am using it like this with only two objects for the Duemilanove. Your version with the table has 59 objects while my duplicated version has 73 objects for a Duemilanove while needing a lot less calculations, a fraction of the message transfers and no table lookups or writes. But as I had mentioned - I doubt that efficiency will play a role in just about any case for the arduino's digital pins. Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Donnerstag, 15. September 2011 08:44 An: Ingo Cc: 'Hans-Christoph Steiner'; pd-list@iem.at Betreff: Re: AW: [PD] pduino rewrite Hi Ingo Thanks for testing! On Thu, 2011-09-15 at 05:23 +0200, Ingo wrote: Hi Roman, the new version works great! I'm glad to hear that. I made myself some testing objects around it. Maybe that could be useful if you guys ever get around fixing the help patch. I'll have a look. Thanks. I still think the version using individual debyte masks is far more efficient than this one. But as you pointed out this one is more scalable and might take care of boards coming in the future (I have just seen a mega clone with 70 or 72 digital inputs). Most people don't use incremental wheels timed to 1-2 ms - like I do - anyway. So efficiency shouldn't matter in 99.9% of the cases. I generally think it does matter. However, i don't have any concerns that the additional table look up causes an efficiency problem. Table lookups are usually very fast. It's probably a matter of taste, but I often find myself looking for an 'algorithmic' solution instead of copying very similar code several times around, even if the former is a bit less efficient than the latter. In this case, if using several [pd debytemask], it'd be nice to use an abstraction instead. However, if the original [mapping/debytemask] would be used, every (-1) instance would require a row of 8 [+ 8] objects, [+ 16], [+ 24], etc. respectively. So it would either end up with a lot of additional objects below all [debytemask] instances or multiple manually crafted [pd debytemask] with each containing slightly different code (as you implemented it) would be required. The additional [pd polychange] with table lookup is made of just a handful of objects. However, if it ever turns out, that in your setup the [arduino] abstraction eats a significant amount of CPU power (what I really doubt), I'll happily replace it by your version of [pd digital messages] if it helps. And yes, the goal should be to cover also 'edge' cases like your incremental wheel. The more use cases work well with Firmata / [arduino] the better. Roman -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Hans-Christoph Steiner Gesendet: Mittwoch, 14. September 2011 22:33 An: Roman Haefeli Cc: pd-list@iem.at Betreff: Re: [PD] pduino rewrite As Ingo pointed out, one bug is that [mapping/debytemask] has the [change] object for each outlet. So probably the way to fix this is to make a bunch of [mapping/debytemask] objects for all the possible digital ports. [arduino] should only output on change of digital input, and it receives the digital information one byte/port at a time, i.e. 8 pins. Another approach would be to have an array of all of the previous values which are then compared to the current before outputting. .hc On Wed, 2011-09-14 at 11:24 +0200, Roman Haefeli wrote: Hi Ingo Thanks for all your reports. Sorry that my replies sometimes only come a few days later. I'm still willing to fix any outstanding issues, but not very often I find time to get an arduino into my hands. Since sometimes I have troubles following you and keeping your several bug reports apart from each other, I'd suggest to stick with [arduino] bugs and let the documentation aspect aside for a while. I _think_ I finally understand your problem with the digital ins. I can't currently test or reproduce the problem, since I don't have an arduino at hand, but from reading the code, I think I see what could go wrong. On certain incoming commands of [pd digital messages], the [pd debytemask] *) subpatch generates more than one message, but only the last one is finally sent to the outlet, because it only fires, when the left inlet of [+ ] is triggered
Re: [PD] pduino rewrite
Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? I simply (roughly) counted the numbers of objects the calculation including all sub processes have to pass until you get the final result. (Unfortunately I cannot tell how heavy each of these calculations is compared to another one.) I started this a while ago since I am running my machines always at the very limit that they can handle. Which is why I started cutting down the number of processes needed to get something done wherever possible. Saving 20% of the calculations in a machine that's at the limit can make quite a difference. Of course it's the audio processes that are heavier than the control processes. I remember a discussion here a while ago about how heavy the actual message transfer is. So keeping calculations as simple and straight forward all of the time will keep the machines from getting overloaded earlier than necessary. Which again reminds me that I have to redo lots of old stuff for efficiency - never ending story! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] multiple arduinos
I just tried to open the help file on Windows XP and Natty and it crashes Pd on both platforms. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von olsen Gesendet: Donnerstag, 15. September 2011 14:52 An: tim vets Cc: pd-list Betreff: Re: [PD] multiple arduinos Hi if you're running on Linux check the [ADDITIONAL-INFOS] in the arduino- help.pd on the upper right corner in the pd-rewrite: https://github.com/reduzent/pduino as mentioned below the infos you'll find there are basically from http://answers.ros.org/answers/101/revisions/ with this method you can connect the arduino within pd due to its serial adress avoiding id-conflicts. hope this helps ø On 09/06/2011 09:27 PM, tim vets wrote: We have an installation running at www.verbekefoundation.com http://www.verbekefoundation.com with two arduino's and pd for several years now. The only thing that fries now and then are the power supplies. iirc, it's just a matter of sending the right [devicename name_of_device( to the two [comport], ( or [arduino] ?) objects. You can get those devicenames by doing ls /dev/ttyU*, which will give you something like /dev/ttyUSB0 and /dev/ttyUSB1, representing the two arduino's. (under the assumption that the newer arduino models still work the same way.) gr, Tim 2011/9/6 FernandoG dataf...@gmail.com mailto:dataf...@gmail.com Hi Anybody knows if its posible to use multiple arduinos ( 2 or 3 arduino mega) with the same pduino based puredata patch? Thanks! F ___ Pd-list@iem.at mailto: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 -- ETs DNA will not be televised http://hasa-labs.org ___ 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
Re: [PD] pduino rewrite
Hi Hans, unfortunately I am not really good at C or C++ so I have to stick with simplifying within Pd until I get there. But I am actually working on it so I'll be able to replace certain objects in my patches by more efficient externals. Anyway, I think in the case of simplifying the pduino patch another external would be rather contra productive. The optimized multiple debytemasks (up to 56 input pins) as a Pd-patch are attached. I just called it differently because this was taken from an old display keypad patch that I had done before. I am using this in my remote control unit and it's working perfectly. Ingo -Ursprüngliche Nachricht- Von: Hans-Christoph Steiner [mailto:h...@at.or.at] Gesendet: Donnerstag, 15. September 2011 17:48 An: Ingo Cc: 'Roman Haefeli'; pd-list@iem.at Betreff: Re: AW: [PD] pduino rewrite On Thu, 2011-09-15 at 10:20 +0200, Ingo wrote: Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? I simply (roughly) counted the numbers of objects the calculation including all sub processes have to pass until you get the final result. (Unfortunately I cannot tell how heavy each of these calculations is compared to another one.) I started this a while ago since I am running my machines always at the very limit that they can handle. Which is why I started cutting down the number of processes needed to get something done wherever possible. Saving 20% of the calculations in a machine that's at the limit can make quite a difference. Of course it's the audio processes that are heavier than the control processes. I remember a discussion here a while ago about how heavy the actual message transfer is. So keeping calculations as simple and straight forward all of the time will keep the machines from getting overloaded earlier than necessary. Which again reminds me that I have to redo lots of old stuff for efficiency - never ending story! Ingo If you want efficiency in this object, you should implement it in C. That should not be hard to do since the Firmata code is C++, but coded mostly in a C style. So you can get all of the parsing and message generating code from Firmata.cpp and StandardFirmata.pde, and make a compiled object out of it. And Ingo, if you implement a fixed the [debytemask] approach, I'll included it in the Pduino arduino.pd. .hc #N canvas 504 92 321 208 10; #N canvas 606 345 294 266 digital_messages 1; #X obj 43 16 inlet; #X obj 43 237 outlet; #X obj 43 43 route 0 1 2 3 4 5 6; #N canvas 1386 0 534 360 resolve-bits_32-39 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169 change -1; #X obj 200 55 change -1; #X msg 20 196 digital 32 \$1; #X msg 80 216 digital 33 \$1; #X msg 140 196 digital 34 \$1; #X msg 200 216 digital 35 \$1; #X msg 260 196 digital 36 \$1; #X msg 320 216 digital 37 \$1; #X msg 380 196 digital 38 \$1; #X msg 440 216 digital 39 \$1; #X obj 440 129 mod 256; #X connect 0 0 24 0; #X connect 2 0 15 0; #X connect 3 0 14 0; #X connect 4 0 13 0; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 7 0 9 0; #X connect 8 0 16 0; #X connect 9 0 17 0; #X connect 10 0 23 0; #X connect 11 0 18 0; #X connect 12 0 19 0; #X connect 13 0 20 0; #X connect 14 0 21 0; #X connect 15 0 22 0; #X connect 16 0 25 0; #X connect 17 0 26 0; #X connect 18 0 27 0; #X connect 19 0 28 0; #X connect 20 0 29 0; #X connect 21 0 30 0; #X connect 22 0 31 0; #X connect 23 0 32 0; #X connect 24 0 2 0; #X connect 24 0 3 0; #X connect 24 0 4 0; #X connect 24 0 5 0; #X connect 24 0 6 0; #X connect 24 0 8 0; #X connect 24 0 7 0; #X connect 24 0 33 0; #X connect 25 0 1 0; #X connect 26 0 1 0; #X connect 27 0 1 0; #X connect 28 0 1 0; #X connect 29 0 1 0; #X connect 30 0 1 0; #X connect 31 0 1 0; #X connect 32 0 1 0; #X connect 33 0 10 0; #X restore 106 150 pd resolve-bits_32-39; #N canvas 1386 0 534 360 resolve-bits_0-7 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169
Re: [PD] pduino rewrite
The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. .hc Not sure what you mean by labor-intensive, Hans. Are you talking about manually changing 8 numbers per object (which took me less than 1 minute for 56 channels) or are you talking about cpu processing? Which leads me to the next question: is the Boolean approach using [ 4] and [ 2] more cpu friendly than using [mod 8] and [div 4]? I don't know how Pd handles such calculations and how it talks to the cpu. I'd be really very interested to find out if there is a difference. Since the pin numbers are predefined when you are using a [route] object to sort out the groups I don't see the point why the pin number should be calculated again (in this case of multiple instances). This is why I hardcoded them into the message boxes. I put the two approaches next to each other to see how much simpler my approach is object wise and calculation wise. Still with the question mark which calculation method is more cpu friendly. Anyway changing [mod 8] and [div 4] to [ 4] and [ 2] shouldn't take more than a minute. The main difference to Romans approach is that it uses more fixed code to end up doing less when actually working. BTW I think Romans approach makes generally more sense for most cases since it is scalable and does not need any different code for any number of pins (up to 128 in the current version) which makes it much simpler to use. I have attached a patch that shows the difference between the two debyte methods. Ingo #N canvas 317 0 1025 801 10; #X obj 238 619 cnv 15 370 140 empty empty empty 20 12 0 14 -262130 -66577 0; #X floatatom 253 633 5 0 255 0 - - -; #X floatatom 253 685 5 0 0 0 - - -; #X floatatom 303 685 5 0 0 0 - - -; #X floatatom 253 731 5 0 0 0 - - -; #X floatatom 303 731 5 0 0 0 - - -; #X obj 253 665 mod 8; #X obj 253 704 div 4; #X obj 303 665 4; #X obj 303 705 2; #X text 362 628 Question:; #X obj 540 79 cnv 15 350 100 empty empty empty 20 12 0 14 -232576 -66577 0; #X obj 659 376 cnv 15 170 180 empty empty empty 20 12 0 14 -232576 -66577 0; #X obj 190 582 outlet; #X obj 190 55 route 0 1 2 3 4 5 6; #X obj 190 28 inlet; #X obj 690 495 +; #X msg 690 535 digital \$1 \$2; #X obj 690 515 pack float float; #X obj 690 378 unpack float float; #X obj 690 82 t a a; #X msg 717 102 \$1; #X msg 690 102 \$2; #X obj 690 55 route 0 1 2 3 4 5 6; #X obj 690 28 inlet; #X obj 550 159 trigger float float float float float float float float ; #X obj 690 582 outlet; #X obj 659 619 cnv 15 170 140 empty empty empty 20 12 0 14 -232576 -66577 0; #X text 668 663 There is no need to; #X obj 959 193 cnv 15 50 50 empty empty empty 20 12 0 14 -232576 -66577 0; #X obj 972 199 15; #X obj 972 220 * 8; #X text 668 726 selects this pin group.; #X text 668 711 The route object already; #X text 362 648 is the 1st calculation using [mod] and; #X text 362 663 [div] heavier on cpu cycles than [ 4]; #X text 362 678 and [ 2] due to different processor; #X text 362 693 instructions?; #X text 687 6 debyte; #X text 668 691 defined by the firmata.; #X text 668 676 calculate the pin number; #X text 668 628 The objects marked here; #X text 668 643 are not necessary.; #X obj 336 722 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 336 682 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 4 188 cnv 15 920 120 empty empty empty 20 12 0 14 -233017 -66577 0; #X obj 370 206 mod 128; #X obj 310 206 mod 64; #X obj 250 206 mod 32; #X obj 190 206 mod 16; #X obj 130 206 mod 8; #X obj 70 206 mod 4; #X obj 10 206 mod 2; #X obj 70 226 div 2; #X obj 430 226 div 128; #X obj 130 226 div 4; #X obj 190 226 div 8; #X obj 250 226 div 16; #X obj 310 226 div 32; #X obj 370 226 div 64; #X obj 10 246 change -1; #X obj 70 246 change -1; #X obj 130 246 change -1; #X obj 190 246 change -1; #X obj 250 246 change -1; #X obj 310 246 change -1; #X obj 370 246 change -1; #X obj 430 246 change -1; #X msg 10 266 digital 0 \$1; #X msg 70 286 digital 1 \$1; #X msg 130 266 digital 2 \$1; #X msg 190 286 digital 3 \$1; #X msg 250 266 digital 4 \$1; #X msg 310 286 digital 5 \$1; #X msg 370 266 digital 6 \$1; #X msg 430 286 digital 7 \$1; #X obj 430 206 mod 256; #X msg 550 264 0 \$1; #X msg 596 284 1 \$1; #X msg 643 265 2 \$1; #X msg 690 284 3 \$1; #X msg 736 266 4 \$1; #X msg 783 284 5 \$1; #X msg 830 267 6 \$1; #X msg 877 284 7 \$1; #X obj 550 206 1; #X obj 596 205 2; #X obj 643 205 4; #X obj 690 205 8; #X obj 736 205 16; #X obj 783 205 32; #X obj 830 205 64; #X obj 877 205 128; #X obj 596 225 1; #X obj 643 225 2; #X obj 690 225 3; #X obj 736 225 4; #X obj 783 225 5; #X obj 830 225 6; #X obj 877 225 7; #X obj 550 244 change; #X obj 596 245 change; #X obj 643 245 change; #X obj 690 245 change; #X obj 736 246 change; #X obj 783 247 change; #X obj 830 247 change; #X obj 877
Re: [PD] pduino rewrite
Wow, I just compared your version of [pd digital message] with mine and yours takes only 180ms to process 100 of messages, while mine uses over 8s. Frankly, I wouldn't have expected such a big difference Let me dig into this. Roman That's more than I would have expected, too! I would have been guessing it could be up to 10x as fast but not 50x. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Roman, Frankly, I'm not yet convinced that those little improvements in [arduino] will significantly improve the overall Pd performance. Here's the reason why I started really to simplify any patch, no matter if audio or control objects: I have been programming for about 4 years on one single patch (fulltime - only with breaks to get the hardware/OS going and sampling/editing sampled instruments). You can imagine the amount of code that is in the patch by now. When I started I thought it was very convenient to use wireless [send/receive] objects to send midi data to the sample-voices (which it is). At a certain point (about 2 years ago) the machine was completely overloaded! Then I measured that a EWI-USB wind controller can send up to 500 midi CC messages per second. I had a function that could multiply the messages to six different midi channels. That makes it 3,000 messages floating around. The sample voices have at least 500 [receive] objects (there are close to 500 parameters per voice). There were 16 voices which adds up to 8,000 [receive] objects. Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million times per second that the individual [receive] objects had to check whether the message was meant to be for them or not. That should be as much data shifting around only for checking [receive] objects as it would take to move the data of several hundreds of audio channels around. The first fix was easy: assigning the parameter to receive from midi Ch01 if voices are stacked. That cut the message transfer by 6. The second fix was to replace the wireless sends with hard wired patch chords. That took care of most of the rest. The machine was working again. Unfortunately this second fix took 3-4 full months!!! This is when I decided to think about efficiency in running mode first. If you have a piece of code that has to check between 10 different options and in a certain case only two options are available then it is worth it copying the object and take out all unnecessary options. It's more work while programming but it saves in this particular example several hundred percent cpu time when running. When such a programming style is used consistently I am sure you can get at least double or more of the performance of a computer. Even with messages where you would think they are not too heavy. Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 16. September 2011 11:32 An: Ingo Cc: 'Hans-Christoph Steiner'; pd-list@iem.at Betreff: Re: AW: AW: AW: [PD] pduino rewrite On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote: The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. .hc Not sure what you mean by labor-intensive, Hans. Are you talking about manually changing 8 numbers per object (which took me less than 1 minute for 56 channels) or are you talking about cpu processing? Which leads me to the next question: is the Boolean approach using [ 4] and [ 2] more cpu friendly than using [mod 8] and [div 4]? I was told that it is. Bit shifting and bit mask matching is supposed to be faster than integer division and modulo with an arbitrary (inclusive non-power-of-two integers). However, I can't tell you whether they are really faster in the real world. But you should be able to test it in your own setup with [realtime]. Start [realtime], let [mod 8]-[div 4] process 1 million numbers in 0 logical time, stop [realtime]. Do the same with a [ 4]-[ 2] chain and compare the results. I don't know how Pd handles such calculations and how it talks to the cpu. I'd be really very interested to find out if there is a difference. Since the pin numbers are predefined when you are using a [route] object to sort out the groups I don't see the point why the pin number should be calculated again (in this case of multiple instances). This is why I hardcoded them into the message boxes. I put the two approaches next to each other to see how much simpler my approach is object wise and calculation wise. Still with the question mark which calculation method is more cpu friendly. Anyway changing [mod 8] and [div 4] to [ 4] and [ 2] shouldn't take more than a minute. You could also test the whole [pd digital message] subpatch with the above mentioned approach. Frankly, I'm not yet convinced that those little improvements in [arduino] will significantly improve the overall Pd performance. Using one less tilde object somewhere in your patch would save some order of magnitudes of CPU power more of what you ever will be able to squeeze out of the [arduino]. Message processing is usually so cheap compared to signal processing, that most often it's hardly worth to focus
Re: [PD] multiple arduinos
I just tried to open the help file on Windows XP and Natty and it crashes Pd on both platforms. hm that's a pity - anyone else similar experience? any hints how to reproduce this? Tried it again right now and it's working. Might have been a server issue. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
To make sure boards that are larger than 56 digital in pins you should copy a couple more of these objects to go up to 128. Of course since [] and [] seems to be slightly faster that would be the choice. To be even more efficient the object [pd route digital/analog] should be bypassed by adding the addresses [144 145 146 ... 151] to the route object inside the parent patch making it [route 249 240 144 145 146 147 148 149 150 151]. The last outlet goes into [pd route digital/analog]. The [route 0 1 2 3 4 5 6 7] inside the [pd digital messages] should be replace by 8 individual inlets. BTW you could keep going on with this forever ... All I wanted originally was to get the correct messages coming out of the patch ... Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 16. September 2011 14:44 An: Ingo Cc: 'Hans-Christoph Steiner'; pd-list@iem.at Betreff: Re: AW: AW: AW: AW: [PD] pduino rewrite On Fri, 2011-09-16 at 14:05 +0200, Ingo wrote: Wow, I just compared your version of [pd digital message] with mine and yours takes only 180ms to process 100 of messages, while mine uses over 8s. Frankly, I wouldn't have expected such a big difference Let me dig into this. Roman That's more than I would have expected, too! I would have been guessing it could be up to 10x as fast but not 50x. I think I'm going to put your much more efficient version into the git version. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Claude, When I started I thought it was very convenient to use wireless [send/receive] objects to send midi data to the sample-voices (which it is). [snip] Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million times per second that the individual [receive] objects had to check whether the message was meant to be for them or not. [snip] The second fix was to replace the wireless sends with hard wired patch chords. Faced with this scenario I would probably have tried dynamic sends, so the data determines which receive gets the message. For example: ... | [pack f f f f f f] | [ ; r-$1-$2-$3 $4 $5 $6 ( [r r-1-4-7] | [unpack f f f] | ... [r r-27-63-49] | [unpack f f f] | That would imply that you know which midi CC message gets there when since the left inlet of [pack] needs to be banged. Or it would be delayed until the left inlet receives a new message (if at all). Or you would have to bang the left inlet every time another one comes in. That would even multiply the data transfer. Last solution would be a fixed send timing every couple of milliseconds. That would multiply the average data transfer and lower the timing resolution. And using nested abstractions you could create the receives based on $args $args have to listen to all sent messages also. You are simply expanding the name with the $arg. When you have 10 voices all [receive]s of all 10 voices will have to listen for every [send] message to determine whether it is for them or not. Doesn't matter if the name starts with $0-. and if you need lots of voices you could use dynamic patching to instantiate them. To initialize sample-voices like the ones I am using Pd takes about ten seconds. If you want to play a piano chord that has one note more than current voices are present you don't really want to wait 10 seconds, do you? And afterwards are you going to erase that voice again? This would again interrupt the audio stream. Anyway audio calculation can be turned off with the [switch~] object. [receive] objects cannot be made inactive ever. The only way to do this would be to split up the voices over several independent patches which communicate over [netsend/netreceive] or [osc]. This makes audio communication very difficult and it would be very hard to keep all of those thousands of tables updated in all patches. It's just simply more efficient to address the data directly by wired connections only to the destination that needs the data. Looks messy but works better! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Actually, packing an id before the actual data and using a route object to distribute all separate destinations from one single [receive] - [route] - parameters would do the trick. Maybe that's what you meant? I just cannot picture a [route] object with up to 500 outlets, yet. But there might be ways to organize it using a small number of [receive] and a small number of [route] and sub-[route] objects. However, it would take just as much time to rewrite an existing patch like this as it takes to hardwire the sends. I still think that these considerations need to be made when starting to write any kind of code because problems only start showing up when it's almost too late. Once the patch gets kinda huge fixing will become very time consuming. Optimizing any code to the least amount of parsing data/messages around is the key for doing any complex patches. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ingo Gesendet: Freitag, 16. September 2011 16:42 An: 'Claude Heiland-Allen'; pd-list@iem.at Betreff: Re: [PD] pduino rewrite Hi Claude, When I started I thought it was very convenient to use wireless [send/receive] objects to send midi data to the sample-voices (which it is). [snip] Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million times per second that the individual [receive] objects had to check whether the message was meant to be for them or not. [snip] The second fix was to replace the wireless sends with hard wired patch chords. Faced with this scenario I would probably have tried dynamic sends, so the data determines which receive gets the message. For example: ... | [pack f f f f f f] | [ ; r-$1-$2-$3 $4 $5 $6 ( [r r-1-4-7] | [unpack f f f] | ... [r r-27-63-49] | [unpack f f f] | That would imply that you know which midi CC message gets there when since the left inlet of [pack] needs to be banged. Or it would be delayed until the left inlet receives a new message (if at all). Or you would have to bang the left inlet every time another one comes in. That would even multiply the data transfer. Last solution would be a fixed send timing every couple of milliseconds. That would multiply the average data transfer and lower the timing resolution. And using nested abstractions you could create the receives based on $args $args have to listen to all sent messages also. You are simply expanding the name with the $arg. When you have 10 voices all [receive]s of all 10 voices will have to listen for every [send] message to determine whether it is for them or not. Doesn't matter if the name starts with $0-. and if you need lots of voices you could use dynamic patching to instantiate them. To initialize sample-voices like the ones I am using Pd takes about ten seconds. If you want to play a piano chord that has one note more than current voices are present you don't really want to wait 10 seconds, do you? And afterwards are you going to erase that voice again? This would again interrupt the audio stream. Anyway audio calculation can be turned off with the [switch~] object. [receive] objects cannot be made inactive ever. The only way to do this would be to split up the voices over several independent patches which communicate over [netsend/netreceive] or [osc]. This makes audio communication very difficult and it would be very hard to keep all of those thousands of tables updated in all patches. It's just simply more efficient to address the data directly by wired connections only to the destination that needs the data. Looks messy but works better! Ingo ___ 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
Re: [PD] Variable number of objects?
To my experience there will be definitely audio dropouts with dynamic voice creation. In the case of my rather complex patch (with currently only 8 voices) I have to wait up to ten seconds until the patch is ready again for playback. I am using a 3.2 GHz Athlon II X2 which is not that slow. Simpler synth voices might be faster, though. I think it is much better to create as many voices as needed beforehand and turn unused voices off with the [switch~] object. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ludwig Maes Gesendet: Mittwoch, 28. September 2011 17:56 An: Pd List Betreff: [PD] Variable number of objects? Im not sure what the best way is to instantiate variable number of objects, for example consider polysynth.pd: Theres a fixed number of manually placed voices, suppose I want to have the top patch to contain a counter through which one may increase or decrease the number of voices, how would I go about that (without manually placing a load of voices and disabling them...)? Whats the vanilla way to do this? Whats the pd-extended way to do this? ... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Variable number of objects?
Well, as I said in my case the voices are very complex. There are hundreds of audio objects in each voice. It takes a lot of time to adjust all of the signal flow and reallocate the memory I guess. Control objects shouldn't be such a big problem. Ingo Von: Ludwig Maes [mailto:ludwig.m...@gmail.com] Gesendet: Mittwoch, 28. September 2011 19:30 An: Ingo Betreff: Re: [PD] Variable number of objects? I actually meant more in general, also for non-~ signals (i.e. also control rate .pd patches). I referred to polysynth such that people would see more easily what I meant. Are there really no such primitives? That seems like quite a restriction... How can that take 10 seconds?? I dont see what would cause such a huge overhead, i'd expect an increase in computations memory though (say from 10 voices to 11: 10% increase in cpu workload ram dedicated to these voices..., I fail to see what would necessitate a long initialization...) also, how is it done even with the long delays? On 28 September 2011 18:33, Ingo i...@miamiwave.com wrote: To my experience there will be definitely audio dropouts with dynamic voice creation. In the case of my rather complex patch (with currently only 8 voices) I have to wait up to ten seconds until the patch is ready again for playback. I am using a 3.2 GHz Athlon II X2 which is not that slow. Simpler synth voices might be faster, though. I think it is much better to create as many voices as needed beforehand and turn unused voices off with the [switch~] object. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ludwig Maes Gesendet: Mittwoch, 28. September 2011 17:56 An: Pd List Betreff: [PD] Variable number of objects? Im not sure what the best way is to instantiate variable number of objects, for example consider polysynth.pd: Theres a fixed number of manually placed voices, suppose I want to have the top patch to contain a counter through which one may increase or decrease the number of voices, how would I go about that (without manually placing a load of voices and disabling them...)? Whats the vanilla way to do this? Whats the pd-extended way to do this? ... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] throw~ / catch~ versus send~ / receive~
I would assume this one block delay could be avoided by cut and undo of the [catch~] object after creating new [throw~] objects. Right? But how can you time it if they are in different abstractions? Ingo _ Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Björn Eriksson Gesendet: Donnerstag, 29. September 2011 00:20 An: Lorenzo Sutton; pd-list@iem.at Betreff: Re: [PD] throw~ / catch~ versus send~ / receive~ Thanks for the info and pointer! Was by that also getting aware about the possible added delay When you send a signal to a point that is earlier in the sorted list of tilde objects, the signal doesn't get there until the next cycle of DSP computation, one block later; so your signal will be delayed by one block (1.45 msec by default.) Can be good to know! /Björn 2011/9/28 Lorenzo Sutton lsut...@libero.it Hi Björn, On 28/09/2011 15:27, Björn Eriksson wrote: [...] what are the differences between throw~ / catch~ and send~ / receive~ ? For me they seem to work equally well, either as bus sending or single audio signal send. From the Pd Documentation [1]: There can be many throw~ objects associated with a single catch~, but a throw~ can't talk to more than one catch~. ... Send~ just saves a signal which may then be receive~d any number of times; but a receive~ can only pick up one send~ at a time (but you can switch between send~s if you want.) Ciao, Lorenzo [1] http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s4.5 Maybe I am doing wrong when I´m summing audiosignals together into a send~ object just by patching them together and should use the throw~object instead, but just curious on why and how?// Thankful for thoughts on this.. All the best, Björn Eriksson ___ 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
Re: [PD] Fwd: Variable number of objects?
Actually, I just tried again to simply copy a couple of voices and it only took a fraction of a second with a very short dropout - even with the dsp on. I have recently installed Natty instead of Lucid on a new machine. Maybe it has something to do with realloc that Mathieu mentioned. So it looks like dynamic patching of voices isn't that much of a problem here anymore. It still takes 7-8 seconds to create 16 voices in my case with the dsp off (12 with the dsp on) but that's still faster than restarting the patch. I would never have checked again if nobody would have mentioned it. I have attached a patch that I used for testing. These voices were receiving their input with [receive] so no connections were needed. If you are using wired inlets you will have to dynamically add the connections of course. I added a cut paste at the end because for some reasons the voices didn't get initialized correctly. Not sure if this is needed for other voice-abstractions. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Roman Haefeli Gesendet: Donnerstag, 29. September 2011 08:36 An: Ludwig Maes Cc: Pd List Betreff: Re: [PD] Fwd: Variable number of objects? On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote: -- Forwarded message -- From: Ludwig Maes ludwig.m...@gmail.com Date: 28 September 2011 19:29 Subject: Re: [PD] Variable number of objects? To: Ingo i...@miamiwave.com I actually meant more in general, also for non-~ signals (i.e. also control rate .pd patches). I referred to polysynth such that people would see more easily what I meant. Are there really no such primitives? That seems like quite a restriction... How can that take 10 seconds?? I dont see what would cause such a huge overhead, i'd expect an increase in computations memory though (say from 10 voices to 11: 10% increase in cpu workload ram dedicated to these voices..., I fail to see what would necessitate a long initialization...) also, how is it done even with the long delays? As I understand it, the whole DSP is recompiled whenever it is changed. So, if you have a very large patch (and Ingo seems to be an expert in very large patches) and you create another voice, it's easily possible to eat up quite some time. Also, it's probably much slower the first time, if the voice abstraction is built of many other abstractions, which need to be read from disk. But I guess you are right about the increase in CPU workload _after_ the DSP graph has been recompiled: A switch from 10 two 11 instances is expected to show only an increase of 10% in CPU usage. It's been said, that often you can gain quite some time while turning off DSP during dynamic instantiation. But I guess, this makes only a difference when performing several instantiations at the same time. When DSP is on, each cycle would cause a complete DSP graph recompilation, whereas when DSP is off, it's only recompiled once (after turning it on again). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 609 0 565 676 10; #X text 193 513 pos left; #X text 251 513 pos top; #X obj 244 568 pack f f f; #X msg 117 554 selectall; #X msg 87 554 cut; #X msg 47 554 paste; #X obj 30 608 s reset_system_delay; #X obj 262 243 f; #X obj 294 243 + 1; #X obj 228 280 sel; #X obj 246 228 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 228 307 0; #X obj 160 307 spigot; #X obj 262 435 t b f f; #X obj 272 462 * 20; #X msg 406 372 clear; #X obj 30 527 t b b b b; #X obj 193 124 f; #X text 305 513 argument (voice number); #X text 277 108 set number of voices; #X obj 298 16 loadbang; #X obj 247 110 nbx 2 14 1 24 0 1 empty empty empty 0 -8 0 10 -261682 -1 -1 4 256; #X msg 214 531 30; #X obj 272 482 + 20; #N canvas 268 529 331 383 voicecanvas 1; #X restore 26 18 pd voicecanvas; #X obj 406 392 s pd-voicecanvas; #X obj 273 48 bng 15 250 50 0 empty empty add_voices -52 7 1 9 -257985 -1 -1; #X obj 47 581 s pd-voicecanvas; #X obj 244 608 s pd-voicecanvas; #X msg 244 588 obj \$1 \$2 samplevoice \$3; #X obj 30 507 pipe 100; #X text 20 279 pipe can be set faster; #X text 242 623 send to window-name; #X obj 298 63 t b b b; #X obj 337 244 nbx 2 14 0 16 0 0 empty empty empty 0 -8 0 10 -261682 -1 -1 0 256; #X obj 262 295 +; #X obj 289 402 s pd-voicecanvas; #X msg 289 382 obj 30 10 inlet; #X obj 262 315 t f f; #X obj 289 355 t b b; #X obj 289 335 sel 1; #X msg 262 201 0; #X obj 193 144 t b f f; #X obj 160 280 pipe 100; #X text 339 333 clear subpatch and create inlet; #X text 339 343 when starting from 1st voice; #X msg 443 212 set \$1; #X obj 346 477 f; #X text 371 476 set automatic voice offset; #X obj 406 21 bng 15 250 50 0 empty empty reset 17 7 0 10 -258113 -1 -1; #X msg 406 39 0; #X text 367 242 automatic voice number
Re: [PD] Fwd: Variable number of objects?
I just added the [; pd dsp 0( when starting to creat voices to speed it up and eliminated the 17 voices limit of the patch. Maybe it's useful for somebody. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ingo Gesendet: Donnerstag, 29. September 2011 11:33 An: 'Roman Haefeli'; 'Ludwig Maes' Cc: 'Pd List' Betreff: Re: [PD] Fwd: Variable number of objects? Actually, I just tried again to simply copy a couple of voices and it only took a fraction of a second with a very short dropout - even with the dsp on. I have recently installed Natty instead of Lucid on a new machine. Maybe it has something to do with realloc that Mathieu mentioned. So it looks like dynamic patching of voices isn't that much of a problem here anymore. It still takes 7-8 seconds to create 16 voices in my case with the dsp off (12 with the dsp on) but that's still faster than restarting the patch. I would never have checked again if nobody would have mentioned it. I have attached a patch that I used for testing. These voices were receiving their input with [receive] so no connections were needed. If you are using wired inlets you will have to dynamically add the connections of course. I added a cut paste at the end because for some reasons the voices didn't get initialized correctly. Not sure if this is needed for other voice-abstractions. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Roman Haefeli Gesendet: Donnerstag, 29. September 2011 08:36 An: Ludwig Maes Cc: Pd List Betreff: Re: [PD] Fwd: Variable number of objects? On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote: -- Forwarded message -- From: Ludwig Maes ludwig.m...@gmail.com Date: 28 September 2011 19:29 Subject: Re: [PD] Variable number of objects? To: Ingo i...@miamiwave.com I actually meant more in general, also for non-~ signals (i.e. also control rate .pd patches). I referred to polysynth such that people would see more easily what I meant. Are there really no such primitives? That seems like quite a restriction... How can that take 10 seconds?? I dont see what would cause such a huge overhead, i'd expect an increase in computations memory though (say from 10 voices to 11: 10% increase in cpu workload ram dedicated to these voices..., I fail to see what would necessitate a long initialization...) also, how is it done even with the long delays? As I understand it, the whole DSP is recompiled whenever it is changed. So, if you have a very large patch (and Ingo seems to be an expert in very large patches) and you create another voice, it's easily possible to eat up quite some time. Also, it's probably much slower the first time, if the voice abstraction is built of many other abstractions, which need to be read from disk. But I guess you are right about the increase in CPU workload _after_ the DSP graph has been recompiled: A switch from 10 two 11 instances is expected to show only an increase of 10% in CPU usage. It's been said, that often you can gain quite some time while turning off DSP during dynamic instantiation. But I guess, this makes only a difference when performing several instantiations at the same time. When DSP is on, each cycle would cause a complete DSP graph recompilation, whereas when DSP is off, it's only recompiled once (after turning it on again). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 609 0 565 681 10; #X text 193 513 pos left; #X text 251 513 pos top; #X obj 244 568 pack f f f; #X msg 131 554 selectall; #X msg 101 554 cut; #X msg 61 554 paste; #X obj 45 608 s reset_system_delay; #X obj 260 223 f; #X obj 292 223 + 1; #X obj 228 280 sel; #X obj 244 208 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 228 307 0; #X obj 160 307 spigot; #X obj 262 435 t b f f; #X obj 272 462 * 20; #X msg 406 372 clear; #X obj 174 124 f; #X text 305 513 argument (voice number); #X text 269 108 set number of voices; #X obj 308 16 loadbang; #X obj 238 110 nbx 2 14 1 24 0 1 empty empty empty 0 -8 0 10 -261682 -1 -1 4 256; #X msg 214 531 30; #X obj 272 482 + 20; #N canvas 268 529 331 383 voicecanvas 1; #X restore 26 18 pd voicecanvas; #X obj 406 392 s pd-voicecanvas; #X obj 283 48 bng 15 250 50 0 empty empty add_voices -52 7 1 9 -257985 -1 -1; #X obj 61 581 s pd-voicecanvas; #X obj 244 608 s pd-voicecanvas; #X msg 244 588 obj \$1 \$2 samplevoice \$3; #X obj 30 507 pipe 100; #X text 20 279 pipe can be set faster; #X text 242 623 send to window-name; #X obj 342 244 nbx 2 14 0 1e+037 0 0 empty empty empty 0 -8 0 10 -261682 -1 -1 0 256; #X obj 262 295 +; #X obj 289 402 s pd-voicecanvas; #X msg
Re: [PD] Fwd: Variable number of objects?
I made some more changes and added some help information to the voice creation patch so you can simple use a float to add voices and 0 to clear all voices. There are wired inlets for the voices now. Hope it's helpful for anybody! Ingo -Ursprüngliche Nachricht- Von: Ingo [mailto:i...@miamiwave.com] Gesendet: Donnerstag, 29. September 2011 12:02 An: 'Ingo'; 'Roman Haefeli'; 'Ludwig Maes' Cc: 'Pd List' Betreff: AW: [PD] Fwd: Variable number of objects? I just added the [; pd dsp 0( when starting to creat voices to speed it up and eliminated the 17 voices limit of the patch. Maybe it's useful for somebody. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ingo Gesendet: Donnerstag, 29. September 2011 11:33 An: 'Roman Haefeli'; 'Ludwig Maes' Cc: 'Pd List' Betreff: Re: [PD] Fwd: Variable number of objects? Actually, I just tried again to simply copy a couple of voices and it only took a fraction of a second with a very short dropout - even with the dsp on. I have recently installed Natty instead of Lucid on a new machine. Maybe it has something to do with realloc that Mathieu mentioned. So it looks like dynamic patching of voices isn't that much of a problem here anymore. It still takes 7-8 seconds to create 16 voices in my case with the dsp off (12 with the dsp on) but that's still faster than restarting the patch. I would never have checked again if nobody would have mentioned it. I have attached a patch that I used for testing. These voices were receiving their input with [receive] so no connections were needed. If you are using wired inlets you will have to dynamically add the connections of course. I added a cut paste at the end because for some reasons the voices didn't get initialized correctly. Not sure if this is needed for other voice-abstractions. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Roman Haefeli Gesendet: Donnerstag, 29. September 2011 08:36 An: Ludwig Maes Cc: Pd List Betreff: Re: [PD] Fwd: Variable number of objects? On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote: -- Forwarded message -- From: Ludwig Maes ludwig.m...@gmail.com Date: 28 September 2011 19:29 Subject: Re: [PD] Variable number of objects? To: Ingo i...@miamiwave.com I actually meant more in general, also for non-~ signals (i.e. also control rate .pd patches). I referred to polysynth such that people would see more easily what I meant. Are there really no such primitives? That seems like quite a restriction... How can that take 10 seconds?? I dont see what would cause such a huge overhead, i'd expect an increase in computations memory though (say from 10 voices to 11: 10% increase in cpu workload ram dedicated to these voices..., I fail to see what would necessitate a long initialization...) also, how is it done even with the long delays? As I understand it, the whole DSP is recompiled whenever it is changed. So, if you have a very large patch (and Ingo seems to be an expert in very large patches) and you create another voice, it's easily possible to eat up quite some time. Also, it's probably much slower the first time, if the voice abstraction is built of many other abstractions, which need to be read from disk. But I guess you are right about the increase in CPU workload _after_ the DSP graph has been recompiled: A switch from 10 two 11 instances is expected to show only an increase of 10% in CPU usage. It's been said, that often you can gain quite some time while turning off DSP during dynamic instantiation. But I guess, this makes only a difference when performing several instantiations at the same time. When DSP is on, each cycle would cause a complete DSP graph recompilation, whereas when DSP is off, it's only recompiled once (after turning it on again). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 607 0 578 744 10; #X obj 26 21 inlet; #N canvas 342 529 257 383 voicecanvas 1; #X restore 26 58 pd voicecanvas; #X text 254 559 pos left; #X text 312 559 pos top; #X obj 297 623 pack f f f; #X msg 112 562 selectall; #X msg 82 562 cut; #X obj 39 616 s reset_system_delay; #X obj 240 348 f; #X obj 272 348 + 1; #X obj 196 395 sel; #X obj 220 333 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 196 422 0; #X obj 98 422 spigot; #X obj 315 576 * 20; #X msg 459 429 clear; #X obj 315 596 + 20; #X obj 459 449 s pd-voicecanvas; #X obj 82 589 s pd-voicecanvas; #X obj 297 663 s pd-voicecanvas; #X text 295 678 send
Re: [PD] Fwd: Variable number of objects?
What happens if you just have the maximum number of voices you think you'd ever need and [switch~] them on and off as needed? Since you have a large patch, I'd be curious to know how much memory is taken up by having the switched off voices just sitting there. -Jonathan That's what I am doing anyway. Memory is not an issue. There is obviously no change in memory by simply switching the voices on or off. After I got most of the control stuff as well as a large number of the [receive] objects out of the way the patch doesn't need that much cpu time at all unless the voices are turned on and playing. Now that the switched off voices are not hardly doing anything anymore there is no more need to adjust the voice number as it was the case before I got rid of a whole bunch of [receive] objects and cut most of the control messages when the [switch~] object gets turned off. In certain cases I can limit the voice number with different [poly] objects. One shouldn't underestimate the cpu load when several hundreds of midi controllers per second are modulating hundreds of parameters and the get multiplied by 16 voices constantly because the control messages are still active all of the time. Ingo - Original Message - From: Ingo i...@miamiwave.com To: 'Roman Haefeli' reduz...@gmail.com; 'Ludwig Maes' ludwig.m...@gmail.com Cc: 'Pd List' pd-list@iem.at Sent: Thursday, September 29, 2011 5:33 AM Subject: Re: [PD] Fwd: Variable number of objects? Actually, I just tried again to simply copy a couple of voices and it only took a fraction of a second with a very short dropout - even with the dsp on. I have recently installed Natty instead of Lucid on a new machine. Maybe it has something to do with realloc that Mathieu mentioned. So it looks like dynamic patching of voices isn't that much of a problem here anymore. It still takes 7-8 seconds to create 16 voices in my case with the dsp off (12 with the dsp on) but that's still faster than restarting the patch. I would never have checked again if nobody would have mentioned it. I have attached a patch that I used for testing. These voices were receiving their input with [receive] so no connections were needed. If you are using wired inlets you will have to dynamically add the connections of course. I added a cut paste at the end because for some reasons the voices didn't get initialized correctly. Not sure if this is needed for other voice-abstractions. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Roman Haefeli Gesendet: Donnerstag, 29. September 2011 08:36 An: Ludwig Maes Cc: Pd List Betreff: Re: [PD] Fwd: Variable number of objects? On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote: -- Forwarded message -- From: Ludwig Maes ludwig.m...@gmail.com Date: 28 September 2011 19:29 Subject: Re: [PD] Variable number of objects? To: Ingo i...@miamiwave.com I actually meant more in general, also for non-~ signals (i.e. also control rate .pd patches). I referred to polysynth such that people would see more easily what I meant. Are there really no such primitives? That seems like quite a restriction... How can that take 10 seconds?? I dont see what would cause such a huge overhead, i'd expect an increase in computations memory though (say from 10 voices to 11: 10% increase in cpu workload ram dedicated to these voices..., I fail to see what would necessitate a long initialization...) also, how is it done even with the long delays? As I understand it, the whole DSP is recompiled whenever it is changed. So, if you have a very large patch (and Ingo seems to be an expert in very large patches) and you create another voice, it's easily possible to eat up quite some time. Also, it's probably much slower the first time, if the voice abstraction is built of many other abstractions, which need to be read from disk. But I guess you are right about the increase in CPU workload _after_ the DSP graph has been recompiled: A switch from 10 two 11 instances is expected to show only an increase of 10% in CPU usage. It's been said, that often you can gain quite some time while turning off DSP during dynamic instantiation. But I guess, this makes only a difference when performing several instantiations at the same time. When DSP is on, each cycle would cause a complete DSP graph recompilation, whereas when DSP is off, it's only recompiled once (after turning it on again). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list
Re: [PD] Fwd: Variable number of objects?
Why would you have control messages going if switch~ is off? Because the voice gets assigned to a certain midi channel when it receives a [noteon] and has to keep receiving all midi controllers on that channel until the envelope release has finished. Then the next voice will play on that same midi channel. There is nothing that cuts off the control inlets or [send/receive]s automatically because the audio gets switched off. So when you play 16 notes in a row all 16 voices are set up to receive control data on that particular midi channel. Everything in the control domain, like LFOs, [metro]s and [line]s keep running and keep calculating pitch, volume, filter offsets and so on ... Turning off the [receive]s would be very complicated if not impossible which is why they need to be avoided wherever it can be done. But all of the wired inlets can be cut off manually together with the [switch~] and turned back on when the next note will play that voice. On top of it all 500 parameters need to be updated to the current state of the external control input and the current preset data when played anew. Ingo -Ursprüngliche Nachricht- Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] Gesendet: Donnerstag, 29. September 2011 19:56 An: Ingo Cc: Jonathan Wilkes; Pd List Betreff: Re: [PD] Fwd: Variable number of objects? On Thu, Sep 29, 2011 at 1:41 PM, Ingo i...@miamiwave.com wrote: One shouldn't underestimate the cpu load when several hundreds of midi controllers per second are modulating hundreds of parameters and the get multiplied by 16 voices constantly because the control messages are still active all of the time. Why would you have control messages going if switch~ is off? J Ingo - Original Message - From: Ingo i...@miamiwave.com To: 'Roman Haefeli' reduz...@gmail.com; 'Ludwig Maes' ludwig.m...@gmail.com Cc: 'Pd List' pd-list@iem.at Sent: Thursday, September 29, 2011 5:33 AM Subject: Re: [PD] Fwd: Variable number of objects? Actually, I just tried again to simply copy a couple of voices and it only took a fraction of a second with a very short dropout - even with the dsp on. I have recently installed Natty instead of Lucid on a new machine. Maybe it has something to do with realloc that Mathieu mentioned. So it looks like dynamic patching of voices isn't that much of a problem here anymore. It still takes 7-8 seconds to create 16 voices in my case with the dsp off (12 with the dsp on) but that's still faster than restarting the patch. I would never have checked again if nobody would have mentioned it. I have attached a patch that I used for testing. These voices were receiving their input with [receive] so no connections were needed. If you are using wired inlets you will have to dynamically add the connections of course. I added a cut paste at the end because for some reasons the voices didn't get initialized correctly. Not sure if this is needed for other voice-abstractions. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Roman Haefeli Gesendet: Donnerstag, 29. September 2011 08:36 An: Ludwig Maes Cc: Pd List Betreff: Re: [PD] Fwd: Variable number of objects? On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote: -- Forwarded message -- From: Ludwig Maes ludwig.m...@gmail.com Date: 28 September 2011 19:29 Subject: Re: [PD] Variable number of objects? To: Ingo i...@miamiwave.com I actually meant more in general, also for non-~ signals (i.e. also control rate .pd patches). I referred to polysynth such that people would see more easily what I meant. Are there really no such primitives? That seems like quite a restriction... How can that take 10 seconds?? I dont see what would cause such a huge overhead, i'd expect an increase in computations memory though (say from 10 voices to 11: 10% increase in cpu workload ram dedicated to these voices..., I fail to see what would necessitate a long initialization...) also, how is it done even with the long delays? As I understand it, the whole DSP is recompiled whenever it is changed. So, if you have a very large patch (and Ingo seems to be an expert in very large patches) and you create another voice, it's easily possible to eat up quite some time. Also, it's probably much slower the first time, if the voice abstraction is built of many other abstractions, which need to be read from disk. But I guess you are right about the increase in CPU workload _after_ the DSP graph has been recompiled: A switch from 10 two 11 instances is expected to show only an increase of 10% in CPU usage. It's been said
Re: [PD] Fwd: Variable number of objects?
I actually do switch off everything possible with a spigot but the [receive]s do still need to check if the [send] message is meant to be for them or not. So once you get too many [receive] objects while sending a lot it CAN slow down the patch quite a bit. But unfortunately that only starts showing up once the patch is so big that it takes forever to replace all of the [receive] objects with wired connections. So for now I'm trying to use wires wherever possible to address data only to the object that needs the data rather than having ten thousands of objects checking hundreds of times per second if the data is meant to be for them or not. Ingo -Ursprüngliche Nachricht- Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] Gesendet: Freitag, 30. September 2011 05:04 An: Ingo Cc: Jonathan Wilkes; Pd List Betreff: Re: [PD] Fwd: Variable number of objects? I see... What I do is put a spigot right after all receives and the spigot is controlled by the same messages that control switch~: [r foo] | [spigot 0] | ... In this way you'll at least stop using all lines and metros and the like. I am not entirely sure that having a receive immediately connected to a [spigot 0] has any computational expense, but if I'm measuring things correctly they don't. So no need to shut off receives, just send them to a closed gate best, J On Thu, Sep 29, 2011 at 10:30 PM, Ingo i...@miamiwave.com wrote: Why would you have control messages going if switch~ is off? Because the voice gets assigned to a certain midi channel when it receives a [noteon] and has to keep receiving all midi controllers on that channel until the envelope release has finished. Then the next voice will play on that same midi channel. There is nothing that cuts off the control inlets or [send/receive]s automatically because the audio gets switched off. So when you play 16 notes in a row all 16 voices are set up to receive control data on that particular midi channel. Everything in the control domain, like LFOs, [metro]s and [line]s keep running and keep calculating pitch, volume, filter offsets and so on ... Turning off the [receive]s would be very complicated if not impossible which is why they need to be avoided wherever it can be done. But all of the wired inlets can be cut off manually together with the [switch~] and turned back on when the next note will play that voice. On top of it all 500 parameters need to be updated to the current state of the external control input and the current preset data when played anew. Ingo -Ursprüngliche Nachricht- Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] Gesendet: Donnerstag, 29. September 2011 19:56 An: Ingo Cc: Jonathan Wilkes; Pd List Betreff: Re: [PD] Fwd: Variable number of objects? On Thu, Sep 29, 2011 at 1:41 PM, Ingo i...@miamiwave.com wrote: One shouldn't underestimate the cpu load when several hundreds of midi controllers per second are modulating hundreds of parameters and the get multiplied by 16 voices constantly because the control messages are still active all of the time. Why would you have control messages going if switch~ is off? J Ingo - Original Message - From: Ingo i...@miamiwave.com To: 'Roman Haefeli' reduz...@gmail.com; 'Ludwig Maes' ludwig.m...@gmail.com Cc: 'Pd List' pd-list@iem.at Sent: Thursday, September 29, 2011 5:33 AM Subject: Re: [PD] Fwd: Variable number of objects? Actually, I just tried again to simply copy a couple of voices and it only took a fraction of a second with a very short dropout - even with the dsp on. I have recently installed Natty instead of Lucid on a new machine. Maybe it has something to do with realloc that Mathieu mentioned. So it looks like dynamic patching of voices isn't that much of a problem here anymore. It still takes 7-8 seconds to create 16 voices in my case with the dsp off (12 with the dsp on) but that's still faster than restarting the patch. I would never have checked again if nobody would have mentioned it. I have attached a patch that I used for testing. These voices were receiving their input with [receive] so no connections were needed. If you are using wired inlets you will have to dynamically add the connections of course. I added a cut paste at the end because for some reasons the voices didn't get initialized correctly. Not sure if this is needed for other voice-abstractions. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Roman Haefeli Gesendet: Donnerstag, 29. September 2011 08:36 An: Ludwig Maes Cc: Pd List Betreff: Re: [PD] Fwd: Variable number of objects? On Wed, 2011-09-28 at 19
Re: [PD] Fwd: Variable number of objects?
I wonder what kind of ears it takes to listen to something so complex... rather, what kind of brain lobes it takes. It takes a regular pair of ears - one on the left side and one on the right side! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Variable number of objects?
If you're going to wire them why not just create specific send messages? Give every abstraction an index and send only to that one: [r $1-foo] | etc J Every [receive] will have to check if any [send] message is meant to be for this particular [receive]. It will have to check if the header of the [send] matches the header of the [receive] until the first character doesn't match anymore. Then it will abort checking and the next [receive] will start checking, and so on ... I can't see how this can be done without taxing the cpu. Having several hundred of messages being sent per second going to several hundred [receives] multiplied by the voice number will add up to many millions of these checks per second. After a certain amount of objects and input data this definitely takes too much time for realtime low latency playing when using high voice counts. It may not affect anything until the number of [send/receive] exceeds a certain number. Getting rid of the [send/receive]s at this point takes a ridiculous amount of time (I'm still not done after several months but getting much better results already). Using dollar arguments only adds a number to the [receive] and doesn't keep it from having to do the checking. That's the reason why I try to avoid [send/receive] objects wherever realtime playing is involved. I still use them, but only for non realtime editing purposes. But there is still a tendency for audio dropouts. Ingo On Sep 30, 2011, at 4:13 AM, Ingo i...@miamiwave.com wrote: I actually do switch off everything possible with a spigot but the [receive]s do still need to check if the [send] message is meant to be for them or not. So once you get too many [receive] objects while sending a lot it CAN slow down the patch quite a bit. But unfortunately that only starts showing up once the patch is so big that it takes forever to replace all of the [receive] objects with wired connections. So for now I'm trying to use wires wherever possible to address data only to the object that needs the data rather than having ten thousands of objects checking hundreds of times per second if the data is meant to be for them or not. Ingo -Ursprüngliche Nachricht- Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] Gesendet: Freitag, 30. September 2011 05:04 An: Ingo Cc: Jonathan Wilkes; Pd List Betreff: Re: [PD] Fwd: Variable number of objects? I see... What I do is put a spigot right after all receives and the spigot is controlled by the same messages that control switch~: [r foo] | [spigot 0] | ... In this way you'll at least stop using all lines and metros and the like. I am not entirely sure that having a receive immediately connected to a [spigot 0] has any computational expense, but if I'm measuring things correctly they don't. So no need to shut off receives, just send them to a closed gate best, J On Thu, Sep 29, 2011 at 10:30 PM, Ingo i...@miamiwave.com wrote: Why would you have control messages going if switch~ is off? Because the voice gets assigned to a certain midi channel when it receives a [noteon] and has to keep receiving all midi controllers on that channel until the envelope release has finished. Then the next voice will play on that same midi channel. There is nothing that cuts off the control inlets or [send/receive]s automatically because the audio gets switched off. So when you play 16 notes in a row all 16 voices are set up to receive control data on that particular midi channel. Everything in the control domain, like LFOs, [metro]s and [line]s keep running and keep calculating pitch, volume, filter offsets and so on ... Turning off the [receive]s would be very complicated if not impossible which is why they need to be avoided wherever it can be done. But all of the wired inlets can be cut off manually together with the [switch~] and turned back on when the next note will play that voice. On top of it all 500 parameters need to be updated to the current state of the external control input and the current preset data when played anew. Ingo -Ursprüngliche Nachricht- Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] Gesendet: Donnerstag, 29. September 2011 19:56 An: Ingo Cc: Jonathan Wilkes; Pd List Betreff: Re: [PD] Fwd: Variable number of objects? On Thu, Sep 29, 2011 at 1:41 PM, Ingo i...@miamiwave.com wrote: One shouldn't underestimate the cpu load when several hundreds of midi controllers per second are modulating hundreds of parameters and the get multiplied by 16 voices constantly because the control messages are still active all of the time. Why would you have control messages going if switch~ is off? J Ingo - Original Message - From: Ingo i...@miamiwave.com To: 'Roman Haefeli' reduz...@gmail.com; 'Ludwig Maes' ludwig.m...@gmail.com
Re: [PD] Fwd: Variable number of objects?
Ok, it looks like I was misunderstanding the way how the [send] / [receive] is working. But then I am still wondering why I got a lot of performance boost after replacing the [send] / [receive] with wired connections? Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von IOhannes m zmölnig Gesendet: Samstag, 1. Oktober 2011 18:18 An: pd-list@iem.at Betreff: Re: [PD] Fwd: Variable number of objects? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/01/2011 04:48 AM, Ingo wrote: Every [receive] will have to check if any [send] message is meant to be for this particular [receive]. It will have to check if the header of the [send] matches the header of the [receive] until the first character doesn't match anymore. Then it will abort checking and the next [receive] will start checking, and so on ... I can't see how this can be done without taxing the cpu. this is not how send/receive work in Pd. in general, Pd's messaging system works in a push manner, where data is pushed from one object to the next, rather than a pull manner, where an object requests a message from the previous one. therefore, [receive] need not care which [send]s are attached to it. then, [send] need not search for attached [receive]s either, because the send-symbol will maintain a linked list of all attached receivers. going through the linked list for dispatching a message is quite fast. gfdstm IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6HPTEACgkQkX2Xpv6ydvQ8bQCfStNUi4fxyCOe2ZK3uvHtN7BG p+oAoNqIIRG/oaeeD7Qjoi2mmgkNXcZV =Chc9 -END PGP SIGNATURE- ___ 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
Re: [PD] Fwd: Variable number of objects?
Actually, I do have a twin brother. I could almost compete with the guy on the picture. Since I am using 3 stereo outs I could maybe top that with around something like six ears. I'll have to see how quickly I can clone myself! I'm not sure if Pd supports cloning of the listener with the current version? Maybe with an abstraction like: [dac~] | \ [ear~ $1] [ear~ $2] Then do some dynamic patching? Ingo -Ursprüngliche Nachricht- Von: Mathieu Bouchard [mailto:ma...@artengine.ca] Gesendet: Montag, 3. Oktober 2011 19:38 An: Ingo Cc: 'Pd List' Betreff: Re: AW: [PD] Fwd: Variable number of objects? Le 2011-10-01 à 04:14:00, Ingo a écrit : I wonder what kind of ears it takes to listen to something so complex... rather, what kind of brain lobes it takes. It takes a regular pair of ears - one on the left side and one on the right side! per head ? how many heads do you have ? e.g. quadraphonic : http://upload.wikimedia.org/wikipedia/en/7/72/Mark_Wing- Davey_as_Zaphod_Beeblebrox.jpg __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bendin-bendout under Linux
-Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Lorenzo Sutton Gesendet: Montag, 3. Oktober 2011 22:25 An: pd-list@iem.at Betreff: Re: [PD] bendin-bendout under Linux On 03/10/2011 20:13, Nicola Pandini wrote: Il 03/10/2011 19:33, Mathieu Bouchard ha scritto: Le 2011-10-03 à 19:29:00, Nicola Pandini a écrit : Hi, I'm trying to build a patch that routes notes, CCs and pitch bend from a keyboard to different synths. Everything is ok for notes and CCs, but I have a problem with the pitch bend. It seems that [bendout] can outputs only a range between 0 and 16384, while the correct range should be -8192 +8192. I tried to force negative values but it seems that bendout can't go below 0. use [- 8192] because 0-8192 = -8192 and because 16383-8192 = 8191 that is, in unsigned values, 8192 is the middle of the range. You right, but I already tried this: #N canvas 93 232 450 300 10; #X obj 82 77 bendin; #X obj 82 102 - 8192; #X obj 82 130 bendout 1; #X connect 0 0 1 0; #X connect 1 0 2 0; And bendout had only a range from 0 to 8192, it didn't go below 0. Strange I tested (with rosegarden and gmidimonitor) on 0.43 and it worked outputting the whole range -8191 to 8192. Lorenzo This depends on how the software is displaying pitchbend. Pd always uses 0 - 16383. MIDI does always transmit 7-bit values from 0 - 127 (except for SysEx). This is a 14-bit message cascaded by two 7-bit messages - each going from 0 - 127. Generally the msb is being used and the lsb is left at 0 (maybe it's the other way around). This means the center value of Pitchbend is 64 0. You can eliminate the second byte by dividing by 128. For displaying the value is offset by 8192 by certain softwares to show negative values. Some people might think it looks more understandable to have the same range going negative or positive for bend down / bend up. But the numbers still go from 0 - 16383. Center is 8192 or 64 0. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bendin-bendout under Linux
I can't really see how 0.42.5 could use or output a different pitchbend range than 0.43. If this was the case all patches using pitchbend would be broken on 0.43 if they were made with an earlier version. I would call that a major disaster. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Nicola Pandini Gesendet: Dienstag, 4. Oktober 2011 10:46 An: pd-list@iem.at Betreff: Re: [PD] bendin-bendout under Linux Il 04/10/2011 06:21, Ingo ha scritto: -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Lorenzo Sutton Gesendet: Montag, 3. Oktober 2011 22:25 An: pd-list@iem.at Betreff: Re: [PD] bendin-bendout under Linux On 03/10/2011 20:13, Nicola Pandini wrote: Il 03/10/2011 19:33, Mathieu Bouchard ha scritto: Le 2011-10-03 à 19:29:00, Nicola Pandini a écrit : Hi, I'm trying to build a patch that routes notes, CCs and pitch bend from a keyboard to different synths. Everything is ok for notes and CCs, but I have a problem with the pitch bend. It seems that [bendout] can outputs only a range between 0 and 16384, while the correct range should be -8192 +8192. I tried to force negative values but it seems that bendout can't go below 0. use [- 8192] because 0-8192 = -8192 and because 16383-8192 = 8191 that is, in unsigned values, 8192 is the middle of the range. You right, but I already tried this: #N canvas 93 232 450 300 10; #X obj 82 77 bendin; #X obj 82 102 - 8192; #X obj 82 130 bendout 1; #X connect 0 0 1 0; #X connect 1 0 2 0; And bendout had only a range from 0 to 8192, it didn't go below 0. Strange I tested (with rosegarden and gmidimonitor) on 0.43 and it worked outputting the whole range -8191 to 8192. Lorenzo This depends on how the software is displaying pitchbend. Pd always uses 0 - 16383. MIDI does always transmit 7-bit values from 0 - 127 (except for SysEx). This is a 14-bit message cascaded by two 7-bit messages - each going from 0 - 127. Generally the msb is being used and the lsb is left at 0 (maybe it's the other way around). This means the center value of Pitchbend is 64 0. You can eliminate the second byte by dividing by 128. For displaying the value is offset by 8192 by certain softwares to show negative values. Some people might think it looks more understandable to have the same range going negative or positive for bend down / bend up. But the numbers still go from 0 - 16383. Center is 8192 or 64 0. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Thanks for all the feedbacks. On Debian Wheezy I tried the following setup: vkeybd - Pd - qmidiroute On 0.42.5, the numbers starts from 0 even with the [- 8192] object. On 0.43, as Lorenzo said, I can get the correct range (-8192 8192), so it seems to be only a 0.42.5 issue. -- Nicola Pandini http://www.cassandraweb.it http://www.myspace.com/thewhitewhisper http://www.myspace.com/cassandraweb ___ 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
Re: [PD] Interruption of audio / Loading sound into array
This might just be a graphics related problem. It's not! Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von David Schaffer Gesendet: Donnerstag, 3. November 2011 12:31 An: pd list Betreff: Re: [PD] Interruption of audio / Loading sound into array Hi, This might just be a graphics related problem. Just disable the graphical representation of the arrays (I'm not in front of Pd right now but If I remeber well, it's just a matter of clicking on the arrays and unchecking the graph on parent box). I had the very same problem under Win XP, it solved everything. Hope this helps. D.S http://www.flickr.com/photos/schafferdavid/ http://audioblog.arteradio.com/David_Schaffer/ From: i...@miamiwave.com To: sebastian.han...@gmx.de; pd-list@iem.at Date: Mon, 31 Oct 2011 19:24:20 +0100 Subject: Re: [PD] Interruption of audio / Loading sound into array [soundfiler] will always interrupt the audio stream. What I have done before was to stream the soundfile into a table with [readsf~]. You can upsample the subpatch with [block~] or [switch~] so it reads faster than realtime. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Sebastian Hanusa Gesendet: Montag, 31. Oktober 2011 18:37 An: pd-list@iem.at Betreff: [PD] Interruption of audio / Loading sound into array Dear List! I have a problem, where hope the solution is so easy as it is complicated for me to find a solution: When I am loading a soundfile (about one 30 seconds, stereo, .aif, 16bit/44100Hz) to an array and simultaneously I have a quite simple audio prozess like replaying a second soundfile with [readsf] + for example a delay and a bandbass I get in the moment of loading to the array a dropout of the audio stream. I tryed to switch off the patch within the array for the moment of loading - but I get the same result. Is there a way to avoid this dropout? I am working with pd_extended 0.42.5 on a MacBook 2 GHz Intel Core 2 Duo, OS X 10.5.8 Thanks a lot for any help and with best regards, Sebastian ___ 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
Re: [PD] clear console command + create folder from Pd?
Thats working now, Tim. I did see already that the [loadbang] was missing. However, working with absolute directories gets really complicated this way. Especially if you want to have the same Patch or abstraction working on several platforms. I would suspect this version might only work on windows correctly? Ingo Von: tim vets [mailto:timv...@gmail.com] Gesendet: Dienstag, 8. November 2011 12:35 An: Ingo Cc: Hans-Christoph Steiner; pd list Betreff: Re: [PD] clear console command + create folder from Pd? 2011/11/8 tim vets timv...@gmail.com 2011/11/8 Ingo i...@miamiwave.com - is there any object that allows to create a folder (in all OSs)? I wanted to save files to a non-existing folder, but Pd doesn't create one. [mkdir $1(--[popen] ? I wonder if that works on Windows? Anyone tested it? Someone could probably make [mkdir] object quite quickly using pdlua or tclpd. .hc I just tested it on WinXP. I could create a directory in the folder of the patch but not a subdirectory. Not sure if it has anything to do with the slash vs. backslash issue. Ah, true, I didn't think of that. I found a workaround though (see attachment), but it's getting absurdly complicated for just doing mkdir... and I forgot to add a loadbang, you have to click the [symbol( connected to [l2s] first... Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 1260 409 345 335 10; #X obj 240 289 popen; #X obj 95 93 makefilename %c; #X obj 67 223 l2s; #X obj 67 161 pack s s s; #X msg 136 206 symbol; #X obj 67 252 prepend mkdir; #X obj 67 289 print; #X msg 95 72 92; #X msg 124 140 symbol testdd; #X msg 67 113 symbol testd; #X obj 67 52 t b b b; #X msg 240 64 mkdir testd; #X obj 67 32 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 89 5 1 make directory 'testd' in current; #X obj 67 6 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 86 28 2 make subdirectory 'testdd' in 'testd'; #X obj 136 186 loadbang; #X connect 1 0 3 1; #X connect 2 0 5 0; #X connect 3 0 2 0; #X connect 4 0 2 1; #X connect 5 0 6 0; #X connect 5 0 0 0; #X connect 7 0 1 0; #X connect 8 0 3 2; #X connect 9 0 3 0; #X connect 10 0 9 0; #X connect 10 1 7 0; #X connect 10 2 8 0; #X connect 11 0 0 0; #X connect 12 0 10 0; #X connect 14 0 11 0; #X connect 16 0 4 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] clear console command + create folder from Pd?
-Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von João Pais Gesendet: Dienstag, 8. November 2011 12:46 An: Hans-Christoph Steiner Cc: PD-List Betreff: Re: [PD] clear console command + create folder from Pd? - is there any object that allows to create a folder (in all OSs)? I wanted to save files to a non-existing folder, but Pd doesn't create one. You could probably use Tcl's mkdir and send it to the GUI: [file mkidr /path/to/mynewfolder( | [hcs/sys_gui] this works, but only if I give a complete path, not a relative one. You could use [ggee/getdir] if you are on Pd-extended. I can get the patche's current path with tof/path, but I read that tof isn't included in the next versions? Is it possible to get the current path through other methods? João Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
Hi everybody, I need some help about sample rate settings. I would like to use my SPDIF Out with Pd. Unfortunately it looks like either the soundcard or the audio system (OSS) starts up with 48,000 Hz while Pd is set to use 44,100 Hz (that's necessary because of the samples being at 44.1k). Does anybody know where or how I can set the PCM sample rate to match Pd's sample rate? None of the soundcard mixers I was checking have an option to set the sample rate and I don't know where the OSS files are located. Thanks! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
Thanks Roman, but no - the soundcard supports up to 192k sampling rate and I do get it to playback at 44.1k every once in a while. When I switch PCM on/off a couple of times all the sudden it starts working correctly. I can see it on my RME-HDSP. It shows 48k at startup with no sound and after switching it on an off and resetting the samplerate in Pd a number of times it picks up the correct sample rate. The HDSP shows 44.1k and there is sound. So it does support 44.1k. The question is: How do I set this samplerate at system startup in Natty? I just read about a way how to do it in OSS4 but I'm still using the older OSS ( OSS 3 ? ) because of the MIDI support. Ingo Hi Ingo On Thu, 2011-11-10 at 13:10 +0100, Ingo wrote: Hi everybody, I need some help about sample rate settings. I would like to use my SPDIF Out with Pd. Unfortunately it looks like either the soundcard or the audio system (OSS) starts up with 48,000 Hz while Pd is set to use 44,100 Hz (that's necessary because of the samples being at 44.1k). Does anybody know where or how I can set the PCM sample rate to match Pd's sample rate? None of the soundcard mixers I was checking have an option to set the sample rate and I don't know where the OSS files are located. I don't know about your soundcard, but many (cheap) soundcards only support 48kHz. You probably won't notice it with ALSA, since ALSA is capable of resampling the sound before pushing it to the card, but if you really are using old-school OSS, I think there is no way to resample. Just in case, you're sound card really only supports 48kHz, would resampling your audio files be an option? At least then you have some control over the resampling quality. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
On 2011-11-10 13:10, Ingo wrote: Hi everybody, I need some help about sample rate settings. I would like to use my SPDIF Out with Pd. Unfortunately it looks like either the soundcard or the audio system (OSS) starts up with 48,000 Hz while Pd is set to use 44,100 Hz (that's necessary because of the samples being at 44.1k). i was going to say: you can change the samplerate of Pd to 48kHz using the Media-Audio menu. it will magically shorten each sample from (1/44.1)ms to (1/48)ms, so you don't need to worry about that. but then, maybe you meant your soundfiles? fgamsdr IOhannes Yep, I was talking about the soundfiles. It's a sample player synth. Changing the samplerate of Pd will detune all instruments. The funny thing is that my older mainboard simply accepted the sample rate from Pd. The new one doesn't. So it looks like it needs to be set up before Pd gets started. This has to be stored within a file somewhere. I've read somewhere that OSS defaults to 48k. So it might actually be the absence of a configuration file which makes it a bit more difficult to find. Analogue outs work normally. Although I suspect there is resampling going on inside the soundcard. It's a realtek. They tend to do stuff like that. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
It's not the HDSP that's causing the problems. It's a realtek onboard souncard. The HDSP was used on another (WinXP) computer and only served as an input to check the output of the linux machine. Ingo Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von tim vets Gesendet: Donnerstag, 10. November 2011 17:15 An: IOhannes m zmoelnig Cc: pd-list@iem.at Betreff: Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS) Concerning your soundcard, you sould have HdspConf installed, no? There you can simply choose the samplerate with buttons. I don't have any experience with SPDIF, but I did recently started using an ADAT (optical) device with the HDSP/Hammerfall, for inputs. In my case, you have to set the ADAT device to 48 or 44.1 with a physical switch on the back, and have the soundcard sync to that. (also a setting in HdspConf) However, it seems like at 44.1kHz it's a lot less stable, it keeps losing sync and resyncing all the time, at least that's what the gui shows, but afaict it has no effect on the sound... Lastly: I wonder if there isn't a way to downsample some subpatches to playback the 44.1kHz soundfiles in a 48kHz environment? gr, Tim 2011/11/10 IOhannes m zmoelnig zmoel...@iem.at -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-10 13:10, Ingo wrote: Hi everybody, I need some help about sample rate settings. I would like to use my SPDIF Out with Pd. Unfortunately it looks like either the soundcard or the audio system (OSS) starts up with 48,000 Hz while Pd is set to use 44,100 Hz (that's necessary because of the samples being at 44.1k). i was going to say: you can change the samplerate of Pd to 48kHz using the Media-Audio menu. it will magically shorten each sample from (1/44.1)ms to (1/48)ms, so you don't need to worry about that. but then, maybe you meant your soundfiles? fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk677vgACgkQkX2Xpv6ydvTm8wCdEhwpG+04NEttfTb2+SPN9Cmg MB0AoIUPlTey1lb5lJ5ji0f4o3fz74e6 =2RQo -END PGP SIGNATURE- ___ 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
Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS) - Problem solved!
Problem solved! There is a switch at the soundcard mixer (I'm using gamix) that is labeled PCM Default Playback Switch. - If OFF it will set the soundcard to 48k - always (OSS default). - When set to ON it will follow the software's sample rate. So, recalling a mixer preset with this switch set to ON and changing the desired sample rate via Pd's audio dialog afterwards does the trick. Since the sample rate is output at start up of Pd the audio dialog needs to be set once more after recalling the mixer preset or the audio mixer preset needs to be loaded before Pd starts. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ingo Gesendet: Donnerstag, 10. November 2011 17:34 An: 'IOhannes m zmoelnig'; pd-list@iem.at Betreff: Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS) On 2011-11-10 13:10, Ingo wrote: Hi everybody, I need some help about sample rate settings. I would like to use my SPDIF Out with Pd. Unfortunately it looks like either the soundcard or the audio system (OSS) starts up with 48,000 Hz while Pd is set to use 44,100 Hz (that's necessary because of the samples being at 44.1k). i was going to say: you can change the samplerate of Pd to 48kHz using the Media-Audio menu. it will magically shorten each sample from (1/44.1)ms to (1/48)ms, so you don't need to worry about that. but then, maybe you meant your soundfiles? fgamsdr IOhannes Yep, I was talking about the soundfiles. It's a sample player synth. Changing the samplerate of Pd will detune all instruments. The funny thing is that my older mainboard simply accepted the sample rate from Pd. The new one doesn't. So it looks like it needs to be set up before Pd gets started. This has to be stored within a file somewhere. I've read somewhere that OSS defaults to 48k. So it might actually be the absence of a configuration file which makes it a bit more difficult to find. Analogue outs work normally. Although I suspect there is resampling going on inside the soundcard. It's a realtek. They tend to do stuff like that. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
I think if you are using a mixed patch with osc and samples only the samples would play correctly and any osc~ might get detuned. Not sure? But anyway, as far as I know you can only up or downsample by the power of two. I did try to use a frequency multiplier of 0.91875 and it was playing in tune but that still gave me a samplerate of 48k at the SPDIF out instead of the 44.1k which was what I wanted. Anyway, I suspect that some instabilities as well as certain losses of sound quality may happen if the sample rate of Pd conflicts with the sample rate of the sound card. This is because of the resampling that the sound card needs to do. So getting Pd's sample rate matched up with the rate of the hardware might have advantages even if you are using only analogue outs. Ingo 2011/11/10 Roman Haefeli reduz...@gmail.com On Thu, 2011-11-10 at 17:14 +0100, tim vets wrote: .. Lastly: I wonder if there isn't a way to downsample some subpatches to playback the 44.1kHz soundfiles in a 48kHz environment? Why would you want to run an [osc~ 440] at a different samplerate, when it plays a 440Hz anyway? Regarding audio samples, you can use [tabread4~] fed by a [line~] instead of [tabplay~] for up- or downsampling. it was just a thought, I can imagine if you would have based some sophisticated sample playback on a whole bunch of tabplay~'s or readsf~'s, that maybe you wouldn't want or have time to change all that... I checked [switch~] again and indeed you can enter 0.5 to downsample by factor 2, does that mean you could enter 0.918750007 to downsample from 48 to 44.1? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
Also, make sure that the Realtek chip does native 44.1... I feed my MOTU card from the SPDIF output of a Creative Audigy* and I had to change my workflow to 48k because the Audigy turned out to fake 44.1 by constant upsampling/downsampling around its fixed-48k DSP. * because the FireWire connection is so fragile and the damn MOTU freezes all the time Andras I used to have lots of sample rate problems with one of the older EMU cards because of that sound chip (back with Windows 98). It's a known problem with the Creative cards which is why I'm staying away from them. They are set to a fixed rate of 48k. The Realtek actually supports all standard rates up to 192k. Which means it simply can't be fixed like the Creative cards. Anyway, after finding the PCM Default Playback Switch and turning it on so it follows the software's sample rate it works fine. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
