Re: [PD] convolution using pd-vanilla
Brute force time domain convolution for small kernel can be done with [fexpr~]. For zero phase filter kernels, fast convolution in Pd is relatively simple. Multiply real and imaginary part of the signal's spectrum with the filter's spectrum while using four times overlap and Hann windowing before FFT and after IFFT, and normalize. Pd's FFT routines assume x[0] at the start of the filter kernel, not at the center, so you have to rotate your zero phase filter kernel before taking it's Fourier Transform. Katja On Mon, May 5, 2014 at 8:49 PM, david medine dmed...@ucsd.edu wrote: For the FFT based convolution, you could easily modify the example patch I06.timbre.stamp.pd to do straight up convolution in the frequency domain. I wouldn't know how to do it in the time domain without an extern or a lot of painstaking work. It might be a nice thing to have, though. I can tell you, though, that the frequency domain method will out perform the time domain in terms of CPU usage. But, since you are windowing there will be a latency. Apart from that, the output is identical by both methods. y(n) = x(n) * g(n) Y(k) = X(k)G(k), y(n) = IDFT(Y(k)) where g(n) is the impulse response, X(k) is the discrete Fourier transform of x(n) and * is the convolution operation. On 05/05/2014 09:33 AM, Oli Larkin wrote: hi, is anyone aware of an example of both a brute force time domain (e.g. buffir~ in Max) and an FFT-based fast convolution patch in pd-vanilla? I would like to do a comparison of the two. Can be using a small IR, just for demo purposes. cheers, Oli ___ 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] SOLVED!!! Re: pitch to voltage SOLVED!!!
Hi Simon, Maybe it's just me but I did not find an attachment with your last post. By the way I found a bug in my upsampling method: apparently, [samplerate~] in a resampled subpatch needs some time before it reports the correct samplerate, therefore the subpatch used wrong values for filter frequency occasionally, which causes nonsense output. Attached is a fixed version. In the meantime I was wondering if upsampling is needed at all for accuracy. As Miller mentioned earlier, the error from truncating to integer nr of samples can be substantial. Attached patch 'errorsample' calculates that error and as you would expect, the error (expressed in cents) increases with frequency. However, in our patches I can't hear the error! Even if the unsig'ed frequency value shows fluctuation, the sound is stable. For comparison, you could control [phasor~] with the unsig'ed value, then you'll hear what the error really sounds like. So why don't we hear that when [phasor~] is controlled by the tilde objects? Is the fluctuation so fast that we hear an 'average'? No, the fluctuations are often not so fast (which you can verify with a [print~] object). Seems we're just lucky that it works this way, but oh how annoying it is to not understand your own patches. Katja On Wed, Apr 30, 2014 at 12:49 AM, Simon Iten itensi...@gmail.com wrote: hi katja, i tried your patch and had a look at it. it’s beautifully programmed :-) so skilled. thanks for taking the time and it’s very interesting to see a different style and different thinking to get to the “same” outcome. i tried (with a different version of the patch) just to replace osc~ with adc~ and sang into my macbook microphone. there is no octave jumping exept for the very low notes i can sing :-) attached is a simple version with a little filtering. it’s not tested at all but this is how i did it for bass. (with other values for hip and lop of course) note that there is a lot of noise when you don’t sing or sing to quietly, this is because you amplify the shit out of the signal. so to use this you will need to add envelope following and a gate. when i tried this simple solution with your upsampled patch i got nothing :-) the signal just freezes at some high value. but i’m probably missing something very basic. cheers, simon On 29 Apr 2014, at 21:10, katja katjavet...@gmail.com wrote: Hi Simon, I'd be curious to see this adaptive filtering work in practice. Could you share a patch, once you have that working? Vocals mostly don't exceed a 3 octave range either. Only thing is, in vocals the strongest component is sometimes not the first harmonic but the second, when speaking or singing the lowest notes in the range. Katja On Tue, Apr 29, 2014 at 7:58 PM, Simon Iten itensi...@gmail.com wrote: katja, exactly! i filter the input based on the output of the pitch detection. i used this for quite some time with my doublebass (but with a pickup per string) and it works perfectly. i get no octave jumps or glitches at all. the version i shared here is planned to be used for vocals, i have to see if it works as good… the trick is not to filter too much in order to “let through” new notes but enough to filter out strong overtones (mainly octaves). it also helps to have filters in parallel. and of course you cut the range before that in order to fit your input. on a bass string this is very easy since on a double-bass you have a 3 octave range per string you can cut many frequencies before even starting filtering. this is how i did it and it worked. i adapted this system from the gr300 also. there it’s even easier. just two filters per string. one in the lower section (0-7th fret and one from 7-22 fret) they get switched via transistors based on the output voltage of the p/v circuit. they are 2nd order bandpass filters. cheers, simon On 29 Apr 2014, at 19:37, katja katjavet...@gmail.com wrote: Hi Simon, See attachment for an upsampled version. I used a 6th order lo pass filter with cut off at 1/4 of the original sampling rate. This seems to work with max. 8 times upsampling. Period length error is then limited to 1/8 sample. You mentioned adaptive filtering of a real life input signal. Are you planning to control filter cut off frequency with the pitch detection result? Did you already try that? I wonder how that could work at all, because the pitch result comes only after the adaptive filter. Katja On Tue, Apr 29, 2014 at 3:44 PM, Simon Iten itensi...@gmail.com wrote: Katja thanks for your Inputs! Will Look at the Patch tonight. Simple lowpass Filtering? I tried to upsample with a Block object but the biquad object stopped outputting Pulses. If you don't mind doing a Version with upsampling that would be fantastic. Well i just copied from the Gr300 schematic, so no credits for me :) Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com: Hi Simon, So your method
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
Hi Simon, So your method counts samples per (zero-crossing) cycle, is what I learned from studying the patch. Very nice how you do this with tilde objects. It seems possible to get equivalent result with only one [rpole~], when using the positive pulse as trigger for [samphold~] and with two samples delay for [rpole~]. You get the integrator's maximum everytime. See attached patch. Of course it still counts integer number of samples. Upsampling would indeed improve accuracy. An upsampled signal needs filtering to remove spectral images, did you try that? Katja On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote: nice changes with expr~ ! but i think you missed the point of the beginning of the patch. read in my first e-mail for an explanation of what this patch does exactly. it is an gr300 analog guitar synthesizer clone (well one voice of it). it is intended for real-life signals so there needs to be an adaptive filter in the beginning (with the pitch info we get from the two rpole~ objects) and the signal needs to be squared to get the longest possible sustain (envelope is re added later obviously). also i think response is faster when squared, or not? thanks for the changes, greatly appreciated! simon Well i know exactly what the Patch does... I just dont know why the two numbers before the Addition Need to be -1 And -2 :-) Will Look at your Version asap. Cheers Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com: I have no idea what the patch is doing either, but I was able to clean it a lot. many things that didn't need to be there cheers 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com: roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr~] and all of them actually don't need [fexpr~] functionality. I experienced that [fexpr~] is quite expensive, which seems apparent considering it is designed for feedback algorithms. I don't know if [fexpr~] is also expensive when you use it not for feedbacks as your patch does. Anyway, you could replace them by likely less expensive [expr~] instances: [fexpr~ $x1=0] - [expr~ $v1=0] Roman On Mon, 2014-04-28 at 00:59 +0200, simon wrote: hey miller and list, find attached a version that works beautifully. it's a dirty hack without upsampling but it works extremly well. don't ask me why, i have no idea. thanks for all the help miller, really appreciate it! and thanks for pd in general :-) cheers, simon On Apr 27, 2014, at 8:59 PM, Simon Iten wrote: sorry this one went off-list :-) On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote: sure, here is the version with biquad in a subpatch with a block opject to upsample. probably i'm doing something wrong, i just copied from the block help-patch. sinetosawtoothupsample.pd On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote: Drat, I don't have any explanation for this... can you send me the patch again? cheers M On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote: hmm, changing change to biquad does also not work. i mean it does as long as i don't upsample in the subpatch. as soon as i change the block object i get square instead of pulses... On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote: Actually I don't know where the change~ object is from - I've nver seen t before. I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply ubtracts the previous sample from teh current one as I guessed from the patch :) M On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote: ok tried to upsample the whole thing (after the osc~) and now change~ does nothing anymore… it just spits out the same square wave i feed in…clues? On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote: crosspost! sorry about the noise. thanks for the inputs i will try to to this. not sure if i can. otherwise i will ask back if that’s ok! On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote: so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
Hi Simon, See attachment for an upsampled version. I used a 6th order lo pass filter with cut off at 1/4 of the original sampling rate. This seems to work with max. 8 times upsampling. Period length error is then limited to 1/8 sample. You mentioned adaptive filtering of a real life input signal. Are you planning to control filter cut off frequency with the pitch detection result? Did you already try that? I wonder how that could work at all, because the pitch result comes only after the adaptive filter. Katja On Tue, Apr 29, 2014 at 3:44 PM, Simon Iten itensi...@gmail.com wrote: Katja thanks for your Inputs! Will Look at the Patch tonight. Simple lowpass Filtering? I tried to upsample with a Block object but the biquad object stopped outputting Pulses. If you don't mind doing a Version with upsampling that would be fantastic. Well i just copied from the Gr300 schematic, so no credits for me :) Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com: Hi Simon, So your method counts samples per (zero-crossing) cycle, is what I learned from studying the patch. Very nice how you do this with tilde objects. It seems possible to get equivalent result with only one [rpole~], when using the positive pulse as trigger for [samphold~] and with two samples delay for [rpole~]. You get the integrator's maximum everytime. See attached patch. Of course it still counts integer number of samples. Upsampling would indeed improve accuracy. An upsampled signal needs filtering to remove spectral images, did you try that? Katja On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote: nice changes with expr~ ! but i think you missed the point of the beginning of the patch. read in my first e-mail for an explanation of what this patch does exactly. it is an gr300 analog guitar synthesizer clone (well one voice of it). it is intended for real-life signals so there needs to be an adaptive filter in the beginning (with the pitch info we get from the two rpole~ objects) and the signal needs to be squared to get the longest possible sustain (envelope is re added later obviously). also i think response is faster when squared, or not? thanks for the changes, greatly appreciated! simon Well i know exactly what the Patch does... I just dont know why the two numbers before the Addition Need to be -1 And -2 :-) Will Look at your Version asap. Cheers Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com: I have no idea what the patch is doing either, but I was able to clean it a lot. many things that didn't need to be there cheers 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com: roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr~] and all of them actually don't need [fexpr~] functionality. I experienced that [fexpr~] is quite expensive, which seems apparent considering it is designed for feedback algorithms. I don't know if [fexpr~] is also expensive when you use it not for feedbacks as your patch does. Anyway, you could replace them by likely less expensive [expr~] instances: [fexpr~ $x1=0] - [expr~ $v1=0] Roman On Mon, 2014-04-28 at 00:59 +0200, simon wrote: hey miller and list, find attached a version that works beautifully. it's a dirty hack without upsampling but it works extremly well. don't ask me why, i have no idea. thanks for all the help miller, really appreciate it! and thanks for pd in general :-) cheers, simon On Apr 27, 2014, at 8:59 PM, Simon Iten wrote: sorry this one went off-list :-) On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote: sure, here is the version with biquad in a subpatch with a block opject to upsample. probably i'm doing something wrong, i just copied from the block help-patch. sinetosawtoothupsample.pd On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote: Drat, I don't have any explanation for this... can you send me the patch again? cheers M On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote: hmm, changing change to biquad does also not work. i mean it does as long as i don't upsample in the subpatch. as soon as i change the block object i get square instead of pulses... On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote: Actually I don't know where the change~ object is from
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
Hi Simon, I'd be curious to see this adaptive filtering work in practice. Could you share a patch, once you have that working? Vocals mostly don't exceed a 3 octave range either. Only thing is, in vocals the strongest component is sometimes not the first harmonic but the second, when speaking or singing the lowest notes in the range. Katja On Tue, Apr 29, 2014 at 7:58 PM, Simon Iten itensi...@gmail.com wrote: katja, exactly! i filter the input based on the output of the pitch detection. i used this for quite some time with my doublebass (but with a pickup per string) and it works perfectly. i get no octave jumps or glitches at all. the version i shared here is planned to be used for vocals, i have to see if it works as good… the trick is not to filter too much in order to “let through” new notes but enough to filter out strong overtones (mainly octaves). it also helps to have filters in parallel. and of course you cut the range before that in order to fit your input. on a bass string this is very easy since on a double-bass you have a 3 octave range per string you can cut many frequencies before even starting filtering. this is how i did it and it worked. i adapted this system from the gr300 also. there it’s even easier. just two filters per string. one in the lower section (0-7th fret and one from 7-22 fret) they get switched via transistors based on the output voltage of the p/v circuit. they are 2nd order bandpass filters. cheers, simon On 29 Apr 2014, at 19:37, katja katjavet...@gmail.com wrote: Hi Simon, See attachment for an upsampled version. I used a 6th order lo pass filter with cut off at 1/4 of the original sampling rate. This seems to work with max. 8 times upsampling. Period length error is then limited to 1/8 sample. You mentioned adaptive filtering of a real life input signal. Are you planning to control filter cut off frequency with the pitch detection result? Did you already try that? I wonder how that could work at all, because the pitch result comes only after the adaptive filter. Katja On Tue, Apr 29, 2014 at 3:44 PM, Simon Iten itensi...@gmail.com wrote: Katja thanks for your Inputs! Will Look at the Patch tonight. Simple lowpass Filtering? I tried to upsample with a Block object but the biquad object stopped outputting Pulses. If you don't mind doing a Version with upsampling that would be fantastic. Well i just copied from the Gr300 schematic, so no credits for me :) Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com: Hi Simon, So your method counts samples per (zero-crossing) cycle, is what I learned from studying the patch. Very nice how you do this with tilde objects. It seems possible to get equivalent result with only one [rpole~], when using the positive pulse as trigger for [samphold~] and with two samples delay for [rpole~]. You get the integrator's maximum everytime. See attached patch. Of course it still counts integer number of samples. Upsampling would indeed improve accuracy. An upsampled signal needs filtering to remove spectral images, did you try that? Katja On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote: nice changes with expr~ ! but i think you missed the point of the beginning of the patch. read in my first e-mail for an explanation of what this patch does exactly. it is an gr300 analog guitar synthesizer clone (well one voice of it). it is intended for real-life signals so there needs to be an adaptive filter in the beginning (with the pitch info we get from the two rpole~ objects) and the signal needs to be squared to get the longest possible sustain (envelope is re added later obviously). also i think response is faster when squared, or not? thanks for the changes, greatly appreciated! simon Well i know exactly what the Patch does... I just dont know why the two numbers before the Addition Need to be -1 And -2 :-) Will Look at your Version asap. Cheers Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com: I have no idea what the patch is doing either, but I was able to clean it a lot. many things that didn't need to be there cheers 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com: roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr
Re: [PD] pd-double and libraries
Oops, it seems the pd-double genie popped out of it's bottle. I'm sorry to say, but there is no such list of libraries to use with pd-double. There's a lot of issues with this project: 1 - pd-double currently lives as an unmaintained fork of vanilla pd 0.43 2 - pd-double works for OSX and Linux but not yet for Windows 3 - original authors of pd-extended libs have little interest in making their libs ready for double precision 4 - many libs in pd-extended are not maintained by their original authors at all 5 - I don't like to poke in other people's libs unless I fully understand the code In short, the pd-double project is in coma because it was too ambitious for the available workforce. If it is to be reanimated, it would be better to develop a set of patch files for pd core and test extensively on all platforms where pd can run, before touching on externals. Katja On Sat, Mar 1, 2014 at 3:00 PM, Jack j...@rybn.org wrote: Hello Katja, I just try pd-double, and I have to say it is very nice to play long soundfile with [soundfiler] :) Where can i find list of libraries that use double float that i can use with pd-double ? ++ Jack ___ 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] Bugs in Pd-Extended in Ubuntu LTS
Hi Pierre, I'm on Xubuntu 12.04 with Pd-extended 0.44 and have experienced big troubles with Jack too. I only use Jack for complex routings like Skype to Pd or Kdenlive to Pd via PulseAudio+Jack. I got a lot of jackdbus-errors initially, and jack wouldn't restart. Don't know if it's the same issue which you're experiencing. Anyway, it seems that this was about jackd2 writing config files to different places, which can be out of sync under certain conditions. Not sure if this is a correct description but it is my interpretation. Looking at running processes in command htop, I always noticed a jackdbus processing still running when the dbus error was given. Killing the jackdbus process sometimes helped. But in the course of time I've somehow learned how to avoid it at all, by carefully considering the right order of operations when starting processes. I have PulseAudio disabled by default, so I can start Jack first, then the Jack clients, of which PulseAudio may be one. Then eventually the PulseAudio clients. When killing processes, everything in reverse order. I don't like this hocus pocus, but well, I'm happy if it works at all. On Kubuntu I couldn't get PulseAudio to cooperate with Jack. Katja On Tue, Feb 25, 2014 at 9:33 PM, Pierre Massat pimas...@gmail.com wrote: I just checked again and to to sum up I have three problems : - errors with JACK (and instability), - X crashes sometimes when typing stuff in an object box, - and Alsa throwing this error in the console : ALSA output error (restart failed): Broken pipe (though the sound does work). Pierre. 2014-02-25 21:23 GMT+01:00 Cyrille Henry c...@chnry.net: Le 25/02/2014 21:03, Roman Haefeli a écrit : On Die, 2014-02-25 at 19:50 +0100, Pierre Massat wrote: I have installed Pd-extended from the Ubuntu repos. It seems to be the same version as the one available on puredata.info (0.43.4). I am pretty sure there is no package called 'pd-extended' in the Ubuntu repositories. Probably you got it from Hans' ppa or from apt.puredata.info? Also, is your Ubuntu 12.04 up-to-date? Your bug description sounds like an intel driver bug in 13.04 or 13.10 that has been discussed a lot on this list. I thought this bug has been fixed for quite a while. i still have some problem. (i'm on 13.10). X can crash specially if i have object that are not created on the patch. c 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 ___ 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] smooth random numbers
On Sat, Feb 22, 2014 at 10:54 PM, Pagano, Patrick p...@digitalworlds.ufl.edu wrote: Hello i have asked this is a few different ways and experimented but i am wondering, how does one create smooth random numbers that flow between each number instead of hoping from number to number? When trying to translate the settings of a 10 band graphic equalizer to a smooth spectrum I had a similar issue for which I used cubic interpolation in three steps. The first two steps involves factor 2 'upsampling' each, which renders a 40 point (+interpolation points) curve smooth enough for interpolation to 1024 points in one last step. Attached patch cubic_upsampling.pd shows the interpolation steps done on a sequence of random numbers. Katja #N canvas 143 79 708 617 10; #N canvas 328 438 667 277 stretch 0; #X obj 17 178 tabread4 \$0-ampsettings; #X obj 17 205 tabwrite \$0-stretched-settings; #X obj 228 97 t f f; #X obj 228 125 / 2; #X obj 228 178 tabread4 \$0-stretched-settings; #X obj 228 205 tabwrite \$0-stretched-settings2; #X obj 433 100 t f f; #X obj 433 74 for++ 0 1024; #X obj 433 180 tabread4 \$0-stretched-settings2; #X obj 433 206 tabwrite \$0-stretched-settings3; #X obj 433 127 / 25.6; #X obj 433 153 + 2; #X obj 17 78 t f f; #X obj 17 138 / 2; #X obj 228 57 for++ 0 43; #X obj 17 14 inlet; #X text 305 11 Intermediate tables \$0-stretched-settings and \$0-stretched-settings2 each have 3 points extra for cubic interpolation.; #X obj 17 40 for++ 0 23; #X connect 0 0 1 0; #X connect 2 0 3 0; #X connect 2 1 5 1; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 6 0 10 0; #X connect 6 1 9 1; #X connect 7 0 6 0; #X connect 8 0 9 0; #X connect 10 0 11 0; #X connect 11 0 8 0; #X connect 12 0 13 0; #X connect 12 1 1 1; #X connect 13 0 0 0; #X connect 14 0 2 0; #X connect 14 1 7 0; #X connect 15 0 17 0; #X connect 17 0 12 0; #X connect 17 1 14 0; #X restore 60 338 pd stretch; #N canvas 485 132 310 415 write-settings 0; #X msg 165 345 arrayviewlistnew; #X obj 165 374 s \$0-ampsettings; #N canvas 1 79 450 300 (subpatch) 0; #X array \$0-ampsettings 13 float 2; #X coords 0 1 13 0 200 100 1 0 0; #X restore 69 225 graph; #X obj 56 23 inlet; #X obj 56 49 unpack; #X obj 70 178 tabwrite \$0-ampsettings; #X obj 70 148 max 0; #X obj 31 375 outlet; #X text 80 375 done; #X obj 89 95 + 1; #X obj 31 94 t b f f; #N canvas 358 356 357 340 copy 0; #X obj 35 13 inlet; #X obj 35 240 tabread \$0-ampsettings; #X obj 35 269 tabwrite \$0-ampsettings; #X obj 88 13 inlet; #X obj 35 62 f; #X obj 35 90 sel 1 10; #X obj 35 210 unpack; #X msg 35 184 1 0; #X obj 91 173 tabread \$0-ampsettings; #X obj 91 202 tabwrite \$0-ampsettings; #X obj 91 143 unpack; #X text 146 103 copy from index 10 to 11 and 12; #X text 182 238 copy from index 1 to 0; #X text 33 300 copy values so [tabread4] can interpolate later; #X msg 91 107 10 11 \, 10 12; #X obj 35 39 bang; #X connect 0 0 15 0; #X connect 1 0 2 0; #X connect 3 0 4 1; #X connect 4 0 5 0; #X connect 5 0 7 0; #X connect 5 1 14 0; #X connect 6 0 1 0; #X connect 6 1 2 1; #X connect 7 0 6 0; #X connect 8 0 9 0; #X connect 10 0 8 0; #X connect 10 1 9 1; #X connect 14 0 10 0; #X connect 15 0 4 0; #X restore 50 121 pd copy; #X text 101 120 copy if index 1 or 10; #X text 114 94 shift index number; #X text 97 23 list: RMS value + slider index; #X connect 0 0 1 0; #X connect 3 0 4 0; #X connect 4 0 10 0; #X connect 4 1 9 0; #X connect 6 0 5 0; #X connect 9 0 5 1; #X connect 9 0 11 1; #X connect 10 0 7 0; #X connect 10 1 11 0; #X connect 10 2 6 0; #X restore 60 313 pd write-settings; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-randomnumbers 10 float 2; #X coords 0 1 10 0 200 100 1 0 0; #X restore 457 24 graph; #X obj 26 182 random 100; #X obj 26 210 / 100; #X obj 26 94 until; #X obj 26 123 f; #X obj 26 40 t b b; #X obj 26 153 t b f; #X msg 26 66 10; #X msg 65 94 0; #X obj 26 15 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 26 240 tabwrite \$0-randomnumbers; #X obj 59 123 + 1; #X obj 60 289 pack; #N canvas 1 73 450 300 (subpatch) 0; #X array \$0-stretched-settings 23 float 2; #X coords 0 1 23 0 200 100 1 0 0; #X restore 457 160 graph; #N canvas 1 73 450 300 (subpatch) 0; #X array \$0-stretched-settings2 43 float 2; #X coords 0 1 43 0 200 100 1 0 0; #X restore 458 318 graph; #N canvas 1 79 450 300 (subpatch) 0; #X array \$0-stretched-settings3 1024 float 2; #X coords 0 1 1024 0 200 100 1 0 0; #X restore 459 474 graph; #X text 53 14 generate random numbers; #X text 465 261 upsampled 2 times; #X text 475 419 upsampled 4 times; #X text 472 574 upsampled 102.4 times; #X text 21 461 Katja Vetter Feb. 2014; #X text 20 384 Smooth 'upsampling' of a random number series by cubic interpolation. The first two stages must be factor 2 upsampling each. After that \, the curve is smooth enough for arbitrary upsampling factors. ; #X connect 1 0 0 0; #X connect 3 0 4 0; #X connect 4 0 12 0; #X connect 4 0 14 0; #X connect 5 0 6 0; #X connect 6 0 8 0; #X connect 6 0 13 0; #X connect 7 0 9 0; #X connect 7 1 10 0
Re: [PD] how to specify literals as type t_float
Hi Miller, My intention is to write Pd code in such a way that it is maximally efficient for tiny computers which aren't fond of doubles (RPi and friends), while keeping the option open to compile with maximum precision for fast machines. The advent of RPi has prompted me to focus more on efficiency, even though I rarely use a Pi myself. Reckoning with ARM, I guess we're sort of back in the days of Pentium 2 when it comes to precious clock cycles (but I didn't program C at that time). Overlooked precision conversions happen so easily. Here is an example from tabread4~ in d_array.c: *out++ = b + frac * ( cminusb - 0.167f * (1.-frac) * ( (d - a - 3.0f * cminusb) * frac + (d + 2.0f*a - 3.0f*b) ) ); All literals have float suffixes, except in (1.-frac). So here is a double which makes the compiler do the first half of the interpolation routine on the FPU with extended precision (on Linux i386). A few years ago I wouldn't have noticed it, and my own code my be full of unspecified literals. That's what I want to repair now. Not by adding the regular float specifier 'f' though, since that would defy the purpose of Pd's own float type definition. Katja On Tue, Feb 11, 2014 at 6:39 AM, Miller Puckette m...@ucsd.edu wrote: Hi Katya - I think there's no simpler way. On the other hand, for constants like 0.125 and 2, it would be equivalent to say 0.125f, etc - but for other constants (1/3 for example), casting as t_float would be more accurate in case t_float is set to double. I think people rarely use t_float as higher precision than 32 bits though, and even if they did the difference between (t_float)1/(t_float)3 and 1.f/3.f is pretty small. cheers Miller On Mon, Feb 10, 2014 at 10:53:02PM +0100, katja wrote: Hello, When working on parabolic interpolation in a Pd class, I wondered again what is the best method to specify literal constants as Pd's type t_float (which could be float or double). The interpolation goes like: ... t_float a = buf[peakindex-1]; t_float b = buf[peakindex]; t_float c = buf[peakindex+1]; t_float realpeak; realpeak = b + 0.125 * (c - a) * (c - a) / (2. * b - a - c); ... Without float suffixes for the literals, single precision t_float variables would be promoted to double here, which would be an unintended waste of CPU cycles. For some time, I've worked around this by using const variables instead of literals, like: ... const t_float two = 2.; const t_float eighth = 0.125; t_float a = buf[peakindex-1]; t_float b = buf[peakindex]; t_float c = buf[peakindex+1]; t_float realpeak; realpeak = b + eighth * (c - a) * (c - a) / (two * b - a - c); ... While this avoids redundant type conversions, it clutters the code and does not result in such fast instructions as literals do. Therefore I am now using type casts where type specifiers are normally used: ... t_float a = buf[peakindex-1]; t_float b = buf[peakindex]; t_float c = buf[peakindex+1]; t_float realpeak; realpeak = b + (t_float)0.125 * (c - a) * (c - a) / ((t_float)2. * b - a - c); ... For the above code I have checked assembly output as generated by GCC with -O3 optimization on Linux i386. Using literals without type specification, the whole routine is done on the FPU (80 bits precision). With the literals cast to t_float, it is done with single precision instructions for XMM registers. As far as I can see, casting literals to t_float results in the same assembly output as using the float specifier. For single precision t_float, '(t_float)0.125' is equivalent to '0.125f'. I can't think of a disadvantage, but let me know if I overlooked something. Katja ___ 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] how to specify literals as type t_float
Hello, When working on parabolic interpolation in a Pd class, I wondered again what is the best method to specify literal constants as Pd's type t_float (which could be float or double). The interpolation goes like: ... t_float a = buf[peakindex-1]; t_float b = buf[peakindex]; t_float c = buf[peakindex+1]; t_float realpeak; realpeak = b + 0.125 * (c - a) * (c - a) / (2. * b - a - c); ... Without float suffixes for the literals, single precision t_float variables would be promoted to double here, which would be an unintended waste of CPU cycles. For some time, I've worked around this by using const variables instead of literals, like: ... const t_float two = 2.; const t_float eighth = 0.125; t_float a = buf[peakindex-1]; t_float b = buf[peakindex]; t_float c = buf[peakindex+1]; t_float realpeak; realpeak = b + eighth * (c - a) * (c - a) / (two * b - a - c); ... While this avoids redundant type conversions, it clutters the code and does not result in such fast instructions as literals do. Therefore I am now using type casts where type specifiers are normally used: ... t_float a = buf[peakindex-1]; t_float b = buf[peakindex]; t_float c = buf[peakindex+1]; t_float realpeak; realpeak = b + (t_float)0.125 * (c - a) * (c - a) / ((t_float)2. * b - a - c); ... For the above code I have checked assembly output as generated by GCC with -O3 optimization on Linux i386. Using literals without type specification, the whole routine is done on the FPU (80 bits precision). With the literals cast to t_float, it is done with single precision instructions for XMM registers. As far as I can see, casting literals to t_float results in the same assembly output as using the float specifier. For single precision t_float, '(t_float)0.125' is equivalent to '0.125f'. I can't think of a disadvantage, but let me know if I overlooked something. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] New Blankets Pd Cali weekend (was) Re: It's too quiet in here
Hi, a first video from Pd weekend is edited and archived. It shows a try out of my wearable live sampling stuff in Miller's class. http://newblankets.org/video/katja_MUS170.webm You can play this video streaming in VLC like so: - right click on the link and copy link location - in VLC, click Media Open Network Stream tab Network - paste link in the network URL field and click Play Or alternatively, there's: http://www.youtube.com/watch?v=giJ-Ss6QRJo Katja On Fri, Nov 22, 2013 at 9:10 PM, Julian Brooks jbee...@gmail.com wrote: Hey Katja, Good to hear. Are you back now? Very much looking forward to checking your mobile wearable stuff - the photo looked fantastic (you should post it it is very cool:). And the mic building workshop etc etc On 22 November 2013 19:55, katja katjavet...@gmail.com wrote: Julian, there's ton's of California Pd weekend video material (presentations, discussions, workshops, live performance) but it must be viewed, edited, compressed etcetera. I would expect that it will be available at newblankets.org in a while. Katja On Fri, Nov 22, 2013 at 10:15 AM, Julian Brooks jbee...@gmail.comwrote: Right on indeed. I for one am very much looking forward to poring over the (hopefully vast) documentation generated over the Cali Pd weekend of events. Did look very cool. Any news on that front? And Phil - The list has been quiet over the last week or so but definitely traffic going on all through Nov. Perhaps an issue with your mailer? All the best, Julian On 21 November 2013 21:33, Phil Stone pkst...@ucdavis.edu wrote: On 11/21/13 1:13 PM, Jonathan Wilkes wrote: On 11/21/2013 02:04 PM, Phil Stone wrote: Hmm, this once-thriving list has gone awfully silent of late. Is this thing on? tap tap I had the pleasure of meeting, for the first time, several august members of the Pd community this past weekend, thanks to Joe Deken and New Blankets gathering some of us together in San Diego and Los Angeles. Miller, Roman, Ivica, Jonathan, (and Katja -- I didn't do more than say hi, sorry) I just wanted to say that I am grateful to be involved in a group of such talented and humble people, and constantly marvel at what a powerful tool has been placed into my hands, at no cost. May Pd never die! Hi Phil, It was great to meet you! Personally I've been sending diffs to Ivica to get some stuff into Pd-l2ork, so that some of the features I showed in my workshop will work out of the box. Best, Jonathan I'm keeping a sharp eye on your work with Pd-l2ork on OS X, Jonathan. It looks like such an excellent environment, I really want to work in it. For one thing, I've heard all the many good arguments for straight, unsegmented patch cords, but I don't think I'd ever get tired of seeing splined patch cords in my patches! Having seen both, I'd say splines work better in all ways. BTW, regarding the title of this thread; I just searched the archives and realized that I hadn't gotten any messages since Nov. 6. After my post today, I'm getting them again. Anybody else had any glitches in getting list messages, or is it something local for me? Phil ___ 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] It's too quiet in here
Julian, there's ton's of California Pd weekend video material (presentations, discussions, workshops, live performance) but it must be viewed, edited, compressed etcetera. I would expect that it will be available at newblankets.org in a while. Katja On Fri, Nov 22, 2013 at 10:15 AM, Julian Brooks jbee...@gmail.com wrote: Right on indeed. I for one am very much looking forward to poring over the (hopefully vast) documentation generated over the Cali Pd weekend of events. Did look very cool. Any news on that front? And Phil - The list has been quiet over the last week or so but definitely traffic going on all through Nov. Perhaps an issue with your mailer? All the best, Julian On 21 November 2013 21:33, Phil Stone pkst...@ucdavis.edu wrote: On 11/21/13 1:13 PM, Jonathan Wilkes wrote: On 11/21/2013 02:04 PM, Phil Stone wrote: Hmm, this once-thriving list has gone awfully silent of late. Is this thing on? tap tap I had the pleasure of meeting, for the first time, several august members of the Pd community this past weekend, thanks to Joe Deken and New Blankets gathering some of us together in San Diego and Los Angeles. Miller, Roman, Ivica, Jonathan, (and Katja -- I didn't do more than say hi, sorry) I just wanted to say that I am grateful to be involved in a group of such talented and humble people, and constantly marvel at what a powerful tool has been placed into my hands, at no cost. May Pd never die! Hi Phil, It was great to meet you! Personally I've been sending diffs to Ivica to get some stuff into Pd-l2ork, so that some of the features I showed in my workshop will work out of the box. Best, Jonathan I'm keeping a sharp eye on your work with Pd-l2ork on OS X, Jonathan. It looks like such an excellent environment, I really want to work in it. For one thing, I've heard all the many good arguments for straight, unsegmented patch cords, but I don't think I'd ever get tired of seeing splined patch cords in my patches! Having seen both, I'd say splines work better in all ways. BTW, regarding the title of this thread; I just searched the archives and realized that I hadn't gotten any messages since Nov. 6. After my post today, I'm getting them again. Anybody else had any glitches in getting list messages, or is it something local for me? Phil ___ 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] tanh() or a compressor?
Hi Mario, Did you try [zexy/limiter~]? It's not so CPU-intensive. Isn't that what you want: only attenuate the sounds which exceed a limit, and leave the rest untouched? Katja On Tue, Oct 1, 2013 at 4:30 PM, Mario Mey mario...@gmail.com wrote: How does Pd or the soundcard outputs the signal 1? Does it compress it? I started this thread because I saw the high peaks in an array... but I never listened the sound distorted. __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list 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] alsa and jack on ARM/Wandbaord
Hello Chris, It may be unrelated but with Debian Squeeze on particular Intel laptops (Panasonic CF-74 and CF-19) I've always experienced that same problem: recording works, playback works, but no duplex sound from Pd or Jack out of the box. In these cases it was a matter of unchecking as many unused options as possible in the ALSA mixer, in particular 'IEC958 Default PCM' (don't know if you have that option). That used to make the difference every time though I still don't know why. Katja On Sun, Sep 22, 2013 at 9:00 PM, Chris Clepper cgclep...@gmail.com wrote: I've got a Wandboard* here for some testing and I can't get Alsa to work in duplex. Testing with arecord produces a soundfile and aplay plays it back. But starting Pd with Alsa or jack gives the dreaded errors about the resource being in use. Pd's performance with just playback is pretty good - pvoc example takes 20% cpu at 10ms latency - but I want to process some audio input! I built my own armhf kernel (much faster than armel) and have a very basic Ubuntu filesystem in place. There's no obvious process like pulseaudio grabbing the audio hardware either. Jack has all of the limits.conf set high. The audio device is sgtl5000 from Freescale. What's the usual setup and troubleshooting process for Pd on Linux these days? Seems like these things are mostly sorted on x86, so maybe the problem is driver or armhf related. Thanks! *Dual Cortex A9 box for $100: http://wandboard.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] compiling externals on ARM
Actually I think that the library template should work for Linux on ARM too, as is. Only it does not provide specific optimization flags, which those ARM boards sorely need for performance. But if it does not build at all, there may be something else wrong, for example the build directory structure. Let's not conclude too early that the makefiles are at fault. Katja On Mon, Sep 9, 2013 at 6:29 PM, jo57 jaime.oliv...@gmail.com wrote: I don't think it is clutter at all… I don't have one of these boards, but I'd love to try them, and when I do, I'd love to come back to this documentation... Perhaps this could be added to the library template? http://puredata.info/docs/developer/LibraryTemplate J On Sep 9, 2013, at 11:39 AM, katja katjavet...@gmail.com wrote: Hi Ali, Seems an interesting board, the Udoo. PengPod has Cortex-A8 while Udoo has Cortex-A9. But machine name is armv7l in both cases, meaning the same compiler flags may be used. If you want I can send you a project by private mail (don't want to clutter the list with this) which builds some home-brew externals and some externals from Pd-extended on RPi and PengPod amongst others. If it would build on Udoo too, we'd know a bit more. Katja On Mon, Sep 9, 2013 at 4:11 PM, Ali Momeni batc...@gmail.com wrote: Hello, Looks like the Udoo is the same as the PengPod. Is the PengPod something like: http://pandaboard.org/ ? Here's what i get: ubuntu@imx6-qsdl:~$ uname -s Linux ubuntu@imx6-qsdl:~$ uname -a Linux imx6-qsdl 3.0.35 #1 SMP PREEMPT Mon Aug 19 07:11:31 PDT 2013 armv7l armv7l armv7l GNU/Linux On Mon, Sep 9, 2013 at 10:03 AM, katja katjavet...@gmail.com wrote: Hello Ali, A while ago I've compiled home-brew Pd externals on Raspberry Pi and PengPod Linux tablet, and found that for each ARM processor type you can identify them by their proper name as returned by command uname -m. For RPi this is armv6l and for PengPod armv7l. So I could define individual flags for those ARM types in the makefiles. There is no general approach to this, as makefiles in various Pd extended libs can be very different. In the template makefile which is used for many libs, the operating system is tested first with uname -s. If it is Linux, the processor type is found with uname -m and stored in variable CPU, which seems to be used for target 'showsetup' only, not for setting specific flags. Anyway, if you get No rule to make target xxx.pd_linux when trying to build a lib with template makefile, I wonder what you get from your Udoo board with command uname -s? Katja On Mon, Sep 9, 2013 at 2:06 PM, Ali Momeni batc...@gmail.com wrote: hello all, i'm working with a Udoo board (http://Udoo.org) i've successfully compiled PureData 0.45 from miller's site; i'm now trying to compile some of the externals in the pd svn, but i'm getting the same error for all. for instance, when trying to compile nusmuk-audio, i.e. http://sourceforge.net/p/pure-data/svn/17203/tree/trunk/externals/nusmuk/nusmuk-audio/ i get the following ubuntu@imx6-qsdl:~/pd-externals/nusmuk/nusmuk-audio$ make make: * No rule to make target `bq~.pd_linux', needed by `all'. Stop. I have contacted the developer (cyrille henry) and he adjusted the MakeFile to account for building for ARM; but i get the same error. I notice, incidentally, that i get the same error (No rule to make target xxx.pd_linux) for all other externals that i tried from the repository. does anyone have any thoughts on how to resolve this? thanks, ali ___ 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] compiling externals on ARM
Hello Ali, A while ago I've compiled home-brew Pd externals on Raspberry Pi and PengPod Linux tablet, and found that for each ARM processor type you can identify them by their proper name as returned by command uname -m. For RPi this is armv6l and for PengPod armv7l. So I could define individual flags for those ARM types in the makefiles. There is no general approach to this, as makefiles in various Pd extended libs can be very different. In the template makefile which is used for many libs, the operating system is tested first with uname -s. If it is Linux, the processor type is found with uname -m and stored in variable CPU, which seems to be used for target 'showsetup' only, not for setting specific flags. Anyway, if you get No rule to make target xxx.pd_linux when trying to build a lib with template makefile, I wonder what you get from your Udoo board with command uname -s? Katja On Mon, Sep 9, 2013 at 2:06 PM, Ali Momeni batc...@gmail.com wrote: hello all, i'm working with a Udoo board (http://Udoo.org) i've successfully compiled PureData 0.45 from miller's site; i'm now trying to compile some of the externals in the pd svn, but i'm getting the same error for all. for instance, when trying to compile nusmuk-audio, i.e. http://sourceforge.net/p/pure-data/svn/17203/tree/trunk/externals/nusmuk/nusmuk-audio/ i get the following ubuntu@imx6-qsdl:~/pd-externals/nusmuk/nusmuk-audio$ make make: * No rule to make target `bq~.pd_linux', needed by `all'. Stop. I have contacted the developer (cyrille henry) and he adjusted the MakeFile to account for building for ARM; but i get the same error. I notice, incidentally, that i get the same error (No rule to make target xxx.pd_linux) for all other externals that i tried from the repository. does anyone have any thoughts on how to resolve this? thanks, ali ___ 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] compiling externals on ARM
Hi Ali, Seems an interesting board, the Udoo. PengPod has Cortex-A8 while Udoo has Cortex-A9. But machine name is armv7l in both cases, meaning the same compiler flags may be used. If you want I can send you a project by private mail (don't want to clutter the list with this) which builds some home-brew externals and some externals from Pd-extended on RPi and PengPod amongst others. If it would build on Udoo too, we'd know a bit more. Katja On Mon, Sep 9, 2013 at 4:11 PM, Ali Momeni batc...@gmail.com wrote: Hello, Looks like the Udoo is the same as the PengPod. Is the PengPod something like: http://pandaboard.org/ ? Here's what i get: ubuntu@imx6-qsdl:~$ uname -s Linux ubuntu@imx6-qsdl:~$ uname -a Linux imx6-qsdl 3.0.35 #1 SMP PREEMPT Mon Aug 19 07:11:31 PDT 2013 armv7l armv7l armv7l GNU/Linux On Mon, Sep 9, 2013 at 10:03 AM, katja katjavet...@gmail.com wrote: Hello Ali, A while ago I've compiled home-brew Pd externals on Raspberry Pi and PengPod Linux tablet, and found that for each ARM processor type you can identify them by their proper name as returned by command uname -m. For RPi this is armv6l and for PengPod armv7l. So I could define individual flags for those ARM types in the makefiles. There is no general approach to this, as makefiles in various Pd extended libs can be very different. In the template makefile which is used for many libs, the operating system is tested first with uname -s. If it is Linux, the processor type is found with uname -m and stored in variable CPU, which seems to be used for target 'showsetup' only, not for setting specific flags. Anyway, if you get No rule to make target xxx.pd_linux when trying to build a lib with template makefile, I wonder what you get from your Udoo board with command uname -s? Katja On Mon, Sep 9, 2013 at 2:06 PM, Ali Momeni batc...@gmail.com wrote: hello all, i'm working with a Udoo board (http://Udoo.org) i've successfully compiled PureData 0.45 from miller's site; i'm now trying to compile some of the externals in the pd svn, but i'm getting the same error for all. for instance, when trying to compile nusmuk-audio, i.e. http://sourceforge.net/p/pure-data/svn/17203/tree/trunk/externals/nusmuk/nusmuk-audio/ i get the following ubuntu@imx6-qsdl:~/pd-externals/nusmuk/nusmuk-audio$ make make: * No rule to make target `bq~.pd_linux', needed by `all'. Stop. I have contacted the developer (cyrille henry) and he adjusted the MakeFile to account for building for ARM; but i get the same error. I notice, incidentally, that i get the same error (No rule to make target xxx.pd_linux) for all other externals that i tried from the repository. does anyone have any thoughts on how to resolve this? thanks, ali ___ 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-announce] pd 0.45 test release
Hi Miller, That's a lot of new, very useful features! It is really cool to have a decent text editor within Pd. I like how methods on named [text] and [array] objects can be called from any place (depending on scope), since you can get output where you want it instead of everything coming from one outlet. Therefore [text] is more powerful than [cyclone/coll] indeed. Wasn't Jonathan Wilkes proposing a similar approach for glists in general some time ago? I compiled Pd 0.45-0test1 on Xubuntu 10.4. I'm sorry to report the following: if the help patch for [list] is opened, Pd exits with 'Segmentation fault (core dumped)'. Katja On Sun, Aug 18, 2013 at 3:51 AM, Miller Puckette m...@ucsd.edu wrote: Hi all, Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data git checkout 0.45-0test1 Some new features: binary netsend/netreceive (so you should no longer need an extern for OSC) pd~ (multiprocessing) works on windows and is less likely to deadlock although not yet perfect multi-purpose array and text objects. Array is a more general replacement for the table, tabread and tabwrite obejcts. text is sort of like Max's coll but simpler and hopefully more powerful. texts are also avaioable as fields in data structures. tempo messages for delay, metro, timer, and test sequence. In particular you can specify or measure time in samples, but you can also use this for changing the speed of an ensemble of delay loops while keeping them in sync. Objects/messages/comments have settable box widths. Also various improvements in audio and midi handling: The Pd window now tells you whether PD has an audio device open or not Fixed hangups exiting when using jack Got ASIO working again on PC (it was apparently broken; I don't know for how long.) cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] idea for simple technique for getting noise from signal
On Wed, Aug 14, 2013 at 8:14 AM, IOhannes m zmölnig zmoel...@iem.at wrote: On 08/13/13 23:27, Hans-Christoph Steiner wrote: That reminds me, the simple Pd question I have is: anyone know of an XOR tilde object? [expr~ $v1 ^ $v2] ... And cyclone has bitwise operators for signal, [cyclone/bitxor~] amongst them. They can operate on floats as raw bit sequences, or convert the floats to integers first. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Benefits of using an external soundcard?
Hello, My experience is partly similar to what Charles mentioned: an external soundcard can be much better in S/R ratio (both Brownian noise of the preamp and specific frequencies produced by power supply). I would not say that noise is less noticeable in live performance though - on the contrary: it is heavily amplified on the pa system, more than in a home environment. Furthermore, in live performance you need a directional mic and these are less sensitive than omnidirectional mics, so you need to amplify more and S/R ratio gets worse. For this reason I bought myself a nice audio interface which works with Linux, a Mackie Onyx Blackjack. Not expensive, two channel mic/line/instrument with phantom, low noise. Later however, I noticed Panasonic unidirectional electret capsules which can be directly connected to a built-in computer sound card with mic input. Sensitivity is less than omnidirectional capsules but better than dynamic or condenser unidirectional mics. The Panasonic capsule is very sensitive to plosive mouth noises and initially I thought they were useless. But with good wind protection (imitation fur) it works nice. The type of this capsule is WM-55A103. My friend bought them from Digikey but it seems they're out of stock now, obsolete they say! They can still be found from other sources. Katja On Sun, Aug 11, 2013 at 4:37 AM, Mario Mey mario...@gmail.com wrote: Brian: I comment between lines: El 09/08/13 09:42, Brian Fay escribió: Is there a specific type of microphone you will be using? I've seen some videos of Beardyman recently using some type of hands-free lavalier microphone. I will use my wireless VHF SHURE microphone (I know it is old). The original is a headset, but, for beatbox, I use a SM-58 connected to the same trasnmisor. It sounds different, so, the SM-58 jack has a resistor to turn the gain down and an EQ in PureData, to make it sound like the other. I don't know if I will use the headset (as Beardyman) or the SM-58. It is about comfort. This and other condenser microphones require Phantom Power, which is provided by many audio interfaces and mixers but generally not built in to an internal soundcard. It doesn't need phantom power. See how far you can get with what you have; there's no point in buying something that you don't need. But you might find that you do need one eventually. I will buy the cheap soundcard (ARS $200). I understand what you say, but it has some benefits: - I care the notebook audio-out jack. USB is more resistent for pluging and unpluging. I (this) summer, I work in a park and I do what this video shows, EVERYNIGHT: http://www.youtube.com/watch?v=oNUZULR7k18 - I have more inputs and outputs (for future features). - Maybe, I avoid noise in the line (for the moment, I don't have it... but I think it depends on the power line of the location). - Sometimes, I do record some samples... it will be usefull for that. Keep in mind that you'll need very low latency (less than 20 miliseconds) for your application. I'm not sure if this is affected by the sound card or not. All of the audio processing happens on the CPU, but maybe the buffering stages for the sound card add enough delay to add latency... could somebody with more familiarity chime in here? For now, I have 5.8ms of latency. It's very good for me. If you are saying that an external soundcard would add latency... more than the internal, so, it is not good! Thanks. On Fri, Aug 9, 2013 at 7:28 AM, Mario Mey mario...@gmail.com wrote: El 08/08/13 17:50, Charles Z Henry escribió: Hi Mario The number one reason for having an external sound card is noise isolation. The card's proximity to the power supply and motherboard are bad for EM noise. Also, a computer power supply and a good audio power supply for recording have much the same relationship--there's more noise in switching electronics. Next, there's the size constraints. You'd have a hard time adding all the connectors for a large number of channels on a card which plugs in to your PCI(e) slots. It's ok, I have a notebook: 1 plug out, 1 plug in. Third: there's not as great a need for bandwidth for audio as there is with video. Video cards need all that PCI(e) bandwidth. Audio doesn't. It's a relatively small amount of data. Of course--I think USB and firewire really don't have enough bandwidth for good scalability, but that's another discussion. But... what are you doing with it? You have different requirements for recording and for live sound. Live sound: just do it up. No one will likely notice. Live sound is my purpose. Mic-in looping-station and multieffects system (following the steps of Beardyman and his Beardytron_5000). But, sorry about not understanding your expresion (english is not my native language) What do you mean with just do it up, no one will likely notice? Should I buy it or no one will notice the difference? I
Re: [PD] direct connection from pd to webrowser, low latency
On Sat, Apr 27, 2013 at 1:31 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Btw-- are you sending compressed or uncompressed audio? Uncompressed, 16 bit ints. Compression requires analysis, introducing extra latency. I'm not using it in practice yet, as I still have to find (or develop) a solution for packet loss concealment. As of now, I use a cheap work-around for wireless monitoring only: an FM 'stereo' transmitter and receiver. FM stereo does not send over two frequency channels, therefore audio quality is suboptimal, not suitable for regular PA situations. However it may be suitable for 'silent concert' experiments in small venues. Onyx, is that an idea? Most cell phones do have an FM receiver. They only work with wired headset connected, functioning as antenna. As wired headsets can be cheap, just offer them for sale during the event. The good thing with FM is, it has zero latency. I got a LinexFM transmitter from here: http://www.linexfm.nl/ Rumors go that USA versions have higher transmission power than the ones sold in Europe. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] direct connection from pd to webrowser, low latency
Yeah, sending FUDI would be good. Or OSC. In case of synthesis, better send controller data instead of audio. In my case (sending processed acoustic audio input) that wouldn't work, but never mind. Katja On Fri, Apr 26, 2013 at 10:36 PM, Phil Stone pkst...@ucdavis.edu wrote: That's a fairly brilliant idea. No need for fancy audio-quality wireless units, either. Phil On 4/26/13 1:19 PM, Jonathan Wilkes wrote: __**__ From: katja katjavet...@gmail.com To: o...@onyx-ashanti.com onyxasha...@gmail.com Cc: pd-list Pd-list@iem.at; Martin Peach martin.pe...@sympatico.ca Sent: Friday, April 26, 2013 4:08 PM Subject: Re: [PD] direct connection from pd to webrowser, low latency Hi Onyx, What is your aim, do you want to entertain your (physically present) audience via smart phones instead of PA system? I have a similar quest pending: to send Pd audio from a wearable computer over wireless to PA system. Why not send FUDI to a box connected directly to the PA system? -Jonathan __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list 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] installing pd 32 bits in a 64 bit linux?
Hi, Recently I installed Kubuntu and Pd-E 0.44 both 64 bit. Pd-E 0.44 does not give the warning about 64 bit issues, and indeed some of the earlier bugs are fixed. However not all are fixed. I do not use many externals but ran into 64 bit issues with cyclone library ([poke~] and [sfv~] at least). On my dual boot with Kubuntu Precise 64 bit and Debian Squeeze 32 bit, I can fall back on the 32 for music performance, while using the 64 for experiment. Currently I am trying to set up a Pd-E development layout on Kubuntu. Anyway, when using Pd on Linux 64 bit it's probably best to fetch latest greatest from nightly builds every now and then, so you have recent fixes. Katja On Mon, Apr 1, 2013 at 7:45 PM, Jm Jones juan...@gmail.com wrote: ok! so I will install PD 64 in my windows machine algo 2013/4/1 András Murányi muran...@gmail.com: Howdy, another 64-bit guy here. My advice: go with the 64-bit version, and most likely you will never experience a problem related to 64-bitness. If you do, or in doubt, report it here so Pd can be improved. If later, by any chance, you run into a 64-bit problem which cannot be fixed soon with the help of the mailing list, you can still install a 32-bit copy. (You have to force the package manager to install the 32-bit package then use the 'getlibs' utility to satisfy dependencies for 32-bit software on 64-bit.) András On Mon, Apr 1, 2013 at 7:14 PM, Jm Jones juan...@gmail.com wrote: I haven't tested all of them, but thats says PD as a warning when i open the software. Right now i remember maxlib, but it mention 6 and advices that others may have problems also. 2013/4/1 IOhannes m zmölnig zmoel...@iem.at: On 03/31/2013 21:01, Jm Jones wrote: Hi, im a little confused because in windows this works different (i think). In win7 64 bits i use pd-extended 32. But In ubuntu 64 bits the 64 bits pd package says that some externals aren't fully compatible, so i want to install the 32 b version, is this possible? yes it's possible, but usually you don't want that. what are those some externals that aren't fully compatible? i've been using native 64bit builds on 64bit linuxes for about 10 years now. fgamsdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- JM Jones ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Murányi András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- JM Jones ___ 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] Urban Schlemmer's Reverb Design (Weimar PDCon)
At the time of the convention at least, Urban's implementation was not publicly available. I remember discussing that with him. The work was very complicated and uncommented, so I could see there was good reason not to share it then. I'm still curious about it though, maybe we should just ask him. Katja On 3/15/13, chris clepper cgclep...@gmail.com wrote: List I rediscovered the presentation from the Weimar PdCon from Urban Schlemmer on reverb design in Pd. The appendices list a set of abstractions and objects from Schlemmer and others, but I have not found an online source for these. Of the listed abstractions, I have only Miller's basic reverb patches and the Dattorro implementation called jon~ Are the Gardiner, Chowning and J.O Smith historical objects and Schlemmer's own toolkit available? Thanks Chris ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] subnormal numbers explained
Hello, Found this instructive article about subnormals (called denormal numbers there): http://www.google.nl/url?sa=trct=jq=musicdsp%20denormalsource=webcd=3ved=0CEEQFjACurl=http%3A%2F%2Fmusicdsp.org%2Ffiles%2Fdenormal.pdfei=O0hAUbu7GcyU0QWezoHQCwusg=AFQjCNGbelHDdXUZnnZOwLOwwz4V8u_98wbvm=bv.43287494,d.d2k Subnormal numbers are a pain in the ass, they cause substantially increased CPU load without doing anything useful for audio DSP. Unfortunately it can happen in some Pd objects (notably [freeverb~]), and spoil the performance of a Pd patch. The article explains why subnormal numbers occur, and what can be done to eliminate or prevent them. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-ext .43.4 debian squeezy wrong architecture
Hello, there is still something wrong with the links to Pd-E for Squeeze i386. About 0.44 from 'latest' or nightly builds, gdebi says 'wrong architecture, amd64'. Katja On Sun, Feb 10, 2013 at 9:49 PM, João Pais jmmmp...@googlemail.com wrote: Ok. Btw, the version I just installed from that section worked with no problems. Did you corrected the build meanwhile? João There are too many Debian/Ubuntu packages for direct links, click on Get Pd-extended 0.43.4 for All platforms list of all available downloads on SourceForge, including packages for Debian, Raspbian, and Ubuntu from Lucid to Raring, etc. .hc On Feb 10, 2013, at 12:03 PM, João Pais wrote: from the autobuilds page. the puredata.info doesn't have links to the deb files, just to a package to build pd (that also doesn't work? I'm starting with debian, the comand in the description wasn't found by the system) Oops... Where did you download these? Could you include the link? .hc On Feb 10, 2013, at 3:08 AM, João Pais wrote: Hi, I was trying to install the -deb package for squeezy i386. But when I open it, the packet installer says wrong architecture amd64. The same happens (logically) when I try the 64b package. Best, jmmmp __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list 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-ext .43.4 debian squeezy wrong architecture
Seems that the Jan 29 2012 build (Pd-E 0.43.4) is the latest which can be installed on Squeeze i386, newer ones for Squeeze i386 are actually amd64 according to gdebi (though I did not try 'm all of course). Katja On Mon, Mar 11, 2013 at 11:38 AM, katja katjavet...@gmail.com wrote: Hello, there is still something wrong with the links to Pd-E for Squeeze i386. About 0.44 from 'latest' or nightly builds, gdebi says 'wrong architecture, amd64'. Katja On Sun, Feb 10, 2013 at 9:49 PM, João Pais jmmmp...@googlemail.comwrote: Ok. Btw, the version I just installed from that section worked with no problems. Did you corrected the build meanwhile? João There are too many Debian/Ubuntu packages for direct links, click on Get Pd-extended 0.43.4 for All platforms list of all available downloads on SourceForge, including packages for Debian, Raspbian, and Ubuntu from Lucid to Raring, etc. .hc On Feb 10, 2013, at 12:03 PM, João Pais wrote: from the autobuilds page. the puredata.info doesn't have links to the deb files, just to a package to build pd (that also doesn't work? I'm starting with debian, the comand in the description wasn't found by the system) Oops... Where did you download these? Could you include the link? .hc On Feb 10, 2013, at 3:08 AM, João Pais wrote: Hi, I was trying to install the -deb package for squeezy i386. But when I open it, the packet installer says wrong architecture amd64. The same happens (logically) when I try the 64b package. Best, jmmmp __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list 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] wireless audio from Pd to PA system (katja)
Netjack docs look promising. It binds Jack clients on the transmitter
computer (called 'slave') to the sample clock on the receiver computer
('master'). Netjack supports transmission over wifi, and over internet
(using the CELT codec). It is primarily designed for 'distributed
music'. Here is a paper introducing Netjack:
http://www.google.nl/url?q=http://lac.linuxaudio.org/2009/cdm/Saturday/22_Hohn/22.pdfsa=Uei=0AM3UajlJIfAO5qDgIgFved=0CDgQFjAJusg=AFQjCNF47yIrp3T6cuIXCKhl0AUIaeiA2w
For anyone using Pd on a mobile device as sound generator, Netjack
could be a great way to deliver audio over wifi. For my purpose
though, I still need access to the sound card at the transmitter side
to capture audio from a mic. An audio rate conversion routine called
AlsaInOut is provided with Netjack so you can use the slave's sound
card for playback. However, this can not be used for capturing or
monitoring, due to large processing delay. So, clock drift is the show
stopper here.
Clock drift is not related to network transmission but to the slight
differences in clock speeds of sound cards even if they are set to the
same nominal sample rate. It also happens with two sound cards used
together on one computer, like when using an USB mic for input and the
system sound card for output. Core Audio can handle such a setup, but
at the expense of increased and fluctuating latency. Jack can combine
soundcards, but buffer under- or overruns are audible.
What is so hard about compensating clock drift? If it must be done in
a theoretically correct way, pitch should not change so it will be a
time stretching routine which will indeed introduce considerable
latency. However, clock speeds often differ by a very small amount,
like a factor 1/1000 or less. What if we just accept the pitch
difference? You would get playback speeds like 1.001 or 0.999,
perfectly acceptable for my purpose at least. This would greatly
simplify the task of resampling.
Katja
On 3/5/13, Charles Goyard c...@fsck.fr wrote:
Hi,
see if netjack fills the bill :
Netjack is a Realtime Audio Transport over a generic IP Network. It is
fully integrated into JACK.
When you transport Audio Signals over a Network, you will always have
the problem, that two Computers are bound to two different Sample
Clocks. The other Network Transports face the Problem of compensating
for the drift between these Sample Clocks. This is very hard to do.
NetJack works around this problem, by syncing all Clients to one
Soundcard. So there will be no resampling or glitches in the whole
network. Packet loss is now also handled gracefully. By using the celt
codec, its even possible, that single packet losses get masked by the
Packet Loss Concealment Code.
https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_NetJack
https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_NetJack2
Cheers,
--
Charles
___
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] wireless audio from Pd to PA system (katja)
Sending Pd-audio over Wifi would have the advantage that no extra gear is needed at the transmitter side, simplifiying the setup of a wearable live performance computer. Therefore this would be the method of my preference, if it is possible at all. This weekend I did some experiments with [udpsend~] and [udpreceive~] over Wifi. I soon found that using a wireless router makes little sense. Wifi is 'half duplex', meaning it can't send and receive at the same time, so the router is either receiving from one computer or sending to the other. A waste of time. I learned about 'ad hoc networks', where computers can be paired via Wifi and talk to each other directly, without a router. Never knew about this before. What a cool option that is. Found a howto here: https://help.ubuntu.com/community/WifiDocs/Adhoc In ad hoc mode, latency is lower, although on average not as low as over cable, and with more fluctuation. Moreover, there was considerable packet loss, which did not happen in wired LAN. Therefore, tcp protocol should probably be used instead, to check for packet loss and eventually resend packets. I found that [udpsend~] can not send packets of 64 samples. It seems that 256 samples is the minimum. Why? Maybe it is best to pack each signal vector in a list and use the [tcpsend] / [tcpreceive] combo instead. A well-known issue with music streaming is clock drift, caused by the slightly different clock speeds between audio cards. This also happens when sending over a local network (wired or wireless). Clock drift is typically 0.0001 to 0.001 ratio of nominal sample rate. A small difference, but it causes one buffer to be skipped or duplicated once in a while. To compensate, the signal should be resampled to match the receiver's sample rate. This would not require a complicated interpolation scheme, but still it would probably need one or more new Pd classes. An interesting article about clock drift and possible solutions is here: http://www.carot.de/Docs/AES_Tokyo.pdf If further experiments are promising enough, I would try this board for the receiver: https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino-WIFI/ Otherwise, I would just be happy to have learned about ad hoc networks. This can come in handy for other purposes too, for example when synching Pd computers. Katja On Fri, Mar 1, 2013 at 9:34 PM, Phil Stone pkst...@ucdavis.edu wrote: These Line 6 units are well respected in the electric bass world, especially considering their moderate price. I think bass players appreciate tight timing, and the low lag may be one reason these units are popular. Also, they have proven to be rugged enough to be road-worthy. They can also model the hi-frequency lossiness of cords, though that seems of dubious value in your case. Phil On 3/1/13 12:24 PM, katja wrote: Apparently, Line 6 managed to build a digital 2.4 GHz wireless with 4 ms latency, the Relay G30, G50 etc . They do not write it in the specs, but most users don't notice latency and when they do, their support is speaking of latency as low as that: http://line6.com/support/thread/33898 This weekend I will do some WiFi experiments and see how fast it can go locally, using mrpeach udp and tcp classes. If it works, one could use a wireless router which has no other task than routing Pd audio, and the computer at the receiving end could be a cheap headless board with no other task than receiving Pd audio and converting it to analog. Together the receiving device could be the size of a weight-watcher's lunch box, while at the transmitter side the computer's built-in stuff is used. Maybe I'm a bit naive here, anyway I'll report results from experiments. Katja On Fri, Mar 1, 2013 at 2:14 PM, richard duckworth richduckwo...@yahoo.com wrote: OMG - that's really high! Maybe Tranz have a belt holder solution - they do look kind of bulky though! Maybe worth dropping them a line, see if they'll help the Pd community Rich Duckworth Lecturer in Music Technology Department of Music House 5 Trinity College Dublin 2 Ireland Tel 353 1 896 1500 Digital? Is that the thing where they take a good old sine wave and they chop it up into little bits? --- Rupert Neve -- *From:* katja katjavet...@gmail.com *To:* Antoine Villeret antoine.ville...@gmail.com *Cc:* richard duckworth richduckwo...@yahoo.com; pd-list@iem.at pd-list@iem.at *Sent:* Friday, 1 March 2013, 13:12 *Subject:* Re: [PD] wireless audio from Pd to PA system (katja) Found more info about TI's PurePath wireless. Latency of wireless transmission is 768 samples minimum. Added to this must be the latencies of ad/da conversion. http://e2e.ti.com/support/low_power_rf/f/382/t/110331.aspx Forget about it, this concept is only useful for home entertainment. Katja On Fri, Mar 1, 2013 at 1:19 PM, katja katjavet...@gmail.com wrote: Thanks everyone for your answers. The case is unconventional
Re: [PD] wireless audio from Pd to PA system (katja)
Hi Chris, thanks for your advice. You're right, Chinese manufacturers are generally not supportive to open source, which is a pity as they are designing and producing most of the hardware today. Katja On Tue, Mar 5, 2013 at 6:43 AM, chris clepper cgclep...@gmail.com wrote: On Mon, Mar 4, 2013 at 6:41 PM, katja katjavet...@gmail.com wrote: If further experiments are promising enough, I would try this board for the receiver: https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino-WIFI/ I have been running Pd on this board for a few weeks now. In general, it works OK, but the ADC is not so good and adds a lot of latency. Just DAC output can be 10ms latency with passable sound. All of the Pd example patches run fine with the FFT ones topping out around 50% CPU load. That's with nothing else running. Any network activity will cause dropouts even at large buffer settings though. The WiFi works with a few tweaks to the settings for your network. The drawback with the Allwinner based chips is you have to take whatever the chip maker gives you for documentation and drivers (slim and none basically). The Chinese SoC makers have zero interest in orders less than a half million units and they mainly make those under $100 7 tablets and bad set top boxes. If something doesn't work, then it likely won't ever work - don't hold out for improved ALSA drivers for example. I would see what the new BeagleBone looks like too. It's supposed to be cheaper and improved plus TI does support open source better than most. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] wireless audio from Pd to PA system (katja)
Thanks everyone for your answers. The case is unconventional because a stereo line signal must be sent from the computer. Professional wireless systems assume mic or instrument. Consumer systems do transmit stereo signal, but without bothering too much about latency. Frankly, I did not expect the difficulty to find a good solution. Initially I wanted the wearable computer for a music video which is to be recorded live with sounds from natural objects. I bought the FM transmitter so my cameraman will be able to hear the music while he's filming. For this purpose it is ideal. Then I thought it would be good to use the computer in it's wearable mode for public performance. I figured that one of the many wireless solutions would suit the purpose, but didn't reckon with the unusual requirements. Further searching brought me to a new technology 'PurePath' from Texas Instruments. It has a range comparable with WiFi (30m), while it seems to work with paired devices as in Bluetooth. I haven't seen consumer products with this technology, but development kits are available. A rather convincing demo is here: http://www.youtube.com/watch?v=0YsnZQUfVGs If this system can work with low latency it could be perfect for wireless Pd. Katja On Fri, Mar 1, 2013 at 11:41 AM, Antoine Villeret antoine.ville...@gmail.com wrote: hello, those are good for what they have been designed for and it depends on what you mean by exellent sound quality I've made few tests on those few years ago and the bandwidth could be good enough to transmit guitar/bass signal but nothing else for me + a -- do it yourself http://antoine.villeret.free.fr 2013/2/28 richard duckworth richduckwo...@yahoo.com Hi Katja one of these would do it - check with Thomann tech support for gain issues (these are Instrument Level input) They should be fine however as active guitar pickups (like heavy style EMG pickups) output quite high levels. These type of wireless systems tend to be very rugged, have excellent sound quality and long battery life - and you'll want these things. http://www.thomann.de/ie/cat.html?gf=wireless_for_guitar_bassoa=pra Rich Duckworth Lecturer in Music Technology Department of Music House 5 Trinity College Dublin 2 Ireland Tel 353 1 896 1500 Digital? Is that the thing where they take a good old sine wave and they chop it up into little bits? --- Rupert Neve -- Message: 3 Date: Thu, 28 Feb 2013 11:53:43 +0100 From: katja katjavet...@gmail.com Subject: [PD] wireless audio from Pd to PA system To: pd-list pd-list@iem.at Message-ID: cafy0eappskfw+gvaxutr7exhqlig+ptdu8rk6sntraliys2...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 For a wearable live performance computer, I am looking into the options of sending wireless audio from Pd to a PA sound system and other listeners. In a first experiment I've tried a Linex FM transmitter. Audio quality is good enough, and FM transmitters do not introduce latency. This option is cheap and flexible, as the signal can be received by simple radio's, which are even built into cell phones and media players. I would need to boost the transmission a bit to make it more reliable. This will of course make the equipment illegal. Even then, the risk that someone else is transmitting a stronger signal on the channel can not be excluded. Another option could be to send audio over Wifi. This would require WLAN to be available, and one extra computer (with audio interface) as a receiver. To avoid extra latency the audio should be sent uncompressed, like [udpsend~] / [udpreceive~] can do it. This has the risk of packet loss and serious dropouts. I've been searching for 2.4 GHz wireless music receivers and found things like this: http://www.sitecom.com/en/wireless-music-streamer/wl-061/p/203. They seem to act like external soundcards for your computer. In Linux though I've never managed to properly connect multiple soundcards with Pd (in OSX it's easy using the Aggregate Device Editor from Audio MIDI Setup). Also I guess these devices introduce huge latency. With audio over bluetooth headsets I've experienced latencies up to a second. Does anyone use a satisfactory method in practice, to send audio from Pd without wires? Thanks, Katja -- ___ Pd-list mailing list Pd-list@iem.at to manage your subscription (including un-subscription) see http://lists.puredata.info/listinfo/pd-list End of Pd-list Digest, Vol 95, Issue 152 ___ 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] wireless audio from Pd to PA system (katja) (Antoine Villeret)
Thanks for the links, Rich. The Tranz system comes close, with their stereo channels. It's a pity they don't have a body pack. Oddly, the manufacturer doesn't supply any technical specs for these devices. Katja On Fri, Mar 1, 2013 at 1:08 PM, richard duckworth richduckwo...@yahoo.comwrote: http://pro.sony.com/bbsc/ssr/product-DWZB30GB/ The Sony's 10 Hz to 22 kHz - looks like acceptable bandwidth for everyday live stage stuff. Unless you're expecting analogue pro-audio 40kHz above (most pro-audio) or analogue 80kHz - 120 kHz (nice pro-audio Neve etc.) There's SM Pro's 'TRANz' wireless DI box too - in living stereo no less: http://www.smproaudio.com/index.php/en/products/di-boxes/tranz I think contemporary wireless systems are expected to perform to more high-fidelity specs than their bandwidth-challenged cousins of yore (Nady et al). The forums GearSlutz or TapeOp might turn up some answers too as the users are very knowledgable and come from many different pro audio backgrounds. My mate worked on The Wall and he showed me the wireless systems that they were using and introduced me to the 'wireless manager'. These systems were not 'reduced bandwith' - unless you're talking about transmitting HD about the place, and I've no idea how you would do that - i'm sure there's some gruesomely expensive system that would do it :) Rich Digital? Is that the thing where they take a good old sine wave and they chop it up into little bits? --- Rupert Neve -- *From:* pd-list-requ...@iem.at pd-list-requ...@iem.at *To:* pd-list@iem.at *Sent:* Friday, 1 March 2013, 11:00 *Subject:* Pd-list Digest, Vol 96, Issue 2 Send Pd-list mailing list submissions to pd-list@iem.at To subscribe or unsubscribe via the World Wide Web, visit http://lists.puredata.info/listinfo/pd-list or, via email, send a message with subject or body 'help' to pd-list-requ...@iem.at You can reach the person managing the list at pd-list-ow...@iem.at When replying, please edit your Subject line so it is more specific than Re: Contents of Pd-list digest... Today's Topics: 1. Re: wireless audio from Pd to PA system (katja) (Antoine Villeret) -- Message: 1 Date: Fri, 1 Mar 2013 11:41:36 +0100 From: Antoine Villeret antoine.ville...@gmail.com Subject: Re: [PD] wireless audio from Pd to PA system (katja) To: richard duckworth richduckwo...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Message-ID: cagn5wnfjsyqz+kzexrcd25f3--6f4hgw7tzy4br23tpznwn...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 hello, those are good for what they have been designed for and it depends on what you mean by exellent sound quality I've made few tests on those few years ago and the bandwidth could be good enough to transmit guitar/bass signal but nothing else for me + a -- do it yourself http://antoine.villeret.free.fr 2013/2/28 richard duckworth richduckwo...@yahoo.com Hi Katja one of these would do it - check with Thomann tech support for gain issues (these are Instrument Level input) They should be fine however as active guitar pickups (like heavy style EMG pickups) output quite high levels. These type of wireless systems tend to be very rugged, have excellent sound quality and long battery life - and you'll want these things. http://www.thomann.de/ie/cat.html?gf=wireless_for_guitar_bassoa=pra Rich Duckworth Lecturer in Music Technology Department of Music House 5 Trinity College Dublin 2 Ireland Tel 353 1 896 1500 Digital? Is that the thing where they take a good old sine wave and they chop it up into little bits? --- Rupert Neve -- Message: 3 Date: Thu, 28 Feb 2013 11:53:43 +0100 From: katja katjavet...@gmail.com Subject: [PD] wireless audio from Pd to PA system To: pd-list pd-list@iem.at Message-ID: cafy0eappskfw+gvaxutr7exhqlig+ptdu8rk6sntraliys2...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 For a wearable live performance computer, I am looking into the options of sending wireless audio from Pd to a PA sound system and other listeners. In a first experiment I've tried a Linex FM transmitter. Audio quality is good enough, and FM transmitters do not introduce latency. This option is cheap and flexible, as the signal can be received by simple radio's, which are even built into cell phones and media players. I would need to boost the transmission a bit to make it more reliable. This will of course make the equipment illegal. Even then, the risk that someone else is transmitting a stronger signal on the channel can not be excluded. Another option could be to send audio over Wifi. This would require WLAN to be available, and one extra computer (with audio interface) as a receiver. To avoid extra latency the audio
Re: [PD] wireless audio from Pd to PA system (katja)
Found more info about TI's PurePath wireless. Latency of wireless transmission is 768 samples minimum. Added to this must be the latencies of ad/da conversion. http://e2e.ti.com/support/low_power_rf/f/382/t/110331.aspx Forget about it, this concept is only useful for home entertainment. Katja On Fri, Mar 1, 2013 at 1:19 PM, katja katjavet...@gmail.com wrote: Thanks everyone for your answers. The case is unconventional because a stereo line signal must be sent from the computer. Professional wireless systems assume mic or instrument. Consumer systems do transmit stereo signal, but without bothering too much about latency. Frankly, I did not expect the difficulty to find a good solution. Initially I wanted the wearable computer for a music video which is to be recorded live with sounds from natural objects. I bought the FM transmitter so my cameraman will be able to hear the music while he's filming. For this purpose it is ideal. Then I thought it would be good to use the computer in it's wearable mode for public performance. I figured that one of the many wireless solutions would suit the purpose, but didn't reckon with the unusual requirements. Further searching brought me to a new technology 'PurePath' from Texas Instruments. It has a range comparable with WiFi (30m), while it seems to work with paired devices as in Bluetooth. I haven't seen consumer products with this technology, but development kits are available. A rather convincing demo is here: http://www.youtube.com/watch?v=0YsnZQUfVGs If this system can work with low latency it could be perfect for wireless Pd. Katja On Fri, Mar 1, 2013 at 11:41 AM, Antoine Villeret antoine.ville...@gmail.com wrote: hello, those are good for what they have been designed for and it depends on what you mean by exellent sound quality I've made few tests on those few years ago and the bandwidth could be good enough to transmit guitar/bass signal but nothing else for me + a -- do it yourself http://antoine.villeret.free.fr 2013/2/28 richard duckworth richduckwo...@yahoo.com Hi Katja one of these would do it - check with Thomann tech support for gain issues (these are Instrument Level input) They should be fine however as active guitar pickups (like heavy style EMG pickups) output quite high levels. These type of wireless systems tend to be very rugged, have excellent sound quality and long battery life - and you'll want these things. http://www.thomann.de/ie/cat.html?gf=wireless_for_guitar_bassoa=pra Rich Duckworth Lecturer in Music Technology Department of Music House 5 Trinity College Dublin 2 Ireland Tel 353 1 896 1500 Digital? Is that the thing where they take a good old sine wave and they chop it up into little bits? --- Rupert Neve -- Message: 3 Date: Thu, 28 Feb 2013 11:53:43 +0100 From: katja katjavet...@gmail.com Subject: [PD] wireless audio from Pd to PA system To: pd-list pd-list@iem.at Message-ID: cafy0eappskfw+gvaxutr7exhqlig+ptdu8rk6sntraliys2...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 For a wearable live performance computer, I am looking into the options of sending wireless audio from Pd to a PA sound system and other listeners. In a first experiment I've tried a Linex FM transmitter. Audio quality is good enough, and FM transmitters do not introduce latency. This option is cheap and flexible, as the signal can be received by simple radio's, which are even built into cell phones and media players. I would need to boost the transmission a bit to make it more reliable. This will of course make the equipment illegal. Even then, the risk that someone else is transmitting a stronger signal on the channel can not be excluded. Another option could be to send audio over Wifi. This would require WLAN to be available, and one extra computer (with audio interface) as a receiver. To avoid extra latency the audio should be sent uncompressed, like [udpsend~] / [udpreceive~] can do it. This has the risk of packet loss and serious dropouts. I've been searching for 2.4 GHz wireless music receivers and found things like this: http://www.sitecom.com/en/wireless-music-streamer/wl-061/p/203. They seem to act like external soundcards for your computer. In Linux though I've never managed to properly connect multiple soundcards with Pd (in OSX it's easy using the Aggregate Device Editor from Audio MIDI Setup). Also I guess these devices introduce huge latency. With audio over bluetooth headsets I've experienced latencies up to a second. Does anyone use a satisfactory method in practice, to send audio from Pd without wires? Thanks, Katja -- ___ Pd-list mailing list Pd-list@iem.at to manage your subscription (including un-subscription) see http://lists.puredata.info/listinfo/pd-list End of Pd-list Digest, Vol 95
Re: [PD] wireless audio from Pd to PA system (katja)
Apparently, Line 6 managed to build a digital 2.4 GHz wireless with 4 ms latency, the Relay G30, G50 etc . They do not write it in the specs, but most users don't notice latency and when they do, their support is speaking of latency as low as that: http://line6.com/support/thread/33898 This weekend I will do some WiFi experiments and see how fast it can go locally, using mrpeach udp and tcp classes. If it works, one could use a wireless router which has no other task than routing Pd audio, and the computer at the receiving end could be a cheap headless board with no other task than receiving Pd audio and converting it to analog. Together the receiving device could be the size of a weight-watcher's lunch box, while at the transmitter side the computer's built-in stuff is used. Maybe I'm a bit naive here, anyway I'll report results from experiments. Katja On Fri, Mar 1, 2013 at 2:14 PM, richard duckworth richduckwo...@yahoo.comwrote: OMG - that's really high! Maybe Tranz have a belt holder solution - they do look kind of bulky though! Maybe worth dropping them a line, see if they'll help the Pd community Rich Duckworth Lecturer in Music Technology Department of Music House 5 Trinity College Dublin 2 Ireland Tel 353 1 896 1500 Digital? Is that the thing where they take a good old sine wave and they chop it up into little bits? --- Rupert Neve -- *From:* katja katjavet...@gmail.com *To:* Antoine Villeret antoine.ville...@gmail.com *Cc:* richard duckworth richduckwo...@yahoo.com; pd-list@iem.at pd-list@iem.at *Sent:* Friday, 1 March 2013, 13:12 *Subject:* Re: [PD] wireless audio from Pd to PA system (katja) Found more info about TI's PurePath wireless. Latency of wireless transmission is 768 samples minimum. Added to this must be the latencies of ad/da conversion. http://e2e.ti.com/support/low_power_rf/f/382/t/110331.aspx Forget about it, this concept is only useful for home entertainment. Katja On Fri, Mar 1, 2013 at 1:19 PM, katja katjavet...@gmail.com wrote: Thanks everyone for your answers. The case is unconventional because a stereo line signal must be sent from the computer. Professional wireless systems assume mic or instrument. Consumer systems do transmit stereo signal, but without bothering too much about latency. Frankly, I did not expect the difficulty to find a good solution. Initially I wanted the wearable computer for a music video which is to be recorded live with sounds from natural objects. I bought the FM transmitter so my cameraman will be able to hear the music while he's filming. For this purpose it is ideal. Then I thought it would be good to use the computer in it's wearable mode for public performance. I figured that one of the many wireless solutions would suit the purpose, but didn't reckon with the unusual requirements. Further searching brought me to a new technology 'PurePath' from Texas Instruments. It has a range comparable with WiFi (30m), while it seems to work with paired devices as in Bluetooth. I haven't seen consumer products with this technology, but development kits are available. A rather convincing demo is here: http://www.youtube.com/watch?v=0YsnZQUfVGs If this system can work with low latency it could be perfect for wireless Pd. Katja On Fri, Mar 1, 2013 at 11:41 AM, Antoine Villeret antoine.ville...@gmail.com wrote: hello, those are good for what they have been designed for and it depends on what you mean by exellent sound quality I've made few tests on those few years ago and the bandwidth could be good enough to transmit guitar/bass signal but nothing else for me + a -- do it yourself http://antoine.villeret.free.fr 2013/2/28 richard duckworth richduckwo...@yahoo.com Hi Katja one of these would do it - check with Thomann tech support for gain issues (these are Instrument Level input) They should be fine however as active guitar pickups (like heavy style EMG pickups) output quite high levels. These type of wireless systems tend to be very rugged, have excellent sound quality and long battery life - and you'll want these things. http://www.thomann.de/ie/cat.html?gf=wireless_for_guitar_bassoa=pra Rich Duckworth Lecturer in Music Technology Department of Music House 5 Trinity College Dublin 2 Ireland Tel 353 1 896 1500 Digital? Is that the thing where they take a good old sine wave and they chop it up into little bits? --- Rupert Neve -- Message: 3 Date: Thu, 28 Feb 2013 11:53:43 +0100 From: katja katjavet...@gmail.com Subject: [PD] wireless audio from Pd to PA system To: pd-list pd-list@iem.at Message-ID: cafy0eappskfw+gvaxutr7exhqlig+ptdu8rk6sntraliys2...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 For a wearable live performance computer, I am looking into the options of sending wireless audio from Pd to a PA sound system and other listeners
[PD] wireless audio from Pd to PA system
For a wearable live performance computer, I am looking into the options of sending wireless audio from Pd to a PA sound system and other listeners. In a first experiment I've tried a Linex FM transmitter. Audio quality is good enough, and FM transmitters do not introduce latency. This option is cheap and flexible, as the signal can be received by simple radio's, which are even built into cell phones and media players. I would need to boost the transmission a bit to make it more reliable. This will of course make the equipment illegal. Even then, the risk that someone else is transmitting a stronger signal on the channel can not be excluded. Another option could be to send audio over Wifi. This would require WLAN to be available, and one extra computer (with audio interface) as a receiver. To avoid extra latency the audio should be sent uncompressed, like [udpsend~] / [udpreceive~] can do it. This has the risk of packet loss and serious dropouts. I've been searching for 2.4 GHz wireless music receivers and found things like this: http://www.sitecom.com/en/wireless-music-streamer/wl-061/p/203. They seem to act like external soundcards for your computer. In Linux though I've never managed to properly connect multiple soundcards with Pd (in OSX it's easy using the Aggregate Device Editor from Audio MIDI Setup). Also I guess these devices introduce huge latency. With audio over bluetooth headsets I've experienced latencies up to a second. Does anyone use a satisfactory method in practice, to send audio from Pd without wires? Thanks, Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Slice//Jockey2 beta, compatible with Pd-E 0.43
Finally I have a public beta of Slice//Jockey2 available. Slice//Jockey is a live-sampling tool for Pd-extended. The original version is shared since 2011. Due to discontinuation of lib toxy, some stuff had to be modified to make Slice//Jockey compatible with Pd-E 0.43. While I was at the job, I took the opportunity to upgrade some effects and overall sound quality. Get SliceJockey2test2.zip from my page: http://www.katjaas.nl/slicejockey/slicejockey.html Please do not hesitate to report bugs if you find any. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] denormals from [cyclone/svf~] on Linux 64 bit
Since last week I have my own Linux 64 bit machine. One of the first issues with Pd-extended on this machine was a strongly increased CPU load when audio input is temporarily shut off from parts of my patch. Subnormals! After three hours of puzzling I identified at least one offender: [cyclone/svf~]. Sorry that most of my posts to this list seem to be about subnormals. That's quite boring. But they're seriously hogging my CPU time like a swarm of grasshoppers. As I got this 64 bit machine so recently I don't know if the issue with [cyclone/svf~] exists in earlier Pd-E versions. Also, I can not understand why it happens, because the object is protected against subnormals with function PD_BIGORSMALL(). This works well on all my other systems. Moreover, it works well for other feedback delay objects like [lop~] on Linux 64 bit. I'd like to know if anyone can confirm the issue. I was planning to do my own state variable filter anyway, but it would be nice to have a working [cyclone/svf~] as well. Check the object with attached patch if you can. To be specific, I have the issue with Pd-E 0.43.4 for Debian Squeeze amd64 from nightly builds. The i386 build is not affected. Katja #N canvas 127 299 620 382 10; #X symbolatom 18 351 72 0 0 0 - - -; #X obj 18 323 makefilename %.70f; #N canvas 0 50 190 245 nan 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 143 * 0; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 6 0; #X connect 2 0 3 0; #X connect 2 1 5 1; #X connect 3 0 5 0; #X connect 4 0 1 0; #X connect 5 0 4 0; #X connect 6 0 2 0; #X restore 18 44 pd nan; #X obj 18 20 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #N canvas 0 50 168 259 inf 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 5 0; #X connect 2 0 3 0; #X connect 2 1 4 1; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 5 0 2 0; #X restore 71 44 pd inf; #X obj 71 20 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 18 181 8 0 0 0 - - -; #X msg 72 114 1; #X msg 72 84 0; #X msg 113 108 \; pd dsp 1; #X msg 113 147 \; pd dsp 0; #X obj 113 85 loadbang; #N canvas 0 50 200 224 unsig~ 0; #X obj 32 40 inlet~; #X obj 32 122 snapshot~; #X obj 61 89 metro 200; #X obj 61 62 tgl 15 1 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 32 153 outlet; #X connect 0 0 1 0; #X connect 1 0 4 0; #X connect 2 0 1 0; #X connect 3 0 2 0; #X restore 18 266 pd unsig~; #X floatatom 18 296 17 0 0 0 - - -; #X text 183 133 Small floats which can't be expressed with the bits of the datatype are also denormal \, more specifically: subnormal. Computations with subnormal numbers are still possible \, but very CPU intensive. Test: click 1 first \, then 0 to see how small the numbers become. If all is OK \, numbers smaller than ~1e-19 are flushed to zero. If not OK \, numbers smaller than 1e-39 are seen. These are subnormals. Check CPU load difference. It is always possible to recover from subnormals by sending a normal number (like 1) in.; #X text 184 320 Katja Vetter Jan 2013; #X text 183 18 NaN and inf are denormal numbers. When inf or nan starts recirculating in a feedback delay line \, the object can't do further calculations \, even if the input goes back to normal. Therefore Pd must avoid writing nan or inf into a feedback delay line. Test: click nan or inf first \, and 1 thereafter. If all is OK \, the output returns to normal. If not OK \, inf or nan will stay at the output and the patch must be reloaded to recover.; #X obj 18 229 svf~ 1; #N canvas 311 334 476 347 lop 0; #N canvas 0 50 190 245 nan 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 143 * 0; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 6 0; #X connect 2 0 3 0; #X connect 2 1 5 1; #X connect 3 0 5 0; #X connect 4 0 1 0; #X connect 5 0 4 0; #X connect 6 0 2 0; #X restore 28 54 pd nan; #X obj 28 30 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #N canvas 0 50 168 259 inf 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 5 0; #X connect 2 0 3 0; #X connect 2 1 4 1; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 5 0 2 0; #X restore 81 54 pd inf; #X obj 81 30 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 28 191 8 0 0 0 - - -; #X msg 82 124 1; #X msg 82 94 0; #N canvas 0 50 200 224 unsig~ 0; #X obj 32 40 inlet~; #X obj 32 122 snapshot~; #X obj 61 89 metro 200; #X obj 61 62 tgl 15 1 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 32 153 outlet; #X connect 0 0 1 0; #X connect 1 0 4 0; #X connect 2 0 1 0; #X connect 3 0 2 0; #X restore 28 276 pd unsig~; #X floatatom 28 306 17 0 0 0 - - -; #X obj 82 215 hsl 100 15 0 200 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 2800 0; #X floatatom 92 240 5 0 0 0 - - -; #X obj 28 239 lop~; #X text 167 27 [lop
Re: [PD] denormals from [cyclone/svf~] on Linux 64 bit
Hi Hans, thanks for your response. I don't consider [bsaylor/svf~] a good alternative, it has aliasing noises with some settings. Oddly, I have a simplified version of [cyclone/svf~] (lopass only) which does work well in Linux 64 bit. So one way or another I should be able to fix [cyclone/svf~]. Not at first sight however. Katja On 2/26/13, Hans-Christoph Steiner h...@at.or.at wrote: I, for one, am very happy that you post on denormal issues! Its great to have these hard technical details worked out so that they don't trip us up in future works :) On my Linux Mint Maya 64-bit machine, I get about 3% CPU before it hits the denormal, then about 11% CPU. Hitting 1 jumps it back down to 3%. Is it worth trying bsaylor/svf~? I don't know if it works better in this situation. I don't think cyclone has gotten many 64-bit fixes. As part of the Pd-extended 0.43.4 release, I did do a push to fix a lot of 64-bit issues related to GUI stuff, but there are still a number of cyclone objects that do not have proper 64-bit array support. .hc On 02/26/2013 04:26 PM, katja wrote: Since last week I have my own Linux 64 bit machine. One of the first issues with Pd-extended on this machine was a strongly increased CPU load when audio input is temporarily shut off from parts of my patch. Subnormals! After three hours of puzzling I identified at least one offender: [cyclone/svf~]. Sorry that most of my posts to this list seem to be about subnormals. That's quite boring. But they're seriously hogging my CPU time like a swarm of grasshoppers. As I got this 64 bit machine so recently I don't know if the issue with [cyclone/svf~] exists in earlier Pd-E versions. Also, I can not understand why it happens, because the object is protected against subnormals with function PD_BIGORSMALL(). This works well on all my other systems. Moreover, it works well for other feedback delay objects like [lop~] on Linux 64 bit. I'd like to know if anyone can confirm the issue. I was planning to do my own state variable filter anyway, but it would be nice to have a working [cyclone/svf~] as well. Check the object with attached patch if you can. To be specific, I have the issue with Pd-E 0.43.4 for Debian Squeeze amd64 from nightly builds. The i386 build is not affected. Katja ___ 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] OT: Alsa configuration debian squeeze
Hi,
On my Panasonic cf-74 with Debian Squeeze 32 bit, audio in Jack and Pd will
only work properly after making a few settings with Gnome Alsa Mixer:
- disable IEC958
- enable capture Rec
I've done a fresh install several times and only with Gnome Alsa Mixer I
could do the right settings for some reason.
Katja
On Thu, Feb 21, 2013 at 5:58 PM, Funs Seelen funssee...@gmail.com wrote:
Hi list,
Sorry for being a little off topic, but I hope to find a solution here.
After spending many many hours trying to get the sound on my new
machine working I feel I'm getting close, but need a last hint. I hope
one of you could help me.
After installing pulseaudio and editing ~/.asoundrc over and over
again sound worked properly for all applications, except for Pd (ALSA
error: Broken pipe). Beside, Jack won't start. I read the recent
thread about `Pd and pulseaudio' here but pulseaudio seems not to be
the problem in my case.
The setup:
- sound card: UA25EX (set to card 0 (snd-usb-audio, index=0));
- OS: Debian Squeeze 32-bit;
- Alsa: Driver version: 1.0.21, Library version: 1.0.23, Utilities
version: 1.0.23
The sound card is compatible with alsa. It has always worked properly
under Ubuntu 10.04 on my netbook, with pulseaudio installed, without
~/.asoundrc or /etc/asound.conf or doing any other sound
configuration.
`aplay' works with pulse and with plughw:0, but not if I select type
hw and card 0 in ~/.asoundrc and choose the default. This seems to
be a bitrate conversion problem (`available sample format S24-3LE'). I
read somewhere that pulse does this conversion automatically, as well
as plughw:0, but I assume that Pd doesn't work with pulseaudio.
Further, I can't find a way to set this `plughw' (of which I don't
know what it actually is or does) as default.
Comparing to another system that does work (now Ubuntu 12.04) I
figured out that /var/lib/alsa/asound.state on my Ubuntu netbook shows
...
state.UA25EX {
control.1 {
iface MIXER
name 'MIDI Input Mode'
value 'Light Load'
comment {
access 'read write'
type ENUMERATED
count 1
item.0 'High Load'
item.1 'Light Load'
}
}
}
while my Debian desktop shows ...
state.UA25EX {
control {
}
}
It is true that I'm not able to set any control in for example
`alsamixer' (This sound device does not have any controls) or with
`amixer cset'. Editing asound.state manually does not help as it is
reset when I `alsactl store'.
Does anyone have a clue how I could fix this problem? I prefer not to
do a new OS install, at least not Ubuntu 12.04 (Unity). That's why I
moved to Debian in the first place.
--Funs
___
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 0.44 vanilla build process
Jonathan, if you do ./configure with option --prefix=absolute path to root dir of that Pd distribution, you can do a local install without su privileges. This doesn't solve the issue with updating but anyway it's convenient. Katja On Wed, Feb 20, 2013 at 11:47 PM, Jonathan Wilkes jancs...@yahoo.comwrote: From: IOhannes m zmoelnig zmoel...@iem.at To: pd-list@iem.at Sent: Wednesday, February 20, 2013 1:45 PM Subject: Re: [PD] pd 0.44 vanilla build process -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-02-20 18:55, Hans-Christoph Steiner wrote: I'd skip the copy and just do: ./autogen.sh ./configure make ./src/pd -nrt(-nrt so it ignores the watchdog) that's not needed with Pd=0.44: if the watchdog cannot be found, Pd will fallback to non-realtime. Thanks for the help. Actually it's not such a big deal to do the cp command. The main problem is that when I make a src code change and do make again, it obviously recompiles the changed files but when I run pd I end up with the old behavior, so it's obviously not updating everything correctly. The src/pd file is a bash script, not an executable, and it seems I have to do make install with su privileges if I want to make an executable. I don't want to go to that trouble, nor do make clean make every time I make changes and test them out. -Jonathan fgjasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlElGdwACgkQkX2Xpv6ydvR0LwCgkys8p87eaOemAOi8kLtFvrAE gEgAoN/3E8WXxJyGau4MTxzbO5c/6Wxj =mdT+ -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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD 4 Pandora
Hi, Pandora is ARM Cortex-A8, that's little endian right? What does portaudio's generated makefile say? I compiled Pd for RPi (ARMv6) and there is (correctly) '-DPA_LITTLE_ENDIAN' among the CFLAGS in portaudio's makefile. Katja On Thu, Feb 14, 2013 at 11:53 AM, dreamer drea...@puikheid.nl wrote: I haven't gotten anywhere with this yet, does anyone else have an idea what I should look at to get alsa working on the pandora? On Sat, Jan 19, 2013 at 11:52 PM, dreamer drea...@puikheid.nl wrote: I've been trying to compile Puredata for the Pandora handheld. Getting the UI to work with tcl/tk 8.5 was fairly straightforward, although the terminal is filled with: watchdog: signalling pd... Otherwise I'm having a lot of issues with alsa. When selecting alsa as output I get: snd_pcm_hw_params (input): Invalid argument snd_pcm_hw_params (output): Invalid argument In the settings I can select two alsa devices: omap3pandora (hardware) omap3pandora (plugin) Which both fail. When I select portaudio output I get: pd: src/common/pa_front.c:325: Pa_Initialize: Assertion `PortAudio: compile time and runtime endianness don't match (((char *)nativeOne)[0]) == 0` failed.Pd: signal 6 And it crashes. Are there some configure flags to mitigate these problems? Some more info on the device in question: http://en.wikipedia.org/wiki/Pandora_%28console%29#Pandora_1GHz Any ideas to get this working are welcome :) regards, drmr ___ 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] Message from the boss of Raspberry Pi Foundation !
Hi Pierre, There has been intensive discussion about GPU processing on RPI: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=33t=6188 Did you read it? In the light of this discussion, I wonder what Eben means when writing We have a bunch of GPU compute available on the device just waiting for an application like this. Anyway it's great they have put your project on RPi blog. You will be famous, Pi Massat! Congrats again. Katja On Fri, Feb 8, 2013 at 10:51 AM, Pierre Massat pimas...@gmail.com wrote: Dear all, Please read below the message I received from Eben Upton, the boss of Raspberry Pi foundation. It looks like he was impressed by the video I made, and he says that there's a possibility of letting the GPU do some DSP computation. I guess you'll all agree that this is awesome news. I have no idea how we can proceed now. I think i'm absolutely incapable of doing anything useful in this field, so i told him that i would transfer this message to you, hoping that Miller, HC, Katja (and others) would know what needs to be done. We should probably ask him if you guys could work directly with their developers. Let me know what you think. Cheers! Pierre. -- Forwarded message -- From: Eben Upton e...@raspberrypi.org Date: 2013/2/8 Subject: Re: RPi as multi-effects for guitar To: Pierre Massat pimas...@gmail.com Hi Pierre Awesome stuff - I think Liz is preparing a blog post about this as we speak. I'd be very interested in knowing a bit more about the DSP code that runs this stuff. We have a bunch of GPU compute available on the device just waiting for an application like this. Cheers Eben On Thu, Feb 7, 2013 at 2:29 AM, Pierre Massat pimas...@gmail.com wrote: Hi, I write a blog about how to make guitar effects with computers running Pure Data in real-time. When I first heard about the Raspberry Pi I thought it would be great if I could use it for the same purpose. It would only be much cheaper, and much smaller than my current laptop, and could fit in my hand-made stompbox. Recent improvements in Raspbian have finally made this possible, and this makes me very happy ! The Raspberry Pi is now actually capable of running rather demanding Pure Data patches in (quasi-) real-time (at least with a latency that's low enough to play live with it). I quickly assembled a small patch to test it and make a video to demonstrate that it actually works very well. It is obviously not the use the RPi was originally intended for, but to me (and I'm sure to other musicians as well), this sounds like a revolution. I'm currently documenting my setup on my blog : - video : http://guitarextended.wordpress.com/2013/01/27/real-time-guitar-effects-with-raspberry-pi-pd-and-arduino/ - blog post about hardware : http://guitarextended.wordpress.com/2013/01/31/raspberry-pi-multi-effects-overview-of-the-setup/ There's no trick, the Pi really IS doing all the DSP work. A reader posted a comment to ask where the computer was :) I take this opportunity to thank the RPi foundation for all the good work you put in this amazing tiny thing. I see that the cam should be out in a few months, this is all very exciting. I'm sure the Pi has already changed the life of a lot of people ! Cheers, Pierre. ___ 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] now that we don't have user-settable global search paths in Pd-E 0.43
Hello, Since a few years I've been using Pd-extended 0.43 incidentally, and since a few months I use it intensively. The discontinuation of user-settable global search paths made me hopping around between alternative solutions, finding out their pro's and cons by (sometimes painful) experience. Don't get me wrong - I think the discontinuation of user-settable global search paths was a good decision. Once you get the best way to work around, it's much easier to share complex patches including dependencies. Initially I preferred the 'namespaces approach'; organize abstractions in folders and instantiate them like you can instantiate objects as [cyclone/svf~], [zexy/limiter~] etc. Sometimes however I felt the need to reorganize folders with abstractions or homebrew externals. Such reorganization forces the namespaces in patches to be refactored. Not good! Then I tried [import] and [declare] instead. I settled on [declare] because it is vanilla Pd, the most flexible approach for all sorts of situations. Fortunately, [declare] doesn't report an error if a path is non-existent, so you can give several options to cover various situations if so desired. I include my home brew binaries and abstractions in subdirs of a project dir, and point to them from the main project patch with [declare -path bin], [declare -path abstractions] and so on. But ow!... with all the namespaces removed I suddenly recalled what makes namespaces so useful. Some classes exist in more than one library. A notable example is [pow~]. There's one in vanilla / Pd core and one in cyclone. Both used to have their exponent and mantissa inlets swapped as compared to [pow]. Somewhere in the Pd 0.43 series, vanilla's [pow~] was refactored to have it's inlets matching the [pow] format. So it became incompatible with Pd 0.42, while [cyclone/pow~] was still compatible with Pd 0.42 and 0.43. Namespaces are also very useful if you have collections of abstractions which you never share but only use for development purposes. For example, I have collections of oscilloscope abstractions and small math utilities. They are stored in their appropriate subdirs on one of the default location as mentioned here: http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files So I can instantiate something like [scopes/scope2~] to quickly check two signal waveforms without including the path in the patch itself, and the object must be removed before the patch is shared. After struggling with Pd search paths for many years, I'm finally starting to get a grip on it. Thanks to / forced by discontinuation of user-settable global paths. No matter how, I guess this will remain tough matter for Pd beginners. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] raspberry pi user experience
Hello, Some people seem to have result with setting lower USB speed on the Pi, but when I try this, the Pi doesn't even respond to keyboard anymore. Checking /boot/cmdline.txt with another computer, I'm sure it is not due to a typo. But the order of settings may be important? Could anyone copy the full text of /boot/cmdline.txt for me, if you have keyboard working with lowered USB speed? (I'm not talking about good audio yet). Thanks, Katja On Sat, Jan 26, 2013 at 8:54 PM, Thomas Grill g...@g.org wrote: Message to self: it seems that one has to wait for updated RPi USB firmware/drivers to get USB 2.0 audio going. Obviously the isochronous transfer mode as used by audio interfaces is currently broken. gr~~~ 2013/1/26 Thomas Grill g...@g.org Hi all, for my USB audio class 2.0 device Native Instruments Komplete Audio 6 i can't report such good news. There is constant irregular crackling, not only with Pd but also with aplay etc. It seems related to USB bandwidth, since turning on and off the inputs in Pd changes crackling frequency. The dwc_otg.speed setting is not usable for me, since the device is dependent on USB 2.0 operation. Any experiences with USB 2.0 audio devices under ALSA/rpi? thanks, gr~~~ 2013/1/26 Cyrille Henry c...@chnry.net hello, I just install raspbian release and update it. then install pd 0.44.1 (without any specific optimisation flag) I made the standard optimisation : * - rtprio 99 * - memlock 10 in /etc/security/limits.conf and dwc_otg.speed=1 in /boot/cmdline.txt as suggested by miller I use a uca222 beringher (that cost about 20 or 25€) sound card. trying the test audio and midi, there is no click with 10ms audio buffer (with adc~ enable). this is with usb keyboard / mouse combo plugged and graphical interface (for the system and for pd). without X, audiobuf can be as low as 5ms having a usb keyboard did not change anything for me. i'm very happy cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Thomas Grill http://g.org -- Thomas Grill http://g.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] raspberry pi user experience
Thanks Pierre and Cyrille. It turned out that various keyboards and mouse just kill USB (when at 1.1) on the Pi. 'Keysonic Wireless Trackball Keyboard' happens to work well. The lower USB speed brings substantial improvement of the audio indeed. Now a real realtime kernel, that would probably improve things further. Katja On Sun, Jan 27, 2013 at 2:33 PM, Cyrille Henry c...@chnry.net wrote: i put it in front of everything : dwc_otg.speed=1 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait cheers c Le 27/01/2013 11:42, katja a écrit : Hello, Some people seem to have result with setting lower USB speed on the Pi, but when I try this, the Pi doesn't even respond to keyboard anymore. Checking /boot/cmdline.txt with another computer, I'm sure it is not due to a typo. But the order of settings may be important? Could anyone copy the full text of /boot/cmdline.txt for me, if you have keyboard working with lowered USB speed? (I'm not talking about good audio yet). Thanks, Katja On Sat, Jan 26, 2013 at 8:54 PM, Thomas Grill g...@g.org wrote: Message to self: it seems that one has to wait for updated RPi USB firmware/drivers to get USB 2.0 audio going. Obviously the isochronous transfer mode as used by audio interfaces is currently broken. gr~~~ 2013/1/26 Thomas Grill g...@g.org Hi all, for my USB audio class 2.0 device Native Instruments Komplete Audio 6 i can't report such good news. There is constant irregular crackling, not only with Pd but also with aplay etc. It seems related to USB bandwidth, since turning on and off the inputs in Pd changes crackling frequency. The dwc_otg.speed setting is not usable for me, since the device is dependent on USB 2.0 operation. Any experiences with USB 2.0 audio devices under ALSA/rpi? thanks, gr~~~ 2013/1/26 Cyrille Henry c...@chnry.net hello, I just install raspbian release and update it. then install pd 0.44.1 (without any specific optimisation flag) I made the standard optimisation : * - rtprio 99 * - memlock 10 in /etc/security/limits.conf and dwc_otg.speed=1 in /boot/cmdline.txt as suggested by miller I use a uca222 beringher (that cost about 20 or 25€) sound card. trying the test audio and midi, there is no click with 10ms audio buffer (with adc~ enable). this is with usb keyboard / mouse combo plugged and graphical interface (for the system and for pd). without X, audiobuf can be as low as 5ms having a usb keyboard did not change anything for me. i'm very happy cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Thomas Grill http://g.org -- Thomas Grill http://g.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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi as rt guitar effect processor : proof of concept
Congratulations Pierre! You're Guitar Extended concept is really great. cheers, Katja On Sun, Jan 27, 2013 at 5:00 PM, Pierre Massat pimas...@gmail.com wrote: http://www.youtube.com/watch?v=NwJNeouLqgQfeature=youtu.be Dear all, It's working !!! :) It looks like a revolution to me. The effect in the second half is a sampler based on the phase-vocoder patch by Miller Puckette. I've set Pd to use a 16 ms buffer to get it to work without dropouts. It's a bit high but this is a demanding patch. I'll be documenting this on my blog, and i'd be glad to have feedback from you, about working/non-working audio interfaces for instance. Cheers! Pierre. ___ 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] raspberry pi user experience
Both are already mentioned but I'd like to confirm that these do work on RPi (provided the USB speed is lowered as described in this thread): iMic and Behringer UCA202. Katja On Sun, Jan 27, 2013 at 5:51 PM, Miller Puckette m...@ucsd.edu wrote: I heard suggestions on the Pi sites (I forget exactly where) that the USB 2.0 implementation isn't compatible with a large variety of USB 2.0 devices (including for instance the Griffin iMic). So I don't think the issue is the load that USB 2.0 puts on the Pi, it's simply bugs. But I gather nobody is in a hurry to get them fixed - the attitude in Cambridge is that it's the devices' fault, not the Pi's. I have beem suspecting that my keyboard is also incompatible with the Pi at USB 1.1 speed. I haven't tried other keyboards yet since I'm usually happy to ssh in without any other USB devices (besides audio and ethernet) talking to the Pi. But this is not always true so soon enough I'll have to try other keyboards so I can get the thing working as a standalone computer. cheers Miller On Sun, Jan 27, 2013 at 04:50:16PM +0100, katja wrote: Thanks Pierre and Cyrille. It turned out that various keyboards and mouse just kill USB (when at 1.1) on the Pi. 'Keysonic Wireless Trackball Keyboard' happens to work well. The lower USB speed brings substantial improvement of the audio indeed. Now a real realtime kernel, that would probably improve things further. Katja On Sun, Jan 27, 2013 at 2:33 PM, Cyrille Henry c...@chnry.net wrote: i put it in front of everything : dwc_otg.speed=1 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait cheers c Le 27/01/2013 11:42, katja a écrit : Hello, Some people seem to have result with setting lower USB speed on the Pi, but when I try this, the Pi doesn't even respond to keyboard anymore. Checking /boot/cmdline.txt with another computer, I'm sure it is not due to a typo. But the order of settings may be important? Could anyone copy the full text of /boot/cmdline.txt for me, if you have keyboard working with lowered USB speed? (I'm not talking about good audio yet). Thanks, Katja On Sat, Jan 26, 2013 at 8:54 PM, Thomas Grill g...@g.org wrote: Message to self: it seems that one has to wait for updated RPi USB firmware/drivers to get USB 2.0 audio going. Obviously the isochronous transfer mode as used by audio interfaces is currently broken. gr~~~ 2013/1/26 Thomas Grill g...@g.org Hi all, for my USB audio class 2.0 device Native Instruments Komplete Audio 6 i can't report such good news. There is constant irregular crackling, not only with Pd but also with aplay etc. It seems related to USB bandwidth, since turning on and off the inputs in Pd changes crackling frequency. The dwc_otg.speed setting is not usable for me, since the device is dependent on USB 2.0 operation. Any experiences with USB 2.0 audio devices under ALSA/rpi? thanks, gr~~~ 2013/1/26 Cyrille Henry c...@chnry.net hello, I just install raspbian release and update it. then install pd 0.44.1 (without any specific optimisation flag) I made the standard optimisation : * - rtprio 99 * - memlock 10 in /etc/security/limits.conf and dwc_otg.speed=1 in /boot/cmdline.txt as suggested by miller I use a uca222 beringher (that cost about 20 or 25€) sound card. trying the test audio and midi, there is no click with 10ms audio buffer (with adc~ enable). this is with usb keyboard / mouse combo plugged and graphical interface (for the system and for pd). without X, audiobuf can be as low as 5ms having a usb keyboard did not change anything for me. i'm very happy cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Thomas Grill http://g.org -- Thomas Grill http://g.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 ___ 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] Start Katja's Pd from command line on rpi with full path (was) Raspberry Pi does denormals
Hi Julian, Most convenient is to go in the bin directory of that 'local' Pd with cd /place/where/new/pd/is/bin From there you can start (and restart) the local Pd with ./pd In my case, the recompiled Pd would not start because it could not find libportaudio.so.2. After installing libportaudio2 via Synaptic, 'normalized' Pd would finally start. It is no problem to have the regular Pd still installed. Maybe you can install the local Pd over the regular Pd using the gnumakefile. Didn't try that, I don't like to install things without package manager. Katja On Fri, Jan 25, 2013 at 3:41 PM, Julian Brooks jbee...@gmail.com wrote: Excuse my ignorance: not sure how to start the below version of pd on the rpi? I have the full path but then what? if I do (in command line) pd /place/where/new/pd/is/bin/pd It signals watchdog. I also still have regular pd 0.44.0 installed btw. Sorry if this is dumb dumb dumb dumb Duuummmbbb. Jb On 24 January 2013 09:14, katja katjavet...@gmail.com wrote: 'Undenormalized' Pd build for Raspberry Pi is temporarily parked here for testing purposes (will be removed when Miller's release is fixed in this sense): www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz This is a locally installed Pd, like Miller's distribution. You can start it from command line with the full path to pd-0.44-0-normalized/bin/pd. It's not a .deb, so it can't be installed under supervision of package manager. Katja On Wed, Jan 23, 2013 at 9:15 PM, Julian Brooks jbee...@gmail.com wrote: Hey Katja, Would you mind sharing the 'normalised' Pd-0.44.0 for RPi please. Cheers, Julian On 23 January 2013 18:23, katja katjavet...@gmail.com wrote: Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a few hours, not only because Pi is so slow) with PD_BIGORSMALL enabled for arm in m_pd.h. Using bigorsmalltest.pd from my previous mail I verified that the macro is implemented indeed. Martin Brinkmann's patch chaosmonster1 (http://www.martin-brinkmann.de) gives a beautiful illustration of the improvement. This patch is full of filters and delay lines. At it's initial settings, there is no subnormals problem. But if you set the bottom slider to the right, it gets silent. With Pd-0.44-0 release, CPU load explodes. With the 'normalized' Pd, nothing special happens. And indeed, the PD_BIGORSMALL conditional checks come for free: with initial settings of the chaosmonster1, performance is equivalent in both Pd's. Cool! Hopefully this is similar on armv7. Katja On Wed, Jan 23, 2013 at 5:01 PM, Hans-Christoph Steiner h...@at.or.at wrote: hey Katya, This also sounds like good evidence for your idea of writing C code that modern compilers optimize well. Using unions for aliasing allows the compiler to do all the new tricks, then writing loops that auto-vectorize gives us the real benefits. Also, I think we can see some gains by using memcpy() since on modern libc version, those are highly optimized for the given CPU, dynamically choosing the routines based on what instructions are available. memcpy will use things like SSSE2 if its available. .hc On 01/23/2013 07:47 AM, katja wrote: Finally some good news on this topic. Earlier I stated that 'big or small tests' are expensive for the Pi, but that is not by definition the case. There must have been other conditions blurring my impression. I've now done a systematic test where other influences are ruled out. A test class [lopass~] with exactly the same routine as [lop~] was made, but compiled with PD_BIGORSMALL() macro enabled. It was verified that [lopass~] is not affected by denormals. Performance comparison of [lop~] and [lopass~] shows that both objects cause equivalent CPU load. Meaning, Raspberry Pi gives the 'big or small checks' for free! At least in the case of this simple filter. Please try attached bigorsmalltest.zip on the Pi to see if I'm not dreaming. While I was at the topic anyway, I also tried a big or small test with union instead of direct type aliasing. It has the advantage that the compiler can apply strict aliasing rules. This test with unions did not cause extra CPU load either on the Pi. If you want to verify this result, enable the call to bigorsmall() instead of PD_BIGORSMALL in lopass~.c and recompile. The fact that these tests do not cause extra CPU load, indicate that they are done in parallel with other instructions. Float and int registers are apparently strictly separated on armv6, there's no such thing like Intel's xmm registers or armv7's NEON. As it happens, the big or small tests are done on ints, aliases of the floats that must be tested. Initially I assumed that the transport of floats from vfp to the arm integer processor would be expensive, but if the instructions are done
Re: [PD] Start Katja's Pd from command line on rpi with full path (was) Raspberry Pi does denormals
Sorry that must be my fault, archived it with default options. I'll have a look into that and let you know when a better .tar is uploaded. Katja On Fri, Jan 25, 2013 at 4:53 PM, Julian Brooks jbee...@gmail.com wrote: Hi Katja, Thanks for this. When I cd into bin then ./pd I get 'permission denied'. And sudo'd I get 'command not found'. Any other ideas? Jb On 25 January 2013 15:36, katja katjavet...@gmail.com wrote: Hi Julian, Most convenient is to go in the bin directory of that 'local' Pd with cd /place/where/new/pd/is/bin From there you can start (and restart) the local Pd with ./pd In my case, the recompiled Pd would not start because it could not find libportaudio.so.2. After installing libportaudio2 via Synaptic, 'normalized' Pd would finally start. It is no problem to have the regular Pd still installed. Maybe you can install the local Pd over the regular Pd using the gnumakefile. Didn't try that, I don't like to install things without package manager. Katja On Fri, Jan 25, 2013 at 3:41 PM, Julian Brooks jbee...@gmail.com wrote: Excuse my ignorance: not sure how to start the below version of pd on the rpi? I have the full path but then what? if I do (in command line) pd /place/where/new/pd/is/bin/pd It signals watchdog. I also still have regular pd 0.44.0 installed btw. Sorry if this is dumb dumb dumb dumb Duuummmbbb. Jb On 24 January 2013 09:14, katja katjavet...@gmail.com wrote: 'Undenormalized' Pd build for Raspberry Pi is temporarily parked here for testing purposes (will be removed when Miller's release is fixed in this sense): www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz This is a locally installed Pd, like Miller's distribution. You can start it from command line with the full path to pd-0.44-0-normalized/bin/pd. It's not a .deb, so it can't be installed under supervision of package manager. Katja On Wed, Jan 23, 2013 at 9:15 PM, Julian Brooks jbee...@gmail.com wrote: Hey Katja, Would you mind sharing the 'normalised' Pd-0.44.0 for RPi please. Cheers, Julian On 23 January 2013 18:23, katja katjavet...@gmail.com wrote: Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a few hours, not only because Pi is so slow) with PD_BIGORSMALL enabled for arm in m_pd.h. Using bigorsmalltest.pd from my previous mail I verified that the macro is implemented indeed. Martin Brinkmann's patch chaosmonster1 (http://www.martin-brinkmann.de) gives a beautiful illustration of the improvement. This patch is full of filters and delay lines. At it's initial settings, there is no subnormals problem. But if you set the bottom slider to the right, it gets silent. With Pd-0.44-0 release, CPU load explodes. With the 'normalized' Pd, nothing special happens. And indeed, the PD_BIGORSMALL conditional checks come for free: with initial settings of the chaosmonster1, performance is equivalent in both Pd's. Cool! Hopefully this is similar on armv7. Katja On Wed, Jan 23, 2013 at 5:01 PM, Hans-Christoph Steiner h...@at.or.at wrote: hey Katya, This also sounds like good evidence for your idea of writing C code that modern compilers optimize well. Using unions for aliasing allows the compiler to do all the new tricks, then writing loops that auto-vectorize gives us the real benefits. Also, I think we can see some gains by using memcpy() since on modern libc version, those are highly optimized for the given CPU, dynamically choosing the routines based on what instructions are available. memcpy will use things like SSSE2 if its available. .hc On 01/23/2013 07:47 AM, katja wrote: Finally some good news on this topic. Earlier I stated that 'big or small tests' are expensive for the Pi, but that is not by definition the case. There must have been other conditions blurring my impression. I've now done a systematic test where other influences are ruled out. A test class [lopass~] with exactly the same routine as [lop~] was made, but compiled with PD_BIGORSMALL() macro enabled. It was verified that [lopass~] is not affected by denormals. Performance comparison of [lop~] and [lopass~] shows that both objects cause equivalent CPU load. Meaning, Raspberry Pi gives the 'big or small checks' for free! At least in the case of this simple filter. Please try attached bigorsmalltest.zip on the Pi to see if I'm not dreaming. While I was at the topic anyway, I also tried a big or small test with union instead of direct type aliasing. It has the advantage that the compiler can apply strict aliasing rules. This test with unions did not cause extra CPU load either on the Pi. If you want to verify
Re: [PD] Raspberry Pi does denormals
'Undenormalized' Pd build for Raspberry Pi is temporarily parked here for testing purposes (will be removed when Miller's release is fixed in this sense): www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz This is a locally installed Pd, like Miller's distribution. You can start it from command line with the full path to pd-0.44-0-normalized/bin/pd. It's not a .deb, so it can't be installed under supervision of package manager. Katja On Wed, Jan 23, 2013 at 9:15 PM, Julian Brooks jbee...@gmail.com wrote: Hey Katja, Would you mind sharing the 'normalised' Pd-0.44.0 for RPi please. Cheers, Julian On 23 January 2013 18:23, katja katjavet...@gmail.com wrote: Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a few hours, not only because Pi is so slow) with PD_BIGORSMALL enabled for arm in m_pd.h. Using bigorsmalltest.pd from my previous mail I verified that the macro is implemented indeed. Martin Brinkmann's patch chaosmonster1 (http://www.martin-brinkmann.de) gives a beautiful illustration of the improvement. This patch is full of filters and delay lines. At it's initial settings, there is no subnormals problem. But if you set the bottom slider to the right, it gets silent. With Pd-0.44-0 release, CPU load explodes. With the 'normalized' Pd, nothing special happens. And indeed, the PD_BIGORSMALL conditional checks come for free: with initial settings of the chaosmonster1, performance is equivalent in both Pd's. Cool! Hopefully this is similar on armv7. Katja On Wed, Jan 23, 2013 at 5:01 PM, Hans-Christoph Steiner h...@at.or.at wrote: hey Katya, This also sounds like good evidence for your idea of writing C code that modern compilers optimize well. Using unions for aliasing allows the compiler to do all the new tricks, then writing loops that auto-vectorize gives us the real benefits. Also, I think we can see some gains by using memcpy() since on modern libc version, those are highly optimized for the given CPU, dynamically choosing the routines based on what instructions are available. memcpy will use things like SSSE2 if its available. .hc On 01/23/2013 07:47 AM, katja wrote: Finally some good news on this topic. Earlier I stated that 'big or small tests' are expensive for the Pi, but that is not by definition the case. There must have been other conditions blurring my impression. I've now done a systematic test where other influences are ruled out. A test class [lopass~] with exactly the same routine as [lop~] was made, but compiled with PD_BIGORSMALL() macro enabled. It was verified that [lopass~] is not affected by denormals. Performance comparison of [lop~] and [lopass~] shows that both objects cause equivalent CPU load. Meaning, Raspberry Pi gives the 'big or small checks' for free! At least in the case of this simple filter. Please try attached bigorsmalltest.zip on the Pi to see if I'm not dreaming. While I was at the topic anyway, I also tried a big or small test with union instead of direct type aliasing. It has the advantage that the compiler can apply strict aliasing rules. This test with unions did not cause extra CPU load either on the Pi. If you want to verify this result, enable the call to bigorsmall() instead of PD_BIGORSMALL in lopass~.c and recompile. The fact that these tests do not cause extra CPU load, indicate that they are done in parallel with other instructions. Float and int registers are apparently strictly separated on armv6, there's no such thing like Intel's xmm registers or armv7's NEON. As it happens, the big or small tests are done on ints, aliases of the floats that must be tested. Initially I assumed that the transport of floats from vfp to the arm integer processor would be expensive, but if the instructions are done simultaneously it may be an advantage instead. Another thing is that ARM implements branch predication instead of branch prediction. Those terms look almost the same but the routines are very different. Predication is when instructions for both branches are executed, and the wrong result is simply discarded later. Conclusions from the limited test with [lop~] and [lopass~] do not mean that all sorts of conditional checks are cheap on the Pi, or on ARM in general. If PD_BIGORSMALL is enabled for RPi using compile-time definition __arm__, it will also hold for armv7, but it may have very different result there. At the moment I have no access yet to an armv7 device. Maybe someone can recompile test class [lopass~] and do the tests on Beagleboard or Cubieboard? Otherwise I may be able to do it on my friend's PengPod when that has arrived. Katja On Tue, Jan 22, 2013 at 8:54 PM, Miller Puckette m...@ucsd.edu wrote: thanks - I'd better try this and find out what's going on :) M On Mon, Jan 21, 2013 at 11:54:29AM +0100, katja wrote: Tried the 0.44.0 build from your website
Re: [PD] Raspberry Pi does denormals
On Wed, Jan 23, 2013 at 8:00 PM, padawa...@obiwannabe.co.uk padawa...@obiwannabe.co.uk wrote: On 23 January 2013 at 18:23 katja katjavet...@gmail.com wrote: Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a few hours, not only because Pi is so slow) Have you looked into cross compiling options much? there's plenty of arm7 support avail lst time I looked Just thinking out loud a. I haven't looked at cross compiling options yet. Frankly, I'm fascinated by the fact that Raspberry Pi is self-supporting. All the GNU tools and other familiar deb packages working on a pocket size circuit board. That's why I like RPi (and not the Android/iOS gadgets). If you know what you're doing, you can start some job and leave Pi alone. In the case of compiling Pd, the job was interrupted by errors several times. Install instructions could be more complete. I should make some notes and post them. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi does denormals
Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a few hours, not only because Pi is so slow) with PD_BIGORSMALL enabled for arm in m_pd.h. Using bigorsmalltest.pd from my previous mail I verified that the macro is implemented indeed. Martin Brinkmann's patch chaosmonster1 (http://www.martin-brinkmann.de) gives a beautiful illustration of the improvement. This patch is full of filters and delay lines. At it's initial settings, there is no subnormals problem. But if you set the bottom slider to the right, it gets silent. With Pd-0.44-0 release, CPU load explodes. With the 'normalized' Pd, nothing special happens. And indeed, the PD_BIGORSMALL conditional checks come for free: with initial settings of the chaosmonster1, performance is equivalent in both Pd's. Cool! Hopefully this is similar on armv7. Katja On Wed, Jan 23, 2013 at 5:01 PM, Hans-Christoph Steiner h...@at.or.at wrote: hey Katya, This also sounds like good evidence for your idea of writing C code that modern compilers optimize well. Using unions for aliasing allows the compiler to do all the new tricks, then writing loops that auto-vectorize gives us the real benefits. Also, I think we can see some gains by using memcpy() since on modern libc version, those are highly optimized for the given CPU, dynamically choosing the routines based on what instructions are available. memcpy will use things like SSSE2 if its available. .hc On 01/23/2013 07:47 AM, katja wrote: Finally some good news on this topic. Earlier I stated that 'big or small tests' are expensive for the Pi, but that is not by definition the case. There must have been other conditions blurring my impression. I've now done a systematic test where other influences are ruled out. A test class [lopass~] with exactly the same routine as [lop~] was made, but compiled with PD_BIGORSMALL() macro enabled. It was verified that [lopass~] is not affected by denormals. Performance comparison of [lop~] and [lopass~] shows that both objects cause equivalent CPU load. Meaning, Raspberry Pi gives the 'big or small checks' for free! At least in the case of this simple filter. Please try attached bigorsmalltest.zip on the Pi to see if I'm not dreaming. While I was at the topic anyway, I also tried a big or small test with union instead of direct type aliasing. It has the advantage that the compiler can apply strict aliasing rules. This test with unions did not cause extra CPU load either on the Pi. If you want to verify this result, enable the call to bigorsmall() instead of PD_BIGORSMALL in lopass~.c and recompile. The fact that these tests do not cause extra CPU load, indicate that they are done in parallel with other instructions. Float and int registers are apparently strictly separated on armv6, there's no such thing like Intel's xmm registers or armv7's NEON. As it happens, the big or small tests are done on ints, aliases of the floats that must be tested. Initially I assumed that the transport of floats from vfp to the arm integer processor would be expensive, but if the instructions are done simultaneously it may be an advantage instead. Another thing is that ARM implements branch predication instead of branch prediction. Those terms look almost the same but the routines are very different. Predication is when instructions for both branches are executed, and the wrong result is simply discarded later. Conclusions from the limited test with [lop~] and [lopass~] do not mean that all sorts of conditional checks are cheap on the Pi, or on ARM in general. If PD_BIGORSMALL is enabled for RPi using compile-time definition __arm__, it will also hold for armv7, but it may have very different result there. At the moment I have no access yet to an armv7 device. Maybe someone can recompile test class [lopass~] and do the tests on Beagleboard or Cubieboard? Otherwise I may be able to do it on my friend's PengPod when that has arrived. Katja On Tue, Jan 22, 2013 at 8:54 PM, Miller Puckette m...@ucsd.edu wrote: thanks - I'd better try this and find out what's going on :) M On Mon, Jan 21, 2013 at 11:54:29AM +0100, katja wrote: Tried the 0.44.0 build from your website. It has the same issue with subnormal values. My test patch is with [lop~]. If inf or nan is fed into [lop~], these 'values' keep circulating in the object, it can no longer process normal signal values. I also tried my reverb stuff with specific compiler options for Pi's processor: -march=armv6zk -mcpu=arm1176jzf-s -mtune=arm1176jzf-s With these options, gcc should be able to decide that RunFast mode is permitted. But even in combination with -ffast-math (which in turn sets -funsafe-math-optimizations and -fno-trapping-math amongst others), denormals are still there. I'm literally out of options for the moment. Sorry for not having better news. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE
Re: [PD] Raspberry Pi does denormals
Hey Pierre, I've commented patch denorm-test.pd in such a way that it explains the topic a bit more (see attached). Now I'd like to ask you, if you can run the patch on a 'normal' computer and on your Raspberry Pi for comparison. If you have Pd gui on the Pi, you should be able to check if your Pd install has a denormals issue. It's hard to believe that I would be the only one experiencing this issue, but I need to be sure. In my previous mail I stated that it is easy to avoid subnormals by just feeding a very small number in objects that may decay into subnormal range (feedback delay lines and most filters). But in practice, this is not always so easy, as I am now experiencing while trying to make a big patch work well on the Pi. There are many more filters than I was aware of. For example, following a bit-mangling operation a [hip~] was added to remove DC. Now if the bit-mangler stops receiving signal input, [hip~] starts to chew subnormals until it will receive signal again. I found that each filter struggling with subnormals eats at least 6% CPU time (while they do some 0.25% in normal state). Pd objects should really take care of this in one way or another, it's too confusing for the user to sort it out. I'm going to try recompile Pd with PD_BIGORSMALL checks enabled, and see what it means for the normal performance of the filter objects. Katja On Mon, Jan 21, 2013 at 4:24 PM, Pierre Massat pimas...@gmail.com wrote: Hi Katja, thank you for your reply! It is now (slightly) clearer. Every time you post something here I feel like some messages from a technical NASA mailing list are being accidentally sent to pd-list! Cheers, Pierre. 2013/1/21 katja katjavet...@gmail.com Pierre, the way how denormals can impact performance on the Pi, is whenever a an object with feedback delay (IIR filter, reverb etc.) stops receiving input signal, it's values decay into the subnormal range, which causes substantial increase of CPU load. Such situations can be avoided by adding a tiny DC value to the object input, like [+~ 1e-21] (note the minus sign in the number notation). When a normal audio signal is present, that number is too small to be added (because of limited precision), but when audio stops, it prevents subnormals. Another thing is, one should be careful not to accidentally send 'inf' or 'nan' into such objects, as they can not recover from it. This would be particularly annoying in a public performance, since you'd need to reload the containing patch to recover. It is possible to prevent denormals via C code, as it is currently done for Pd on Intel processors, but this implements a lot of conditional checks and it means performance loss for many objects. For current Intel computers the extra load is not so much of a problem, but for poor Raspberry Pi one would rather like to save a few instructions, instead of adding more. Katja On Sun, Jan 20, 2013 at 5:27 PM, Pierre Massat pimas...@gmail.com wrote: Hi, Could someone please explain how this impacts Pd's performance on the Raspberry Pi ? It doesn't make any sense to me right now, but i'm very curious... Cheers, Pierre. 2013/1/20 Hans-Christoph Steiner h...@at.or.at I think this is what you want, from 'man gcc'. Its interesting to note that the NEON mode, which provides SIMD, also does not do denormals: -mfpu=name -mfpe=number -mfp=number This specifies what floating point hardware (or hardware emulation) is available on the target. Permissible names are: fpa, fpe2, fpe3, maverick, vfp, vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16 and neon-vfpv4. -mfp and -mfpe are synonyms for -mfpu=fpenumber, for compatibility with older versions of GCC. If -msoft-float is specified this specifies the format of floating point values. If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=neon), note that floating-point operations will not be used by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision. .hc On 01/20/2013 06:54 AM, katja wrote: I was assuming, or maybe just hoping? that Raspberry Pi (and ARM devices in general) would not suffer from Denormal's disease like Intel processors do. But guess what: Pi's float coprocessor is IEEE 754 compliant and does all denormals by default (can check with attached denorm-test.pd). Bummer! As if one would use an ARM device to calculate the size of a Majorana particle, rather than doing simple dsp. Do we really need to enable PD-BIGORSMALL() checks
Re: [PD] Raspberry Pi does denormals
Tried the 0.44.0 build from your website. It has the same issue with subnormal values. My test patch is with [lop~]. If inf or nan is fed into [lop~], these 'values' keep circulating in the object, it can no longer process normal signal values. I also tried my reverb stuff with specific compiler options for Pi's processor: -march=armv6zk -mcpu=arm1176jzf-s -mtune=arm1176jzf-s With these options, gcc should be able to decide that RunFast mode is permitted. But even in combination with -ffast-math (which in turn sets -funsafe-math-optimizations and -fno-trapping-math amongst others), denormals are still there. I'm literally out of options for the moment. Sorry for not having better news. Katja On Sun, Jan 20, 2013 at 9:51 PM, Miller Puckette m...@ucsd.edu wrote: OK.. but try the 0.44 build on my site - the one from Raspian is quite old :) M On Sun, Jan 20, 2013 at 09:28:30PM +0100, katja wrote: Miller, the vanilla Pd which can be installed from Raspbian with apt-get or Synaptic does have the subnormals problem, as can be checked with a test patch attached with my first post. When an input signal to [lop~] is shut off, CPU load increases substantially. Output values go down in the order of 1e-44, subnormal range. I was working on reverb algo's showing the same problem, and compiled with option -ffastmath / --fast-math to see if that would turn on RunFast mode, but it didn't. I'm not familiar with ARM and it's coprocessors, but from Intel I do know that gcc doesn't implement certain specified optimization options (notably SSE versions) unless you also mention a processor type that can handle it . A similar case could be with Rpi's vfpv2; it can do RunFast mode but gcc doesn't implement it, until you find a way to specify vfpv2 (vfpv1 can't do RunFast). Miller, if you succeeded in getting automatic flush-to-zero on the Pi, it may be related to other flags which you've set. Arch flags which I've set so far are -march=armv6 and -mfpu=vfp. Option -mfpu=vfpv2 is not allowed. I would be happy to do further testing with compiler options, if you know some. The big-or-small checks are rather expensive for RPi, that's what I've found. Katja On Sun, Jan 20, 2013 at 8:24 PM, Miller Puckette m...@ucsd.edu wrote: Hi all... I think it's possible to get flush-to-zero behavior on the Pi (ARMv6) by calling gcc with --fast-math. At any rate what I found was that, if I compiled without --fast-math, when numbers got small (e.g., when a reverberator decays down past 10^-38 or so), the patch would suddenly jump in CPI usage as if it were trappnig to the kernel (as it does for i386). But when I added --fast-math the problem went away. On i386 and x86_64, I believe that one can't get flush-to-zero (at least in the normal non-SSE floating point instructions) so there's no choice but to use a macro such as PD_BADFLOAT to protect against that. So in m_pd.h the PD_BADFLOAT macro is only turned on for Intel. However I've been mistaken many times about all this in the past and won't be surprised if I'm mistaken again. cheers Miller On Sun, Jan 20, 2013 at 11:12:28AM -0500, Hans-Christoph Steiner wrote: I think this is what you want, from 'man gcc'. Its interesting to note that the NEON mode, which provides SIMD, also does not do denormals: -mfpu=name -mfpe=number -mfp=number This specifies what floating point hardware (or hardware emulation) is available on the target. Permissible names are: fpa, fpe2, fpe3, maverick, vfp, vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16 and neon-vfpv4. -mfp and -mfpe are synonyms for -mfpu=fpenumber, for compatibility with older versions of GCC. If -msoft-float is specified this specifies the format of floating point values. If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=neon), note that floating-point operations will not be used by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision. .hc On 01/20/2013 06:54 AM, katja wrote: I was assuming, or maybe just hoping? that Raspberry Pi (and ARM devices in general) would not suffer from Denormal's disease like Intel processors do. But guess what: Pi's float coprocessor is IEEE 754 compliant and does all denormals by default (can check with attached denorm-test.pd). Bummer! As if one would use an ARM device to calculate the size of a Majorana particle, rather than doing simple dsp. Do we really need to enable PD-BIGORSMALL() checks for this poor little
Re: [PD] Raspberry Pi does denormals
Pierre, the way how denormals can impact performance on the Pi, is whenever a an object with feedback delay (IIR filter, reverb etc.) stops receiving input signal, it's values decay into the subnormal range, which causes substantial increase of CPU load. Such situations can be avoided by adding a tiny DC value to the object input, like [+~ 1e-21] (note the minus sign in the number notation). When a normal audio signal is present, that number is too small to be added (because of limited precision), but when audio stops, it prevents subnormals. Another thing is, one should be careful not to accidentally send 'inf' or 'nan' into such objects, as they can not recover from it. This would be particularly annoying in a public performance, since you'd need to reload the containing patch to recover. It is possible to prevent denormals via C code, as it is currently done for Pd on Intel processors, but this implements a lot of conditional checks and it means performance loss for many objects. For current Intel computers the extra load is not so much of a problem, but for poor Raspberry Pi one would rather like to save a few instructions, instead of adding more. Katja On Sun, Jan 20, 2013 at 5:27 PM, Pierre Massat pimas...@gmail.com wrote: Hi, Could someone please explain how this impacts Pd's performance on the Raspberry Pi ? It doesn't make any sense to me right now, but i'm very curious... Cheers, Pierre. 2013/1/20 Hans-Christoph Steiner h...@at.or.at I think this is what you want, from 'man gcc'. Its interesting to note that the NEON mode, which provides SIMD, also does not do denormals: -mfpu=name -mfpe=number -mfp=number This specifies what floating point hardware (or hardware emulation) is available on the target. Permissible names are: fpa, fpe2, fpe3, maverick, vfp, vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16 and neon-vfpv4. -mfp and -mfpe are synonyms for -mfpu=fpenumber, for compatibility with older versions of GCC. If -msoft-float is specified this specifies the format of floating point values. If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=neon), note that floating-point operations will not be used by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision. .hc On 01/20/2013 06:54 AM, katja wrote: I was assuming, or maybe just hoping? that Raspberry Pi (and ARM devices in general) would not suffer from Denormal's disease like Intel processors do. But guess what: Pi's float coprocessor is IEEE 754 compliant and does all denormals by default (can check with attached denorm-test.pd). Bummer! As if one would use an ARM device to calculate the size of a Majorana particle, rather than doing simple dsp. Do we really need to enable PD-BIGORSMALL() checks for this poor little processor? There seems to be something called 'RunFast mode' for Pi's float processor vfpv2, but I see no way how to enable this via gcc. Option -ffast-math is allowed but doesn't do the trick. Can't find an option to set vfpv2 specifically, in gcc docs. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi does denormals
Miller, the vanilla Pd which can be installed from Raspbian with apt-get or Synaptic does have the subnormals problem, as can be checked with a test patch attached with my first post. When an input signal to [lop~] is shut off, CPU load increases substantially. Output values go down in the order of 1e-44, subnormal range. I was working on reverb algo's showing the same problem, and compiled with option -ffastmath / --fast-math to see if that would turn on RunFast mode, but it didn't. I'm not familiar with ARM and it's coprocessors, but from Intel I do know that gcc doesn't implement certain specified optimization options (notably SSE versions) unless you also mention a processor type that can handle it . A similar case could be with Rpi's vfpv2; it can do RunFast mode but gcc doesn't implement it, until you find a way to specify vfpv2 (vfpv1 can't do RunFast). Miller, if you succeeded in getting automatic flush-to-zero on the Pi, it may be related to other flags which you've set. Arch flags which I've set so far are -march=armv6 and -mfpu=vfp. Option -mfpu=vfpv2 is not allowed. I would be happy to do further testing with compiler options, if you know some. The big-or-small checks are rather expensive for RPi, that's what I've found. Katja On Sun, Jan 20, 2013 at 8:24 PM, Miller Puckette m...@ucsd.edu wrote: Hi all... I think it's possible to get flush-to-zero behavior on the Pi (ARMv6) by calling gcc with --fast-math. At any rate what I found was that, if I compiled without --fast-math, when numbers got small (e.g., when a reverberator decays down past 10^-38 or so), the patch would suddenly jump in CPI usage as if it were trappnig to the kernel (as it does for i386). But when I added --fast-math the problem went away. On i386 and x86_64, I believe that one can't get flush-to-zero (at least in the normal non-SSE floating point instructions) so there's no choice but to use a macro such as PD_BADFLOAT to protect against that. So in m_pd.h the PD_BADFLOAT macro is only turned on for Intel. However I've been mistaken many times about all this in the past and won't be surprised if I'm mistaken again. cheers Miller On Sun, Jan 20, 2013 at 11:12:28AM -0500, Hans-Christoph Steiner wrote: I think this is what you want, from 'man gcc'. Its interesting to note that the NEON mode, which provides SIMD, also does not do denormals: -mfpu=name -mfpe=number -mfp=number This specifies what floating point hardware (or hardware emulation) is available on the target. Permissible names are: fpa, fpe2, fpe3, maverick, vfp, vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16 and neon-vfpv4. -mfp and -mfpe are synonyms for -mfpu=fpenumber, for compatibility with older versions of GCC. If -msoft-float is specified this specifies the format of floating point values. If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=neon), note that floating-point operations will not be used by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision. .hc On 01/20/2013 06:54 AM, katja wrote: I was assuming, or maybe just hoping? that Raspberry Pi (and ARM devices in general) would not suffer from Denormal's disease like Intel processors do. But guess what: Pi's float coprocessor is IEEE 754 compliant and does all denormals by default (can check with attached denorm-test.pd). Bummer! As if one would use an ARM device to calculate the size of a Majorana particle, rather than doing simple dsp. Do we really need to enable PD-BIGORSMALL() checks for this poor little processor? There seems to be something called 'RunFast mode' for Pi's float processor vfpv2, but I see no way how to enable this via gcc. Option -ffast-math is allowed but doesn't do the trick. Can't find an option to set vfpv2 specifically, in gcc docs. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi does denormals
Hans, the info about NEON is relevant for armv7 (Beagleboard, Cubieboard, PengPod...). But Raspberry Pi doesn't have NEON. Float processing is done on coprocessor vfpv2. As far as I can see, vfpv2 hardly has any SIMD instructions (except for moving data between ARM and vfp). It is said to process a maximum of 8 single precision floats in parallel, but Raspberry Pi doesn't show a sign that it profits from data alignment, at least not when code is compiled with gcc. Katja On Sun, Jan 20, 2013 at 5:12 PM, Hans-Christoph Steiner h...@at.or.at wrote: I think this is what you want, from 'man gcc'. Its interesting to note that the NEON mode, which provides SIMD, also does not do denormals: -mfpu=name -mfpe=number -mfp=number This specifies what floating point hardware (or hardware emulation) is available on the target. Permissible names are: fpa, fpe2, fpe3, maverick, vfp, vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16 and neon-vfpv4. -mfp and -mfpe are synonyms for -mfpu=fpenumber, for compatibility with older versions of GCC. If -msoft-float is specified this specifies the format of floating point values. If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=neon), note that floating-point operations will not be used by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision. .hc On 01/20/2013 06:54 AM, katja wrote: I was assuming, or maybe just hoping? that Raspberry Pi (and ARM devices in general) would not suffer from Denormal's disease like Intel processors do. But guess what: Pi's float coprocessor is IEEE 754 compliant and does all denormals by default (can check with attached denorm-test.pd). Bummer! As if one would use an ARM device to calculate the size of a Majorana particle, rather than doing simple dsp. Do we really need to enable PD-BIGORSMALL() checks for this poor little processor? There seems to be something called 'RunFast mode' for Pi's float processor vfpv2, but I see no way how to enable this via gcc. Option -ffast-math is allowed but doesn't do the trick. Can't find an option to set vfpv2 specifically, in gcc docs. Katja ___ 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] how to iterate over left and right channel separately in one Pd class?
Still struggling with the stereo layout. I stated earlier that this worked well (for an in place routine): memcpy(outR, inR, vectorsize * sizeof(t_float)); inR = outR; The output sounded all right. But upon closer inspection, it turned out that all the stereo sound came from the right input and the left input did nothing. It seems that the two signal buffers A and B for a two-in two-out object are assigned like so: inL: buffer A inR: buffer B outL: buffer B outR: buffer A So it's safe to process inL as a block but write it to outR, and process inR while writing to outL. Then the output blocks are ok, but they come from the wrong outlets. I swap these within the object. It is less operations than copying left and right inputs to outputs, but still a waste. Katja On Sun, Jan 13, 2013 at 3:49 AM, Hans-Christoph Steiner h...@at.or.at wrote: Yeah, that makes sense. With all the auto-vectorization and SIMD support is recent versions of gcc, it seems a better approach is to tailor the C code to work well with SIMD-aware compilers. .hc On 01/12/2013 04:45 PM, katja wrote: It's interesting, but rather compiler-and-processor-specific. Such code is maintanance-intensive. At the moment, ARM processors are screaming loudest for optimization. Best thing for a community project is probably plain C code which reckons with parallel processing, because that won't go away for the next few decades. Functions like copy_perform8(), times_perform8() etc. can profit from SIMD instructions without a need for compiler intrinsics and asm code. Well-structured data storage and access can make a 50 % or more performance gain, in my experience. Another important thing: avoid float precision conversions. Throughout Pd there are many untyped float defines and literal constants which default to double, and I have introduced more when making libs double-ready. Not good. I'll come back to this in another thread. Katja On Sat, Jan 12, 2013 at 8:14 PM, Hans-Christoph Steiner h...@at.or.at wrote: If you are interested, there is still the hand-coded SIMD stuff from pd-devel: https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-devel/v0-39 .hc On 01/12/2013 09:34 AM, katja wrote: Function copy_perform8() is also eligible for SIMD processing. I used memcpy() because it is straightforward to use, while Pd's functions pointed to the wrong locations for this case. On the reverb's total load there is no significant performance difference. Katja On Sat, Jan 12, 2013 at 1:00 AM, Hans-Christoph Steiner h...@at.or.at wrote: I recently learned that libc's memcpy actually uses things like SSE2 or SSSE2 so it can be quite fast on CPUs from the past 10 years, especially of the last 5 years. It would be worth profiling to see if that's noticeable. .hc On 01/11/2013 05:12 PM, katja wrote: Ok so I did the ugly thing with the right channel input and output pointers: memcpy(outR, inR, vectorsize * sizeof(t_float)); inR = outR; Works like a charm, thanks again. Katja On Fri, Jan 11, 2013 at 10:05 PM, Miller Puckette m...@ucsd.edu wrote: copy_perform assumes the data is 4-byte aligned so might save a test or two compared to memcopy() - but I really don't know. I never benchmarked the two against each other :) M On Fri, Jan 11, 2013 at 09:36:41PM +0100, katja wrote: Hi Miller, Thanks for the solution. The routines are in place so copying the right channel input to output should do it. Is there any reason to prefer copy_perform() over memcpy()? I'm trying to make the most efficient reverb for RPi Co. Katja On Fri, Jan 11, 2013 at 7:57 PM, Miller Puckette m...@ucsd.edu wrote: Hi Katja - There's one example of this in sigfft_dspx() - a complex FFT that 'natively' works on 2 signals in-place but has to deal with various cases in which buffers get re-used. It's ugly but the basic idea is first to get the inputs copied to the outputs (unless they're already there in the correct order in which case nothing needs to be done) and then run the in-place algorithm. If the algo only works out-of-place (i.e. you need 4 distinct buffers, 2 in and 2 out) the only way out is (at least conditionally) allocate temporary copies of the inputs before writing to any outputs. I may be able to add an optional way tilde objects can request that output buffers be distinct from input ones sometime in the future - but this is a couple of steps away for me right now :) M On Fri, Jan 11, 2013 at 03:32:09PM +0100, katja wrote: Hello, I'm working on a Pd class with stereo channels (reverb), and the routine happens to be most efficient when iterating over the samples per channel, instead of left and right together in the perform loop. However, when doing two while loops in one object, one for left and one for right, the right channel samples get overwritten because of sample-wise in-place computation. Is this an inescapable truth? I
Re: [PD] how to iterate over left and right channel separately in one Pd class?
Function copy_perform8() is also eligible for SIMD processing. I used memcpy() because it is straightforward to use, while Pd's functions pointed to the wrong locations for this case. On the reverb's total load there is no significant performance difference. Katja On Sat, Jan 12, 2013 at 1:00 AM, Hans-Christoph Steiner h...@at.or.at wrote: I recently learned that libc's memcpy actually uses things like SSE2 or SSSE2 so it can be quite fast on CPUs from the past 10 years, especially of the last 5 years. It would be worth profiling to see if that's noticeable. .hc On 01/11/2013 05:12 PM, katja wrote: Ok so I did the ugly thing with the right channel input and output pointers: memcpy(outR, inR, vectorsize * sizeof(t_float)); inR = outR; Works like a charm, thanks again. Katja On Fri, Jan 11, 2013 at 10:05 PM, Miller Puckette m...@ucsd.edu wrote: copy_perform assumes the data is 4-byte aligned so might save a test or two compared to memcopy() - but I really don't know. I never benchmarked the two against each other :) M On Fri, Jan 11, 2013 at 09:36:41PM +0100, katja wrote: Hi Miller, Thanks for the solution. The routines are in place so copying the right channel input to output should do it. Is there any reason to prefer copy_perform() over memcpy()? I'm trying to make the most efficient reverb for RPi Co. Katja On Fri, Jan 11, 2013 at 7:57 PM, Miller Puckette m...@ucsd.edu wrote: Hi Katja - There's one example of this in sigfft_dspx() - a complex FFT that 'natively' works on 2 signals in-place but has to deal with various cases in which buffers get re-used. It's ugly but the basic idea is first to get the inputs copied to the outputs (unless they're already there in the correct order in which case nothing needs to be done) and then run the in-place algorithm. If the algo only works out-of-place (i.e. you need 4 distinct buffers, 2 in and 2 out) the only way out is (at least conditionally) allocate temporary copies of the inputs before writing to any outputs. I may be able to add an optional way tilde objects can request that output buffers be distinct from input ones sometime in the future - but this is a couple of steps away for me right now :) M On Fri, Jan 11, 2013 at 03:32:09PM +0100, katja wrote: Hello, I'm working on a Pd class with stereo channels (reverb), and the routine happens to be most efficient when iterating over the samples per channel, instead of left and right together in the perform loop. However, when doing two while loops in one object, one for left and one for right, the right channel samples get overwritten because of sample-wise in-place computation. Is this an inescapable truth? I mean, I could write a left channel class and a right channel class (actually did that to verify that it works), but it's inconvenient to use. What could be an efficient way to get them in one object? Thanks, Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to iterate over left and right channel separately in one Pd class?
It's interesting, but rather compiler-and-processor-specific. Such code is maintanance-intensive. At the moment, ARM processors are screaming loudest for optimization. Best thing for a community project is probably plain C code which reckons with parallel processing, because that won't go away for the next few decades. Functions like copy_perform8(), times_perform8() etc. can profit from SIMD instructions without a need for compiler intrinsics and asm code. Well-structured data storage and access can make a 50 % or more performance gain, in my experience. Another important thing: avoid float precision conversions. Throughout Pd there are many untyped float defines and literal constants which default to double, and I have introduced more when making libs double-ready. Not good. I'll come back to this in another thread. Katja On Sat, Jan 12, 2013 at 8:14 PM, Hans-Christoph Steiner h...@at.or.at wrote: If you are interested, there is still the hand-coded SIMD stuff from pd-devel: https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-devel/v0-39 .hc On 01/12/2013 09:34 AM, katja wrote: Function copy_perform8() is also eligible for SIMD processing. I used memcpy() because it is straightforward to use, while Pd's functions pointed to the wrong locations for this case. On the reverb's total load there is no significant performance difference. Katja On Sat, Jan 12, 2013 at 1:00 AM, Hans-Christoph Steiner h...@at.or.at wrote: I recently learned that libc's memcpy actually uses things like SSE2 or SSSE2 so it can be quite fast on CPUs from the past 10 years, especially of the last 5 years. It would be worth profiling to see if that's noticeable. .hc On 01/11/2013 05:12 PM, katja wrote: Ok so I did the ugly thing with the right channel input and output pointers: memcpy(outR, inR, vectorsize * sizeof(t_float)); inR = outR; Works like a charm, thanks again. Katja On Fri, Jan 11, 2013 at 10:05 PM, Miller Puckette m...@ucsd.edu wrote: copy_perform assumes the data is 4-byte aligned so might save a test or two compared to memcopy() - but I really don't know. I never benchmarked the two against each other :) M On Fri, Jan 11, 2013 at 09:36:41PM +0100, katja wrote: Hi Miller, Thanks for the solution. The routines are in place so copying the right channel input to output should do it. Is there any reason to prefer copy_perform() over memcpy()? I'm trying to make the most efficient reverb for RPi Co. Katja On Fri, Jan 11, 2013 at 7:57 PM, Miller Puckette m...@ucsd.edu wrote: Hi Katja - There's one example of this in sigfft_dspx() - a complex FFT that 'natively' works on 2 signals in-place but has to deal with various cases in which buffers get re-used. It's ugly but the basic idea is first to get the inputs copied to the outputs (unless they're already there in the correct order in which case nothing needs to be done) and then run the in-place algorithm. If the algo only works out-of-place (i.e. you need 4 distinct buffers, 2 in and 2 out) the only way out is (at least conditionally) allocate temporary copies of the inputs before writing to any outputs. I may be able to add an optional way tilde objects can request that output buffers be distinct from input ones sometime in the future - but this is a couple of steps away for me right now :) M On Fri, Jan 11, 2013 at 03:32:09PM +0100, katja wrote: Hello, I'm working on a Pd class with stereo channels (reverb), and the routine happens to be most efficient when iterating over the samples per channel, instead of left and right together in the perform loop. However, when doing two while loops in one object, one for left and one for right, the right channel samples get overwritten because of sample-wise in-place computation. Is this an inescapable truth? I mean, I could write a left channel class and a right channel class (actually did that to verify that it works), but it's inconvenient to use. What could be an efficient way to get them in one object? Thanks, Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] how to iterate over left and right channel separately in one Pd class?
Hello, I'm working on a Pd class with stereo channels (reverb), and the routine happens to be most efficient when iterating over the samples per channel, instead of left and right together in the perform loop. However, when doing two while loops in one object, one for left and one for right, the right channel samples get overwritten because of sample-wise in-place computation. Is this an inescapable truth? I mean, I could write a left channel class and a right channel class (actually did that to verify that it works), but it's inconvenient to use. What could be an efficient way to get them in one object? Thanks, Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to iterate over left and right channel separately in one Pd class?
Hi Miller, Thanks for the solution. The routines are in place so copying the right channel input to output should do it. Is there any reason to prefer copy_perform() over memcpy()? I'm trying to make the most efficient reverb for RPi Co. Katja On Fri, Jan 11, 2013 at 7:57 PM, Miller Puckette m...@ucsd.edu wrote: Hi Katja - There's one example of this in sigfft_dspx() - a complex FFT that 'natively' works on 2 signals in-place but has to deal with various cases in which buffers get re-used. It's ugly but the basic idea is first to get the inputs copied to the outputs (unless they're already there in the correct order in which case nothing needs to be done) and then run the in-place algorithm. If the algo only works out-of-place (i.e. you need 4 distinct buffers, 2 in and 2 out) the only way out is (at least conditionally) allocate temporary copies of the inputs before writing to any outputs. I may be able to add an optional way tilde objects can request that output buffers be distinct from input ones sometime in the future - but this is a couple of steps away for me right now :) M On Fri, Jan 11, 2013 at 03:32:09PM +0100, katja wrote: Hello, I'm working on a Pd class with stereo channels (reverb), and the routine happens to be most efficient when iterating over the samples per channel, instead of left and right together in the perform loop. However, when doing two while loops in one object, one for left and one for right, the right channel samples get overwritten because of sample-wise in-place computation. Is this an inescapable truth? I mean, I could write a left channel class and a right channel class (actually did that to verify that it works), but it's inconvenient to use. What could be an efficient way to get them in one object? Thanks, Katja ___ 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] how to iterate over left and right channel separately in one Pd class?
Ok so I did the ugly thing with the right channel input and output pointers: memcpy(outR, inR, vectorsize * sizeof(t_float)); inR = outR; Works like a charm, thanks again. Katja On Fri, Jan 11, 2013 at 10:05 PM, Miller Puckette m...@ucsd.edu wrote: copy_perform assumes the data is 4-byte aligned so might save a test or two compared to memcopy() - but I really don't know. I never benchmarked the two against each other :) M On Fri, Jan 11, 2013 at 09:36:41PM +0100, katja wrote: Hi Miller, Thanks for the solution. The routines are in place so copying the right channel input to output should do it. Is there any reason to prefer copy_perform() over memcpy()? I'm trying to make the most efficient reverb for RPi Co. Katja On Fri, Jan 11, 2013 at 7:57 PM, Miller Puckette m...@ucsd.edu wrote: Hi Katja - There's one example of this in sigfft_dspx() - a complex FFT that 'natively' works on 2 signals in-place but has to deal with various cases in which buffers get re-used. It's ugly but the basic idea is first to get the inputs copied to the outputs (unless they're already there in the correct order in which case nothing needs to be done) and then run the in-place algorithm. If the algo only works out-of-place (i.e. you need 4 distinct buffers, 2 in and 2 out) the only way out is (at least conditionally) allocate temporary copies of the inputs before writing to any outputs. I may be able to add an optional way tilde objects can request that output buffers be distinct from input ones sometime in the future - but this is a couple of steps away for me right now :) M On Fri, Jan 11, 2013 at 03:32:09PM +0100, katja wrote: Hello, I'm working on a Pd class with stereo channels (reverb), and the routine happens to be most efficient when iterating over the samples per channel, instead of left and right together in the perform loop. However, when doing two while loops in one object, one for left and one for right, the right channel samples get overwritten because of sample-wise in-place computation. Is this an inescapable truth? I mean, I could write a left channel class and a right channel class (actually did that to verify that it works), but it's inconvenient to use. What could be an efficient way to get them in one object? Thanks, Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] vbap 1.0.3.2 fails when sent longer define_loudspeakers messages
Hello,
This issue seems somehow related to changing 'float' into Pd's type
't_float' about a year ago. I checked a few builds to find out where
the issue started. Most changes were made 2011-11-16 (by me). The
2011-11-25 build does not show the issue yet.
Apparently I had overlooked a few instances of 'float', and Hans did
more changes on 2012-01-12. Most of these are in lines which are
commented out anyway, there is only one change that has effect, and it
is in line 230 of define_loudspeakers.c. Leaving commented-out lines
away, it reads:
t_float azi = 0;
if(av[pointer].a_type == A_FLOAT) azi = av[pointer].a_w.w_float;
else { error(define-loudspeakers: direction angle #%d NaN,i+1);
x-x_ls_read = 0; return; }
In the 20120216 build, the message 'param is not a float' pops
up. However, Pd does not crash (also not when closing the patch). So,
there may be an extra issue, introduced later. I can't imagine how
't_float' could be a problem here, as it is perfectly equivalent to
'float', if m_pd.h is included. Without m_pd.h it should not compile,
but m_pd.h is included via other headers.
Also on 2012-01-12, a variable 'epsilon' of type t_float was
introduced in the same file, but this seems less related to the issue.
Katja
On Wed, Jan 9, 2013 at 1:02 AM, Hans-Christoph Steiner h...@at.or.at wrote:
Ah, that's an important tidbit of info! If that's not in the bug report,
please include which version is working.
.hc
On 01/08/2013 06:53 PM, Zack Settel wrote:
Hi HC- Yeah, I kind of gave up at a certain point, figuring that I was
poorly equipped to get to the bottom of that one quickly. I posted a ticket.
For now, I suppose I'll grab an earlier version that seems to work, and
switch back, once the bug gets sorted out.
cheers,
Zack
On 2013-01-07, at 12:28 PM, Hans-Christoph Steiner wrote:
Hey Zach,
Looks like you've gone deep into it :) Sounds like those MAX macros are set
because the code can't currently handle longer lists. I won't have time to
look at this for a while. Could you post a bug report to the bug tracker
(Help menu -- report bug) with the info in this email? Also it might be
worth your while to see if anyone has tried this when using this object in
Max/MSP. Its the same code.
.hc
On 01/07/2013 09:45 AM, Zack Settel wrote:
Hi Hans-Christoph,
Thanks for your previous reply before the holidays.
Just to refresh the subject:
using Pd-0.42.5-extended.app, Pd-0.43-3.app, and
Pd-0.43.4-extended-20121101
on OSX 10.6x and 10.7x,
vbap 1.0.3.2 crashes when sent longer define_loudspeakers messages
the PD console displays: vbap: Loudspeaker setup configured! pd:
getbytes() failed -- out of memory vbap: Configure loudspeakers first!
and the program crashes.
(It appears to be failing in the vbap_matrix method. But, perhaps, the
data sent to that message is already bad).
Following your suggestion,
I tried doubling both MAX_LS_AMOUNT as well as MAX_LS_SETS. Now the
program does not crash, vbap fails each time: when sent the
define_loudspeakers, the PD console displays:
vbap loudspeaker-matrices: param 475 is not a float. (from vbap_matrix
method)
Things I have noticed:
--The above param number in the error message will be different each time
pd is relaunched and a new attempt is made.
--increasing MAX_LS_AMOUNT and MAX_LS_SETS 10 times introduces
intermittency:Some times the same error message above will be
displayed, sometimes it the define_loudspeakers message will succeed, and
VBAP will function correctly.
-- occasionally, a different error message in the pd console will result:
Dimension can be only 2 or 3 (from vbap_matrix method)
--And of course, the problem does not manifest when smaller configurations
are used (i.e. shorter define_loudspeakers messages).
I wrestled with the problem for a long time without getting any further.
Maybe you, or someone out there, will have some greater insight into this
problem. Any assistance or additional suggestions would be greatly
appreciated, since the problem above comes with the latest pd-extended.
Below is the the vbap message that provokes the problem:
define_loudspeakers 3 0 90 -7.5 55 52.5 55 112.5 55 172.5
55 -127.5 55 -67.5 55 7.5 20 37.5 20 67.5 20 97.5 20 127.5 20 157.5
20 -172.5 20 -142.5 20 -112.5 20 -82.5 20 -52.5 20 -22.5 20 7.5 -15
37.5 -15 67.5 -15 97.5 -15 127.5 -15 157.5 -15 -172.5 -15 -142.5 -15
-112.5 -15 -82.5 -15 -52.5 -15 -22.5 -15
thanks
Zack
On Dec 22, 2012, at 0:55, Hans-Christoph Steiner wrote:
Sounds like you are the first to try it with that many speakers! My
guess is that something that allocates memory is hard-coded to a pretty
short number. I've used it a lot for 6 speakers and had no crashes.
Try changing this in vbap.h:
#define MAX_LS_AMOUNT 55
.hc
On Dec 21, 2012, at 6:41 PM, Zack Settel wrote:
Hi List,
It seems that VBAP v 1.0.3.2 (downloaded
Re: [PD] PengPod Linux tablet, hopefully coming soon
On Tue, Dec 25, 2012 at 1:16 AM, Hans-Christoph Steiner h...@at.or.at wrote: Hopefuilly some of these open hardware projects will spend the effort to get the audio drivers right, so that there isn't the massive latency like with Android. Reportedly, Android's latency issues where for a large part due to the audio mixer, which has been improved recently: http://createdigitalmusic.com/2012/07/android-high-performance-audio-in-4-1-and-what-it-means-plus-libpd-goodness-today/ Pd under Linux has the advantage of talking straight to ALSA. But even when absolute latency time would be reasonably low, the instantaneous load of a program respective to CPU/system speed may still justify longer buffers. For example: Pd's testtone can do with 10 ms latency on my no so new Linux laptop, but when running a moderately complex patch it must be 20 ms, and when I measure real throughput latency that's already 30 ms. And that laptop cannot do without realtime kernel when audio goes via USB. Therefore I guess a realtime kernel could also make a difference when running Pd on an ARM device. Maybe Bastiaan can check throughput latency with Pd on the Cubieboard? I've attached a (vanilla) patch for sample-precise throughput latency measurement. Katja There is now a Debian source package as part of the nightly builds, so it should be much easier to build Pd-extended on Debian these days. After downloading the two tarballs: http://autobuild.puredata.info/auto-build/latest/Pd-extended_0.43.4~20121224-source.tar.bz2 http://autobuild.puredata.info/auto-build/latest/Pd-extended_0.43.4~20121224-source.debian.tar.bz2 You basically just need to do this: tar xjf Pd-extended_0.43.4~20121224-source.tar.bz2 cd pd-extended tar xjf ../Pd-extended_0.43.4~20121224-source.debian.tar.bz2 debuild -uc -us --lintian .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list latency-tester.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] small slice jockey bug report
Hans, thanks for pointing to possible solutions for this bug. I'm still working on a 0.42 / 0.43 compatible SliceJockey. A first test version should be ready very soon. Katja On Thu, Dec 20, 2012 at 3:30 AM, Hans-Christoph Steiner h...@at.or.at wrote: I'm using SliceJockey as a test patch for the 0.43.4 release (its really a great patch, I have to say again). There are still some issues with GUI redrawing freeing that SliceJockey illustrates well, I think I might have found the cause, so hopefully a fix is near. In the process I noticed a small bug. In [pd top] you're getting [window_name 1] to send the -topmost message to it. [window_name 1] refers to the window of the patch one level above, which is actually the [pd parameter-settings] subpatch. 0.43 now prints a big loud error about it. So you can either fix it in a 0.42 compatible way by using [window_name 2], or at least I think its 2, I'm not sure where that subpatch is. Or you can use the new handy [window_name] symbol arg: [window_name pd-SliceJockey.pd] .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PengPod Linux tablet, hopefully coming soon
On Mon, Dec 24, 2012 at 12:45 AM, Bastiaan van den Berg b...@spacedout.nl wrote: Is it me or does this email read like you have some financial interest in selling this pad? Yeah it sounds like spam. Let me add a bit more. spam What I like about this crowdfunded project is the intention to develop open source drivers and deliver a fully functional Linux tablet. The hardware designers and manufacturers didn't give a shit about that. Android happens to be most convenient for them so that is what we get. Open source drivers, why? A previous Linux tablet effort was apparently stalled, read this: http://lwn.net/Articles/504865/ This could still happen to the PengPod as well. If a Linux-oriented hardware project succeeds, it makes me happy. /spam Anyway, just to let you know, _all_ allwinner A10 tablets/tvsticks/settopboxes can run linux without much effort at all. Not really any point in a 'boxed linux' version of it.. Sounds like you're experienced with these. I'm curious, did you manage to compile and install Pd or Pd-extended on them? Is it possible to get duplex audio I/O with Pd? (still a problem with the Pi). Do you need to use a real time kernel to get decent sound from Pd? Is a real time kernel for ARMv7 available at all? Thanks, Katja 7 tablets with allwinner a10 cost about 70 usd on ebay. I have been playing with a cubieboard a lot this last week ( http://cubieboard.org/ ) and although its not a holy grail, its a really nice toy. -- buZz ___ 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] [nbuntil]: an non-blocking [until] replacement
Cool, with [nbuntil] the workload is even spread over the cores! So now you can do calculations on long arrays without fear of CPU spikes. And in turn, audio latency may be set to lower level. Great solution Roman, thanks for sharing. Katja On Sun, Dec 16, 2012 at 10:51 PM, Roman Haefeli reduz...@gmail.com wrote: Hi all Audio drop-outs happen, when Pd needs more time to do something than is available (i.e. the configured audio buffer size). The underlying reasons are manifold, often it is because something requiring lots of CPU power is processed in zero logical time. For such of those problems, that can be divided into smaller tasks or those that already are of an iterative nature, [nbuntil] may provide a solution to avoid audio drop-outs. [nbuntil] works similar to the regular [until], but unlike the original, it breaks Pd's principle of depth first. It measures how much time each iteration requires and delays the next iteration by this time. By employing [nbuntil], many kinds of tasks can be performed without causing drop-outs, that would otherwise block Pd for a certain amount of time. Example applications include loading presets or dynamic creation of parts in the background. Yet, I use it to pre-calculate a set of tables while audio is running. I could imagine using it to create an emulation of a threaded [soundfiler], though a proof of concept is yet lacking and needs to be created. Contrary to Miller's suggestion of using a [readsf~] in an upsampled subpatch, [nbuntil]'s adaptive approach uses the maximum available CPU power. I'm curios to see whether other people find it useful and even find use cases I haven't thought of yet. Despite its rather simple design, I can't remember having seen this approach discussed here on the list. I'd also be interested if similar or different approaches have been used, but not yet discussed here. I'm currently not in the urgent need of a vanilla pseudo-threaded [soundfiler], but if there is enough interest, I'd be happy to dedicate some time to it (not totally sure, that it would work, though). 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] [nbuntil]: an non-blocking [until] replacement
On Mon, Dec 17, 2012 at 1:21 PM, Roman Haefeli reduz...@gmail.com wrote: ... On Mon, 2012-12-17 at 11:56 +0100, katja wrote: Cool, with [nbuntil] the workload is even spread over the cores! I don't think that [nbuntil] will help in making Pd use more than one core. Since [nbuntil] is just an abstraction, everything run below it is still part of the pd process/thread. For fully exploiting many cores, real threading is needed, I suppose. You're right, your abstraction exploits threading which is already done. When running [nbuntil-help] on OSX, I notice CPU increase for both cores in Activity Monitor. But it is also the case with regular [until] in the patch. Following the principle in [nbuntil], it would be possible to make a general abstraction for deferring subsequent tasks with low priority, no? Let's say [defer], a variation on [pipe], but where delay is proportional to CPU load. This could then be used in any straight sequence of subpatches which do a substantial amount of operations each. Katja Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [nbuntil]: an non-blocking [until] replacement
On Mon, Dec 17, 2012 at 4:18 PM, katja katjavet...@gmail.com wrote: On Mon, Dec 17, 2012 at 1:21 PM, Roman Haefeli reduz...@gmail.com wrote: ... On Mon, 2012-12-17 at 11:56 +0100, katja wrote: Cool, with [nbuntil] the workload is even spread over the cores! I don't think that [nbuntil] will help in making Pd use more than one core. Since [nbuntil] is just an abstraction, everything run below it is still part of the pd process/thread. For fully exploiting many cores, real threading is needed, I suppose. You're right, your abstraction exploits threading which is already done. When running [nbuntil-help] on OSX, I notice CPU increase for both cores in Activity Monitor. But it is also the case with regular [until] in the patch. Wait this is not a matter of threading of course, the process is just switching between cores. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] is there a kalman filter for pd? (if not I could probably provide one, if I make it :) )
Thanks for the suggestion, Cyrille. I've been playing around with median filters in a different context (spectral processing), but completely forgot about them. With the variometer, the problem is to isolate very low frequencies (the pressure gradient you want to detect) from DC (constant atmospheric pressure at certain height) and sensor noise frequencies. And you want to see results with accuracy and little delay. In fact it needs a very sharp minimum-phase filter. Maybe a median filter can 'preprocess' the signal in some way. Anyway it gives a new perspective. Katja On Fri, Dec 14, 2012 at 1:27 PM, Cyrille Henry c...@chnry.net wrote: for sensors data, depending of the noise, it can be useful to begin with a median filter. a median on the 7 last sample add 3 sample delay, but often remove lot's of noise. you can find them in mapping or puremapping libs. cheers cyrille Le 14/12/2012 11:38, katja a écrit : Patrick, the barometer sensor samplerate is ~50 Hz and I did the butterworth filter with regular Pd objects, not as external (see attached). In the Pd patch I modeled sensor noise (resolution 3 Pascal according to datasheet) and pressure gradient, simulating vertical speed through the air. The aim is to get 0.1 m/s accuracy in vertical speed reading. Theoretically, this would be almost possible with the butterworth. But our real sensor has much more noise than 3 Pascal resolution. Therefore I'm still interested in better filters. Katja On Wed, Dec 12, 2012 at 6:29 PM, patrick pured...@11h11.com wrote: hi Katja, did you ported this filter: https://github.com/lebipbip/le-BipBip/blob/master/filter.c to an pd external? if yes could you share it? not sure if it would help my situation (noisy accelerometer 1 axis), but i would like to give it a shot. thx ___ 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] is there a kalman filter for pd? (if not I could probably provide one, if I make it :) )
Pedro, if you make the Kalman filter for Pd, I will try it for filtering barometer sensor data. I already tried an alpha-beta filter, but it produced overshoot and ring. A butterworth filter with coefficients taken from an open source variometer project performed better (but still not good enough): https://github.com/lebipbip/le-BipBip Katja On Wed, Dec 12, 2012 at 4:37 AM, patrick pured...@11h11.com wrote: hi, i was trying to implement this filter in an avr, but i guess it would be even better in pd. i just need to clean a noisy accelerometer (only 1 axis), but then i read that for 1 input you can use a low pass (in comments): http://interactive-matter.eu/blog/2009/12/18/filtering-sensor-data-with-a-kalman-filter/ as for now, i am using an iir filter in pd (from mapping). works great, but would like to benchmark the kalman implementation compared to low pass, iir. anyone have a gem patch to plot mutiple inputs? à+ ___ 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] what makes Pd-extended 0.43 so CPU-hungry?
On Tue, Dec 11, 2012 at 8:58 PM, Hans-Christoph Steiner h...@at.or.at wrote: I added optimization flags to the GNU/Linux and Windows builds: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16655 http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16656 http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16657 Installed the latest build for Debian Squeeze today. Very happy to see that optimization is working again for all libs. CPU loads are back to normal. Probably freeverb~ was the main victim of non-optimization, with a couple hundred function calls in the perform loop, functions which are supposed to be inlined. The object was almost ten times more expensive with all those function calls. And it was just coincidence that my live setups have four instances of freeverb~ each. Otherwise I might not have noticed the issue at all. I just remembered one issue: one thing that makes it tricky to set optimization flags for all of Pd-extended is the last few remaining type punning issues: http://autobuild.puredata.info/auto-build/2012-12-11/logs/type-punning-2012-12-11.txt I fixed a few recently. Want to try fixing bsaylor/svf~ or oscx? As for 'extra', I think I'll include your pd-double fixes in the pd-extended 0.43 branch. Yeah it's better to get rid of all the overt type punning so the -fno-strict-aliasing need not be set. In bsaylor/svf~ is a type punning method to avoid denormals, this could probably be replaced by the PD_BIGORSMALL(). I'll check that. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] what makes Pd-extended 0.43 so CPU-hungry?
On Fri, Dec 7, 2012 at 11:46 PM, Hans-Christoph Steiner h...@at.or.at wrote: Thanks for this write-up and all that testing, its definitely very helpful. So in the end, you're talking about Pd-extended on debian only? It sounds like your tests show that 0.43 was not slower on Mac OS X. It does look like the Debian-i386 builds don't have optimization turned on, you can look at the build log to see exactly how it was built Hans I checked build logs for various Linux builds and for OSX. As it turns out, Pd core is optimized as well as some external libs (ie GEM), but other externals (like freeverb~) are optimized for OSX and not for Debian. I suspect the problem is in Makefiles according to the template. They have lines like OPT_FLAGS = -O6 -funroll-loops -fomit-frame-pointer. But Makefiles for packages have OPT_FLAGS as well, therefore in the library template it should be OPT_FLAGS +=, no? The darwin_app package makefile defines a lot of OPT_FLAGS, including -fast. The linux package makefile defines several OPT_FLAGS according to target platform, but no optimization level. Apparently, OPT_FLAGS in the package Makefile are implemented, and not the ones in the template. I don't have a Pd autobuild or SVN setup on my Linux box now, can't test a modification rightaway. Anyhow, I guess the problem is now identified. I am sorry about my blunt subject title 'what makes Pd 0.43 so CPU hungry?'. It wasn't even about Pd, but Pd-extended. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to use extensions .l_i386 and .l_ia64 for Linux externals
OK if these extensions are introduced in Pd 0.42 or earlier, it is safe to use them now. And I definitely will. Hans, I can see why libraries in Pd-extended must not go this way. But for projects which are not (yet) in Pd-E, the 'bitwise' extension is a great solution, as you can simply distribute one package with no complicated instructions for the user of what to get and what to put where. It also simplifies building such projects. Very useful in projects which are too individual or experimental to get into Pd-E, or libs which are in testing phase, like when porting a lib to Pd. I also like the 'apt-get-for-Pd-' idea, where external libs could live decentralized in various repos. This would give developers more autonomy and a clearer responsability over their libs. Katja On Sat, Dec 8, 2012 at 2:09 AM, Hans-Christoph Steiner h...@at.or.atwrote: Miller introduced those extensions in 0.42 or earlier, I forget when. I made the filterview package by manually renaming the files. It would be nice to have this automatically handled in the template Makefile for sure. Having the extension as .pd_linux makes the packaging much easier because the packaging only has to handle one file extension, not all of them. I guess don't want to add this to the template library unless it really is the only way. Personally, I think we'd be better off if its easy to just build distribute a library for a given arch without having to include all of them in it. I've been thinking again about a sort of 'apt-get' or 'yum' for Pd. Now that we have a common library hammered out, it should be pretty straightforward to do. So instead of fretting over all the file extensions, we could instead just figure out how to make package repos that Pd can download from in an automated way. .hc On Dec 7, 2012, at 6:50 PM, katja wrote: Hello, I'd like to use extensions .l_i386 and .l_ia64 for Linux Pd externals, like it is in Hans Christoph Steiner's [filterview] project. But how does that work? In the makefile accompanying the filterview project, Linux executable extensions are conventional .pd_linux. I'm looking for ways to simplify build procedures and distribution of externals which are not in Pd-extended. At the moment, I let my makefiles find the bitness of a Linux system and automatically copy the executable to a directory bin/ or bin64/ according to bitness. But the problem is, a Linux user has to remove the file of wrong bitness so Pd can not try to load it. An executable (automatically) named with an extension according to bitness is a great idea. But do these extensions also work for Pd-E versions older than 0.43, and for vanilla Pd? Thanks, Katja ___ 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] how to use extensions .l_i386 and .l_ia64 for Linux externals
On 12/8/12, Hans-Christoph Steiner h...@at.or.at wrote: Pd-extended on Mac OS X will also build a double-clickable MyWorkOfGenius.app with all the libraries embedded inside. I haven't heard much feedback about it, so I wonder how its working for people. .hc I did use the 'make-an-app' option, it works great but it makes a large app file which is not easy to distribute from a homepage with 'fair use policy' and certainly not via a forum or mailing list. For that reason I prefer to package patches plus specific source files and binaries only. With the advantage that it works on 'all' platforms. And the disadvantage that I have to build on all platforms. This poses a natural limit on my ambitions to publish new projects. Maybe not so bad after all... Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] what makes Pd-extended 0.43 so CPU-hungry?
Finally I have some clue what's wrong with Pd-E 0.43 for GNU/Linux, or for Debian Squeeze at least. Sorry that it took me so long to sit down and sort it out. The problem is still there, with version 0.43.4: my live performance setups run with almost double CPU load, when compared to 0.42. Now I also tested with some comprehensive patches which are known to be pure vanilla, like Martin Brinkmann's 'chaosmonster'. Remarkably, these patches do not show an increased CPU load. Therefore I guessed that it must be in external classes. I tried using callgrind and kcachegrind (thanks for the hint Jamie). Though callgrind makes Pd choke completely (while recording the complete call history of a process instead of taking samples), the output gave a clue. Freeverb~ was shown to make a couple hundred function calls within the perform loop. Functions which are written as 'inline' in the C file. An isolated freeverb~ instance turned out to do 10% CPU load. Admittedly, this computer (1.8 GHz core duo 2006) is not the latest. But freeverb~ normally does some 1% per instance. So, freeverb~ is the messenger; without it I might not have noticed any problem. But what is the message? Is Pd-E 0.43 compiled without optimization? I searched for more inline functions in external libs, and found one in bsaylor/svf~. In this case again, the executable implements it as a call. The core code however is almost certainly compiled with properly inlined functions. There's one frequently called inline function in the API (PD_BIGORSMALL, which used to be a macro in the past). If this would be compiled as a call, a patch like 'chaosmonster' would definitely show performance loss. Note that I'm talking about debian binaries so far, more precisely Pd-E 0.43.4 for debian squeeze, as downloaded from puredata.info downloads page. In contrast, I checked freeverb~ in the distribution for OSX i386, and here the inlining was done properly. Another difference between those distributions: SSE instructions are used for OSX, not for debian. Simple operations like addition and multiplication of floats are done on the FPU in debian, while xmm registers are used with OSX. This also means that things like abs() and ifnan() are function calls for debian, while they could be simple instructions on the xmm registers. (Instructions can be viewed by dissassembling executables with command objdump -d file.) My conclusion from these observations: at least some Pd 0.43 externals for debian squeeze are compiled with -0O for some reason (don't know about other Linuxes). How come? The template makefile (also used for freeverb~) has optimization -O6. The root makefile for the packages have certain optimization flags as well. Are they somehow conflicting, producing an undefined result? Not for OSX, apparently. But for debian something goes wrong. The build system stuff is really over my head, hopefully someone else has better overview to find the exact cause. Katja On 5/6/12, Jamie Bullock jamie.b.bull...@gmail.com wrote: Hi Katja, On 5 May 2012, at 20:43, katja katjavet...@gmail.com wrote: I've tried to use Oprofile on Debian, but this gives me a kernel failure soon as I start sampling. Does anyone know of a fine performance profiler for GNU/Linux? Katja You might want to try callgrind + kcachegrind... http://www.slac.stanford.edu/BFROOT/www/Computing/Optimization/genprof.html best, Jamie -- http://www.jamiebullock.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Stream phone call to pd?
Hello Sebastian, Couple of years ago I tried to use a bluetooth stereo device for wireless monitoring in Pd. Nice thing about OSX is you can create an 'Aggregated Device' in 'Audio MIDI Setup' to include the bluetooth stereo to the regular sound card and use the extra channels in Pd. However, I soon found that bluetooth stereo had over half a second latency, so it was not useful for my purpose of monitoring. Besides that, bluetooth audio pairing was really a pain in OSX (back then at least). Another thing, when connecting a phone as bluetooth device to MacBook, I see the following services: Dial-up Networking, Human interface device, OBEX File Transfer, OBEX Object Push. None of these makes the phone available as an extra audio interface. No way to capture it's audio in Pd, like it can be done with bluetooth headsets. With WIFI-enabled cell phones there may be better possibilities, using Skype or similar, and route audio to Pd with Jack or Soundflower. Katja On Mon, Oct 29, 2012 at 4:21 AM, Sebastian Valenzuela svalenzuelamu...@gmail.com wrote: Hey everyone, I know this is a longshot, and most likely not the best place to ask this sort of question, but maybe you can point me in the right direction. I'm working on an art installation which requires the interception of phone conversations to be sent to my macbook and manipulated in Pd. Willing participants would connect their phones (via bluetooth?) to my computer and all audio would be streamed to my laptop in real time and routed into Pd. I realize one could just connect their phones to their laptops via an 8th inch TRS cable and an audio interface... but the idea is to make this connection wirelessly. Any ideas? Anything would be helpful. Thank you for your time, Sebastian -- Sebastian Ignacio Valenzuela Rojas Composer - Performer svalenzuelamusic.wix.com/home youtube.com/svalenzuelamusic ___ 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] Stream phone call to pd?
Sorry Sebastian, you did not read correctly. I had a bluetooth headset included as a sound card in Aggregate Device, but not a phone. When I connect a phone via bluetooth it can be used for data transfer but not for audio. Like Simon suggested, you could try connect a bluetooth headset's output with cables to your computer sound card and have the user pair with that bluetooth headset. Not sure if the phone's wired headset would still function, it may be disabled when using bluetooth? Can't check at the moment. I had a very cheap but functional BCK-08 from dealextreme.com and a Jabra. Batteries of both are dead now after a few years. Katja On Mon, Oct 29, 2012 at 4:13 PM, Sebastian Valenzuela svalenzuelamu...@gmail.com wrote: Hi Katja, Thank you for your reply. I did find a way to SEND audio to my phone via a wifi connection. A mac application called Airfoil allowed me to connect to my android phone (using this app called AirBubble). What I need is to send either the conversation happening on the phone to my computer or at least send what the mic is picking up on the phone to the computer. I'm wondering if I read correctly - did you say you were able to do this by turning your phone into an aggregate device, but that it had crazy latency? For my purposes thats not as important really! Could you please tell me how you did that? Best, Sebastian On Mon, Oct 29, 2012 at 6:52 AM, katja katjavet...@gmail.com wrote: Hello Sebastian, Couple of years ago I tried to use a bluetooth stereo device for wireless monitoring in Pd. Nice thing about OSX is you can create an 'Aggregated Device' in 'Audio MIDI Setup' to include the bluetooth stereo to the regular sound card and use the extra channels in Pd. However, I soon found that bluetooth stereo had over half a second latency, so it was not useful for my purpose of monitoring. Besides that, bluetooth audio pairing was really a pain in OSX (back then at least). Another thing, when connecting a phone as bluetooth device to MacBook, I see the following services: Dial-up Networking, Human interface device, OBEX File Transfer, OBEX Object Push. None of these makes the phone available as an extra audio interface. No way to capture it's audio in Pd, like it can be done with bluetooth headsets. With WIFI-enabled cell phones there may be better possibilities, using Skype or similar, and route audio to Pd with Jack or Soundflower. Katja On Mon, Oct 29, 2012 at 4:21 AM, Sebastian Valenzuela svalenzuelamu...@gmail.com wrote: Hey everyone, I know this is a longshot, and most likely not the best place to ask this sort of question, but maybe you can point me in the right direction. I'm working on an art installation which requires the interception of phone conversations to be sent to my macbook and manipulated in Pd. Willing participants would connect their phones (via bluetooth?) to my computer and all audio would be streamed to my laptop in real time and routed into Pd. I realize one could just connect their phones to their laptops via an 8th inch TRS cable and an audio interface... but the idea is to make this connection wirelessly. Any ideas? Anything would be helpful. Thank you for your time, Sebastian -- Sebastian Ignacio Valenzuela Rojas Composer - Performer svalenzuelamusic.wix.com/home youtube.com/svalenzuelamusic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Sebastian Ignacio Valenzuela Rojas Composer - Performer svalenzuelamusic.wix.com/home youtube.com/svalenzuelamusic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fractional Delay in PD
On Tue, Oct 2, 2012 at 5:05 PM, Aaron Thompson aaron.thomp...@live.co.uk wrote: Hi Katja, Thanks for the reply. That seems to have fixed the problem, thanks! With regards to using the FIR as a fractional delay filter, i'm assuming the delta float (which feeds to the coefficient calculations) should be decimal values above a whole number delay? Ie, if the delay is calculated to be 5.35273 samples for example, then the delta float sent to the FIR, should be 0.35273, correct? In that case, should the value going to the delay be 5 instead of 5.35273, or is it purely the nature of the filter to remove the artifacts created from a non-integar delay? The FIR filter takes care of the time shift in between integer samples, the fractional part of delay indeed. Also, can I ask if you've had any experience with building loss filters, for example within a tubular waveguide the loss filter from viscothermal losses along the tube? I understand the nature is basically a low pass filter with a filter cutoff freq reducing the greater the distance, but interested as you knew about fractional delay, as to whether you've created something of this elk before. No, sorry I'm not so much into physical modeling. Finally, if you do come across that sinc kernal, that would be great! See attached patch phaseshifter.pd. It is only for visualization but you could use the sinc kernel calculator for fractional delay FIR, if you apply a window to it (they say it should be a Kaiser window, not the easiest to calculate). Katja Kind regards, Aaron Date: Tue, 2 Oct 2012 00:52:00 +0200 Subject: Re: [PD] Fractional Delay in PD From: katjavet...@gmail.com To: aaron.thomp...@live.co.uk CC: pd-list@iem.at Hello Aaron, Tried your test patch and here it does not produce the noise you describe. If delay is set to absolute values larger than 1 it produces too large signal values leading to clipping and harmonics, but this is to be expected considering the way the patch is built. I noticed that resulting coefficients were not consistent because you did not use the trigger object in the calculation subpatches to organize the order of operations. With the trigger objects inserted, the FIR calculator seems to work well. I've added sliders in the subpatch to visually verify coefficient values, see attached. Also if you check with white noise as input signal, you can hear the spectrum is unaltered no matter what fractional delay. So, very much OK. Thanks for the patch! By the way I've once made a visualization of fractional delay with sinc kernel, if you're interested I can try to find it. Katja On Mon, Oct 1, 2012 at 10:32 PM, Aaron Thompson aaron.thomp...@live.co.uk wrote: Hello community, Having trouble getting my lagrange 4-point interpolator to function properly. Harmonics are being generated from somewhere, possibly due to the amplitude exceeding FSD (DC offset?). When I then include it in my waveguide, as soon as DSP is enabled, pd beeps, and then leaves crackly noise/fuzz regardless of whether the patch is being fed an audio signal or not. Remove the FIR filters, and it functions again as normal. Interested to know how others have achieved fractional delay filters within pd, be it Lagrange or Thiran Allpass for example. Patch is attached, FIRTest.pd is the parent patch. Any help would be greatly appreciated. Aaron ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list phaseshifter.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] The HISSTools Impulse Response Toolbox: Convolution for the Masses. Call for port to Pd from Max
Happy to learn that HISSTools are released now. Yes I'm certainly interested in a port to Pd. It is very interesting stuff for sound control in live performance situations. I am familiar with IR measurement and minimum-phase filter construction (in C / Pd), so reading and translating certain parts of the code should not give me too much trouble. There's also a graphics class in the package, that's not for me. It would be great if the port can be a collaboration effort, HISSTools is quite an elaborate project. Katja On Thu, Sep 27, 2012 at 3:11 PM, Julian Brooks jbee...@gmail.com wrote: Hi all, After the successful realisation of the [ipoke~] port that we recently undertook I would like to ask if anyone would be up for some more? This time it would be porting the HISSTools Impulse Response Toolbox. Some (cut pasted) bumff: HISSTools first release is a set of tools for working with convolution and impulse responses in MaxMSP. This set of objects addresses various tasks, including measuring impulse responses, spectral display from realtime data/ buffers, and buffer-based convolution, deconvolution and inversion. About HISS here: http://www.thehiss.org/ HISSTools 2012 ICMC paper and link to the Max d/l here: http://eprints.hud.ac.uk/14897/ Some chat on the max-list: http://cycling74.com/forums/topic.php?id=42403 Port is 3-clause-BSD. Last time was genuinely a fantastic example of collaborative working I thought, and a great example of our FLOSS community in action (I'm sure there's a paper in there for someone): good people with the appropriate skills creating super-tight code without ego or conflict. Ace. Big props to Matt Barber, Alex Harker, Charles (Chuck) Henry, P.A. Tremblay and especially Katja Vetter. Really hope some of the above have the energy to get into this again but this is an open call for anyone who has the time and interest in contributing to make it happen. All good wishes, Julian ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Slice Jockey and toxy/tot
On Wed, Jul 25, 2012 at 2:40 PM, Julian Brooks jbee...@gmail.com wrote: Hey all, Slice Jockey's gui is crippled without toxy/tot. Does anyone have tot they can throw in my direction or point to a solution? Some time ago I noticed that toxy is discontinued in Pd 0.43, so I started working on a Slice//Jockey version without toxy/tot. I took the opportunity to introduce some enhancements, notably the ability to playback in different tonalities, and an improved distortion effect. Slice//Jockey v02 should be out end of this summer, but it has to be tested first. Julian, would you like to be beta-tester? Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
Thanks for your mediation Julian. Pierre Alexandre sent ipoke~.c to Charles and to me. If anyone else interested in collaboration on a Pd port please join in. P.A. plans to release ipoke~ under BSD-ish license. Hopefully he'll do that soon so we can discuss details on list, share test versions etc. Katja On Mon, Jul 16, 2012 at 1:26 PM, Julian Brooks jbee...@gmail.com wrote: Hey all, Spoke to P.A. who has asked for any interested party to contact him directly for the source code. p.a.tremb...@hud.ac.uk Cheers, Julian ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
Julian, it is a good idea to first ask P.A. to share the code among a
small group and discuss licence, naming and maintainance matters. I am
still not back home (this mail is typed from a tourist office), but in
one week I will be ready to join in fully.
cheers, Katja
On 6/28/12, Julian Brooks jbee...@gmail.com wrote:
Hey all,
So, after re-reading the thread I guess we're at the point where some
[iPoke~] source would be helpful.
It would seem that there is still two possible approaches for the
[tabwrite4~] option (A B), plus some still to be resolved issues such as
mixing/overwriting which presumably could be user-settings/options
dependent on the proposed usage e.g. modelling a moving source vs looping
software which are two very different practical issues. Right? I would
certainly be in favour, if it makes communal sense, to have one object
which could do both and, as of yet, other unforeseen things.
Perhaps too a reasonably straight port of [iPoke]? would be a good first
project to get this moving towards the proposed [tabwrite4~] or is part of
the problem that currently within Pd [iPoke~] is just not doable?
BTW, my 2-penneth, etc etc - naming wise, if we have hit upon something
which appears to be a fundamental lack from within current Pd I have to
admit to having a slight reservation on encroaching upon Miller's naming
strategy, i.e. would we be bagging something which he would prefer to keep
open for himself? It is a damn good name.
Below is a first draft to P.A., please amend/contribute/re-write/leave as
you see fit:
Dear P.A.,
Thank you for the kind offer to make the source code of your Max/MSP
external [iPoke~] available for a port to Pd.
The source code will be shared amongst a small group of interested and able
Pd coders who have been contributing to a discussion on the Pd-list ('[PD]
ipoke~?') working towards a proposed new object (current working title
[tabwrite4~]). Porting [iPoke~] and being able to understand how you have
managed to resolve some of the issues we currently face (with all due
credit), would be fundamental towards attempting to solve this very
interesting conundrum.
Currently we have not discussed some of the various important practical
issues such as licensing and who and where this new object would be
maintained.
Our first aim would be to create a robust and cross-platform [iPoke~] which
would submit to all of our high standards.
It has been suggested that in keeping with a strategy of clear and open
communication we keep this discussion 'on-list' so please feel free to
respond in kind, or not.
Very best wishes and look forward to hearing from you soon.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
On Fri, Jun 15, 2012 at 11:37 AM, Julian Brooks jbee...@gmail.com wrote: If iPoke~ is of use to our community then I think we should give it a crack. P.A. has very decent coding skills, is supportive of our aims (though has yet to be convinced of its real-world application apart from Pd vanilla) and this would fit nicely with my own passive-aggressive aim to make Hudd music tech more FLOSS/Pd friendly. We also have Alex Harker who has been working on the HISS Tools bundle and is very much a 'fellow-traveller' in these matters, so I'm confident he would pitch-in too. A few months ago I had already expressed my interest for the HISS Tools to Alex Harker. The Huddersfield people are doing great stuff, and their intention to release source code for porting to Pd / SC makes me happy. So yes, I would like to join the gang. Porting [ipoke~] from MaxMsp to Pd should not be too difficult. I'd love to give it a try soon but coming weeks I'll be on a computerless holiday. Anyway I'll try to follow the discussion in the meantime. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
On Fri, Jun 15, 2012 at 3:34 AM, Matt Barber brbrof...@gmail.com wrote: If it used the same interpolator as tabread4~, you could in principle do approach B -- you'd need a struct that held on the the last samples of the previous block, and offset it by a sample. So, let's say you have a blocksize of 4, the first block of incoming signal is [-0.3, 0.4, 0.6, -0.8], and the index block is [0.2, 1.4, 3.0, 5.8]. The way this could work would be to imagine a previous signal block of [0, 0, 0, 0]. Put the last 0 of that block at index 0.2 and the -0.3 at index 1.4. This crosses sample 1, so you find out where that sample sits as a fraction of the difference between those two indices (in this case 0.6), use [0, 0, -0.3, 0.4] as the four points for interpolation between 0 and -0.3, writing sample one as though you were reading from a table with those four points at 0.6 between the 0 and the -0.3 (so far so good?). Then you put 0.4 at index 3.0. Now your interpolation points are [0, -0.3, 0.4, 0.6] to interpolate between -0.3 and 0.4. Index 2 occurs 0.375 between these samples so you run the interpolation function for that fractional index and write sample at index 2, and then you go ahead and write the 0.4 to index 3. Finally, you put 0.6 at index 5.8. You're interpolating between 0.4 and 0.6, and the points are [-0.3, 0.4, 0.6, -0.8]. Index 4 occurs 0.357143 between the two samples and index 5 occurs 0.714286 between, so you run the interpolator twice for those fractional indices, write those samples. Then you save 0.4, 0.6 and -0.8 (the last the samples of the current block of incoming signal), and 5.8 (the last written index) for the next block. When you have the next block you'll have enough info to interpolate between 0.6 and -0.8 from the last block and between -0.8 and the first sample of this one (these steps were actually implied the first time around), and then you're good to go for the next four samples. If I haven't forgotten a step, the same principle ought to work for any blocksize 4 or larger, and you'd need specialized policies for blocksizes of 1 or 2. Sorry for the length, but sometimes detailed examples can be helpful to get things straight. After reading through it several times, I think I understand your example, and how this could be expressed and implemented generally: - an outer perform loop iterates over N input signal samples / float write indexes, where N = blocksize - an inner loop iterates over all integer write indexes inbetween float write indexes stored at [n] and [n+1] (there could be none, one, or more than one integer index in that interval) - for each integer write index, calculate the corresponding read index as a fraction of the interval between the two enclosing float indexes - based on that fraction, do the four point interpolation to calculate the sample that must be written Not sure if I got it right, and if this would give correct results for all cases. Also, there would be no natural bound on the amount of samples written. Imagine a user feeding large random numbers to the write index inlet... There could be a user-settable bound on resampling factor. For moderate resampling purposes it could be an efficient model. Seems we're getting close to an implementation of [tabwrite4~]. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
On Sat, Jun 16, 2012 at 5:01 PM, Matt Barber brbrof...@gmail.com wrote: The user-settable bound would just be in how they decided to use it. Think of it like [until] -- there's no reason to make the user set an upper iteration bound - the user does that just by using it in a way that doesn't crash Pd (and some until loops are more expensive than others). Maybe you're right. Though [tabwrite4~] would be more complicated to handle than [until], user-tests will indicate wether a 'safety belt' would be desired, it is not a prerequisite for the object's functioning. The main thing I see wrong with what we've been calling approach B is that there isn't a good policy for what to do when 1) the index goes backwards in the table, and 2) what to do when the table already has info in it. One could have settable interpolate on backwards jump (default should probably be no) and settable mix new samples with what's there, or overwrite them. When the index goes backwards in the table, the object should write backwards, like [poke~] does. In my view, the object should always overwrite samples, like [poke~] again. I did my sound-on-sound looper with [poke~] and [tabread4~], a mix can be done externally. (see http://puredata.hurleur.com/sujet-5021-sound-sound-looper-clear-option). Now, if we move forward, we need think about what to name it. [tabwrite~] currently does something that maybe should have been called [tabrecord~], so the [tabwrite4~] name is maybe a little misleading. The delay version could be called [vdw~] -- it would take two signals in and output one signal (there's no reason for it to maintain a multitap-able delay buffer because all the relevant work is done on the write end, so if you need multiple read taps you can just feed it into a [delwrite~] further down). I like the name [tabwrite4~]. Every Pd user is (or will be) familiar with [tabwrite~] already, and [tabwrite4~] will be used in combination with [tabread4~], nothing could be more logical. For various reasons I think what we've been calling approach A -- writing a filter kernel into the buffer for every sample is better for the delay version than approach B, but I can't get into it right now as I'm about to board a plane! Matt I'm about to leave for a 3 week holiday, computers will stay home! (I'm almost tempted to smuggle one in my luggage and write the class in my tent, Pd addict I am). Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
On Sat, Jun 16, 2012 at 7:16 PM, Matt Barber brbrof...@gmail.com wrote: When the index goes backwards in the table, the object should write backwards, like [poke~] does. In my view, the object should always overwrite samples, like [poke~] again. I did my sound-on-sound looper with [poke~] and [tabread4~], a mix can be done externally. (see http://puredata.hurleur.com/sujet-5021-sound-sound-looper-clear-option). Consider the use case where one wants to use the table as a buffer and they write through it and loop back to the beginning of the table when it reaches the end. Let's say the table is 44100 samples long, and the index loops from 44087.3 to 2.1 to start writing the table again. Does it interpolate all the intervening samples BACK through the table, or does it interpolate the 14 or so samples FORWARD through the loop? Or neither? These are all possibilities. You're right, there should be a user-settable loop size (which is not by necessity identical to table size) and if the forward or backward interval is equal or larger than loop size, a wrap is done. But wait: if the check is done anyway, it could as well be (a)bused to set an upper bound to upsampling As far as mixing vs. overwriting is concerned, that actually depends on what it's trying to model. Overwriting is probably right for a looper, but mixing is right for a recording of a moving sound source - and because [poke~] doesn't interpolate it's not an issue (it wouldn't be useful to model a moving sound source). But 'approach B' condenses 4 read samples into 1 write sample, so basically it does the same as [poke]: writing one sample at a time. There is no need for mixing internally. If you want to mix, it can be done externally. In my view, a Pd object need not internalize functions that can be done externally, unless there is a huge performance penalty involved. Note that approach A depends on mixing to work because the interpolation would need to be the emergent result of having mixed kernels into the table. Overwriting would defeat the purpose entirely. Yes, with 'approach A' mixing is essential, as the tails of the kernels must overlap. Then you get the amplitude effect. It is a completely different model, and maybe these models each have their own field of application. I like the name [tabwrite4~]. Every Pd user is (or will be) familiar with [tabwrite~] already, and [tabwrite4~] will be used in combination with [tabread4~], nothing could be more logical. I think I agree -- the only problem is that we have different analogies. Consider all of the following: [tabread] : [tabread4] (control, with or without interpolation) [tabread4] : [tabread4~] (interpolating, one control and one for signals) [tabwrite] : [poke~] (write at an index using control or signal) [tabwrite~] : [tabplay~] (record a signal to a table, or play a signal from a table) [tabread4~] : [tabwrite4~] (read or write samples at specific index from/to a table with interpolation) [tabwrite~] : [tabwrite4~] (write samples to a table at specific index to a table, with or without interpolation) -- wait, that's not what tabwrite~ does! [tabwrite~] could have been maybe better named [tabrecord~]. [tabwrite] and [poke~] are the analogous objects, so one could make a case for calling it [poke4~] (does the same thing as [poke~] but with interpolation, in the Pd nomenclature). Or maybe [tabwrite4~] would imply to some people that you don't control it with indices, but with an up- or downsampling factor. I think [tabwrite4~] is the best name for what we've been talking about, but the asymmetry with the names of other objects gives me pause. Yeah [poke4~] is apt for a 4 point interpolating signal write object with index control. OK, onto the next flight! Have a good trip! Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
On Thu, Jun 14, 2012 at 8:41 PM, Miller Puckette m...@ucsd.edu wrote: I've been thinking about this for some days. I agree there are two fundamentally different approaches (A: deal with each incoming sample independently, for each one adding some sort of filter kernel into the table; or B: advancing systematically through the table, filling each point by interpolating from the input signal). I've been focused on approach B (interpolate from the input signal) for long time because it could eventually use the [tabread4~] interpolation scheme, creating a parallel between those processes. But... today I realized why approach B could not work at all for an object which takes float indexes as arguments for writing, like you would expect from [tabwrite4~], [ipoke~] or any variable speed writer: for each perform loop, you get N (=blocksize) signal values and equally many index values, so it would be logical to iterate over N input samples, but in contrast, it would be very complicated to iterate over the output samples and couple these to index values. In fact, it would require yet another interpolation. Approach B would only work fine for an object which has a fixed resampling factor, settable via message. And then, the question how to synchronize it with a [tabread4~] is still open. It's weird how puzzling the task of fractional speed writing is, compared to fractional speed reading. Better focus on approach A (adding a fractionally delayed kernel into the array for each input sample). Approach A does not in itself impose a preferred kernel type or length, so different options could be offered to the user, varying in performance and precision aspects. Each kernel length, if it is fixed (and zero-phase), would imply a known delay, so the user can reckon with it. As I see it, calculating the resampling factor for normalization purposes need not be spoiled by numerical disasters, as each difference is found from two consecutive input index values, there is no autonomous cumulative effect. Or did I overlook something? Anyway, I have to reset my brain again for a new focus on [tabwrite4~], [vtabwrite~] or whatever it's name could be. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
On Sat, Jun 9, 2012 at 5:18 PM, Matt Barber brbrof...@gmail.com wrote: Csound has a variable write delay opcode that would be worth looking at - the csound website has just been flagged by google for having malicious content so I can't link to the manual page, but the opcode is called vdelayxw. Unfortunately I can not understand the c code of vdelayxw. There's comments for the obvious things but not for the magic numbers and other tricks. But it may be a method for sinc-interpolated resampling. James Fenn pointed to Julius O. Smith's pages on resampling and sinc-interpolation: https://ccrma.stanford.edu/~jos/resample/ After reading the pages and experimenting with the proposed sinc tables, I noticed that proper sinc-interpolation would be fairly cpu-intensive. It is much less effective than [tabread4~], because 4 point sinc-interpolation would not even work for the simplest resampling job. Compare with a FIR filter, which should be up to a few dozen points per octave resampling. In addition to that, an object like [ipoke~] or [tabwrite4~] implies a continuously variable resampling factor, which depends on the distances between consecutive float indexes received at the index inlet. Should the interpolation order grow according to distance? If so, what would be the limit? On the other hand, think of [tabread4~]: it's interpolation scheme is fixed, no matter what resampling factor. With extreme resampling, aliases may be noticeable. But what the hell, it doesn't sound like the original music anyway, when sped up or down to extremes. That is the difference with an offline resampling job, when the original sound must be preserved insofar the new frequency range allows. In that sense, an interpolation scheme like in [tabread4~] could be used for realtime variable speed writing, leaving the consequences for the user. For example, if you make large jumps through the table, many old samples would simply not be rewritten. But even with interpolation quality requirements so relaxed, it is not by itself clear how the samples should be written. Using sinc-interpolation, each input sample could be written as many samples of a (eventually phase-shifted) sinc function, with amplitude compensation for the overlap. The interpolation scheme of [tabread4~] however can not calculate four output samples based on one input sample, it could only calculate one output sample based on four input samples. Imagine how one would do this with a fixed resampling factor. For example with resampling factor 0.75 (downsampling) you would write 64 * 0.75 = 48 samples into the array for every block of 64 input samples, while incrementing the read index by 1 / 0.75 = 1.333. Another example, with resampling factor 1.5 (upsampling) you would write 64 * 1.5 = 96 samples into the array for each block of 64 input samples, while incrementing the read index with 1 / 1.5 = 0.666. The perform loop would not iterate over an integer n (= blocksize), but it would just break when the float read index exceeds n. To accommodate for interpolation, and for index increments larger than one, a few samples of fixed delay 'headroom' must be introduced. In a [tabwrite4~], resampling factor would follow from index increments calculated from float index values received at the inlet. But what to do with large increments, exceeding the delay 'headroom' at the end of the input buffer? And another question: what to do with very small increments, leading to massive amounts of written samples and possibly to cpu overload? When starting on [tabwrite4~] a few months ago, I stumbled upon these problems. I then considered a version where you don't enter a float index at signal rate, but a resampling factor at message rate which can be checked for bad values, and set the delay 'headroom' as needed. But such a write object would need another method to optionally synchronize with a read object, and I have not worked that out either. Suggestions or comments are appreciated. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ipoke~ ?
Ha, finally a detailed discussion on this topic, I like it. My replies are inlined. On Wed, Jun 13, 2012 at 10:27 PM, Matt Barber brbrof...@gmail.com wrote: Hi, I've been going through the vdelayxw code myself. See comments: On Wed, Jun 13, 2012 at 12:30 PM, katja katjavet...@gmail.com wrote: On Sat, Jun 9, 2012 at 5:18 PM, Matt Barber brbrof...@gmail.com wrote: Csound has a variable write delay opcode that would be worth looking at - the csound website has just been flagged by google for having malicious content so I can't link to the manual page, but the opcode is called vdelayxw. Unfortunately I can not understand the c code of vdelayxw. There's comments for the obvious things but not for the magic numbers and other tricks. But it may be a method for sinc-interpolated resampling. It almost certainly is some kind of windowed sinc, and you're right about the magic numbers. I don't think you need to know for sure what the exact interpolation scheme is to make sense of it, though; my understanding of it is as follows: For both the variable read and variable write delay opcodes in csound, one chooses an interpolation window size - say 32 samples. Now, let's say we're trying to READ from the delay line at sample index 116.33. So we need to interpolate between sample 116 and 117. Given our 32-point interpolation window, the earliest sample that will have an effect on the interpolation is sample 101, and the last one is sample 132, so to find the correct interpolation we need to sum together all the scaled windowed sincs (or whatever convolution kernel is in the interpolation window) for each of those 32 samples, at index 116.33, which gives us our read value. The write works rather in reverse: if we want to write a sample at index 116.33, then we need to calculate the windowed sinc (or whatever) for the input sample centered on 116.33, and MIX (not overwrite) those values for samples 101-132 into those samples. What emerges, then, becomes the cumulative effect of having interpolated: imagine the next sample written is at index 118.54 - you're going to mix its function into samples 103-134, and the overlap with the previous action is going to cause the interpolation to work once those samples reach the read head. In that way, a variable write into a delay line is somewhat easier conceptually -- if it's done this way -- than a [tabwrite4~] would be, because the way the table is read is predetermined. Nothing is ever read until all the relevant input samples have had a chance to affect the output in the appropriate way. On the other hand, think of [tabread4~]: it's interpolation scheme is fixed, no matter what resampling factor. With extreme resampling, aliases may be noticeable. But what the hell, it doesn't sound like the original music anyway, when sped up or down to extremes. That is the difference with an offline resampling job, when the original sound must be preserved insofar the new frequency range allows. In that sense, an interpolation scheme like in [tabread4~] could be used for realtime variable speed writing, leaving the consequences for the user. For example, if you make large jumps through the table, many old samples would simply not be rewritten. But even with interpolation quality requirements so relaxed, it is not by itself clear how the samples should be written. Using sinc-interpolation, each input sample could be written as many samples of a (eventually phase-shifted) sinc function, with amplitude compensation for the overlap. The interpolation scheme of [tabread4~] however can not calculate four output samples based on one input sample, it could only calculate one output sample based on four input samples. Two points here. The last thing you said is not actually true -- each interpolation scheme has an associated convolution function, which can be calculated by imagining what the interpolation would look like for a single sample whose value was 1.0 surrounded by zeroes everywhere else. This 4-point piecewise function can be used to write four samples in its immediate vicinity the same way that the sinc does in the csound example. Meaning, there is also a convolution kernel for linear interpolation? How would it look like? Ah, it would be a simple dirac delta, but the point is, the kernel can be applied time-shifted with fractional delay, matching the fraction in the index. By the way, this also holds for sinc-interpolated resampling as described by Julius O. Smith: a linear interpolation in the sinc-table to make the result more precise. Interpolating the interpolation kernel... It seems the bigger question to me is, if you skip somewhere far in the table, you're going to write four samples, and then another four samples somewhere else. Maybe this is OK, but another way to think of what to do would be to imagine the incoming signal as something you're interpolating over the way you would do when reading from
Re: [PD] ipoke~ ?
On Sat, Jun 9, 2012 at 11:00 AM, Georg Bosch k...@stillavailable.com wrote: things I used ipoke~ for in Max include an array/buffer based looper that allows for overdubs while changing playback speed, and pedal-style delays, where each feedback iteration is pitchshifted (see also discussion here: http://puredata.hurleur.com/sujet-3204-different-ways-implementing-delay-loops For exactly that purpose I was looking for [tabwrite4~] a while ago, see: http://lists.puredata.info/pipermail/pd-list/2012-01/093476.html Indeed [ipoke~] would be useful for many things. Did anyone ask Pierre Alexandre if he is willing to release the code so it can be ported to Pd? Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] what makes Pd-extended 0.43 so CPU-hungry?
On OSX I use 'Activity Monitor' for quick check of CPU load and Shark.app for serious performance profiling, but for GNU/Linux I don't know a good equivalent of Shark. So on Debian I just start top, and for my live performance setup which does ~40% CPU load with Pd-extended 0.42, it is ~60% with 0.43. Top makes distinction between 'pdextended' and pd-gui, but heavy GUI use is reflected in increasing percentages for Xorg process as well. However, the load-increase with Pd-extended 0.43 is on account of the pdextended process (with my setups at least). Wish I could track that down to specific functions like with Shark.app. In the case of OSX it was clearly the Apple dsp function calls consuming a great deal of CPU time, which could be avoided by using an external soundcard instead of the internal card, and Jack instead of PortAudio. I've tried to use Oprofile on Debian, but this gives me a kernel failure soon as I start sampling. Does anyone know of a fine performance profiler for GNU/Linux? Katja On 5/4/12, Hans-Christoph Steiner h...@at.or.at wrote: I honestly don't know the cause, and haven't really checked on numbers. I mostly work on my four year old laptop, and test by running patches I know (solitude is a good test of heavy CPU usage, it won't run on a machine less than 1.6GHz, from my experience). As for drawing operations like anti-aliasing, those would not show up in the 'pd' process, but rather the 'pd-gui' process, since that's the Tk part. Are you seeing the CPU increase in the 'pd' process? How are you measuring this? .hc On May 4, 2012, at 9:31 AM, katja wrote: Hello, I've installed Pd-extended 0.43 versions (Linux and OSX) from the autobuilds several times in the past year. The latest builds seem to work fine in many aspects, but they are still so CPU-hungry: ~ 50% more than Pd-extended 0.42. How come? A while ago, the new PortAudio version was blamed (http://www.mail-archive.com/pd-list@iem.at/msg50357.html). Indeed, using Jack solves the load difference for OSX. But on Debian I also observe a 50% load increase for the new Pd-extended. No matter if ALSA or Jack is used. Does anyone have similar observations with Linux builds? BTW, I'm happy with Tk 8.5's antialiased font! Initially, I feared that antialiasing was responsible for increased load on Debian, but disabling GUI updates did not make noticeable difference. It seems that antialiasing is done rather efficiently, the performance drop must be somewhere else. Katja ___ 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] ubuntu 12.04 precise pangolin pd-extended 0.43.1 amd64 deb package for download - link included
On Fri, May 4, 2012 at 5:14 AM, Hans-Christoph Steiner h...@at.or.at wrote: Does it does type-punning? Does compilation give warnings about that? That's my guess. [blosc~] does type punning indeed, it uses type unsigned long in phase conversion, blosc~.cc line 86/87. But there is no literal bitmask defined, only a scaling. Not sure if this type punning gives a problem. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ubuntu 12.04 precise pangolin pd-extended 0.43.1 amd64 deb package for download - link included
On Fri, May 4, 2012 at 10:26 AM, katja katjavet...@gmail.com wrote: On Fri, May 4, 2012 at 5:14 AM, Hans-Christoph Steiner h...@at.or.at wrote: Does it does type-punning? Does compilation give warnings about that? That's my guess. [blosc~] does type punning indeed, it uses type unsigned long in phase conversion, blosc~.cc line 86/87. But there is no literal bitmask defined, only a scaling. Not sure if this type punning gives a problem. Wait, it uses unsigned long long and unsigned long as distinguished data types for some tricks. But these types could be both 64 bit on a 64 bit system, no? Would it not be better to use types from stdint.h (or cstdint.h in this case)? Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] what makes Pd-extended 0.43 so CPU-hungry?
Hello, I've installed Pd-extended 0.43 versions (Linux and OSX) from the autobuilds several times in the past year. The latest builds seem to work fine in many aspects, but they are still so CPU-hungry: ~ 50% more than Pd-extended 0.42. How come? A while ago, the new PortAudio version was blamed (http://www.mail-archive.com/pd-list@iem.at/msg50357.html). Indeed, using Jack solves the load difference for OSX. But on Debian I also observe a 50% load increase for the new Pd-extended. No matter if ALSA or Jack is used. Does anyone have similar observations with Linux builds? BTW, I'm happy with Tk 8.5's antialiased font! Initially, I feared that antialiasing was responsible for increased load on Debian, but disabling GUI updates did not make noticeable difference. It seems that antialiasing is done rather efficiently, the performance drop must be somewhere else. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] deep note in Pd
Great audiovisual composition. One could also spend days or weeks learning advanced Pd techniques from it. A typical Jonathan Wilkes patch, I would say. Katja On Wed, May 2, 2012 at 7:50 PM, Jonathan Wilkes jancs...@yahoo.com wrote: Yeah, my default screen-video-capture tool doesn't capture sound, so I just quickly recorded to [writesf~] at whatever level sounded good in my earphones and put it together with the webm. The patch is attached. -Jonathan - Original Message - From: Max abonneme...@revolwear.com To: Jonathan Wilkes jancs...@yahoo.com Cc: Sent: Wednesday, May 2, 2012 7:48 AM Subject: Re: [PD] deep note in Pd LOL the volume is a bit low. Am 02.05.2012 um 04:49 schrieb Jonathan Wilkes: Batuhan Bozkurt wrote a great blog entry about recreating the THX Deep Note with Supercollider awhile back. So I tried it in Pd. Then I lost the patch. Then I tried recreating it from memory, and upped the ante with some visuals :) http://www.youtube.com/watch?v=ESi7ub8AVPs (Unfortunately the a and v don't sync up so well, but you can get the general idea) -Jonathan ___ 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] (OT) safely connect piezo transducer to soundcard as microphone
Hi, A piezo transducer often produces a signal level somewhere inbetween mic level and line level (it depends on size, and method of excitation). Indeed it can be too loud when mic input is used. Another point of concern is impedance, which influences the sound character. If you mount a resistor (in series), the signal level is reduced but the sound is altered as well. Mounting a capacitor (in parallel or series) also works to reduce signal level and alter the sound. Combinations of these (RC networks, effectively) are a great way to tune the sound character to your liking, but it takes a lot of experimentation. Also, the result may be different for each (mic) preamp because input impedance is not fully standardized. Katja On Sat, Apr 21, 2012 at 12:12 AM, Matteo Sisti Sette matteosistise...@gmail.com wrote: Hi, This is OT but I'm sure many of you have used piezo microphones sometimes. I've often connected a piezo transducer to the microphone input of my computer (and other computers) by simply soldering the two wires to the T and S of a minijack plug, and it works just fine and my soundcard hasn't suffered any damage (apparently at least). However, I am concerned that a strong sound input (e.g. hitting the piezo transducer with with fair strength) may actually generate a voltage peak (thought only for a short time) capable of damaging the soundcard, couldn't it? Also, a friend of mine did the same with his Macbook and his headphones output has stopped working (may be just a coincidence though). Is there an easy way to make it safer? I seem to remember I had read somewhere (can't find it) about connecting a 1MOhm resistor in parallel... woudl that do the trick? 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] why does PD round numbers? (in tables, in messageboxes, etc)
Hello, I did another array-update performance test, following Jonathan's earlier suggestion. A 800 pt array (this is also the visual size) is updated every 50 milliseconds. This is very cpu-intensive anyhow. For Pd-double ~4% more than for Pd-extended 0.43.1. Pd-double translates a number to maximally 20 characters (like in -0.00029718922544271) and Pd-extended to a maximum of 12 characters (like in -0.000958107). The small performance difference indicates that the conversions are relatively fast, compared to other aspects of the array update. Indeed, Tcl code is responsible for most of the cpu load in array updates. I've checked it with Shark.app performance profiler. It seems to me that an ASCII decimal representation with more decimal digits, like the %.14lg used in Pd-double, does not seriously hurt (the performance of) storage and transmission to Pd-gui. When printing numbers in boxes on screen however, simply using more than six significant decimals would not give the desired effect for single precision numbers. Since printing numbers in boxes happens relatively seldom, a more detailed routine could be spent on that, to display the desired precision. In the sense of Miller's suggestion, convert a number as typed in a box into a number representable by Pd's float type. Allow numbers to be printed with full precision up to a reasonable number of significant decimal digits For example, %lg14 no matter what float type, would be sufficient for all practical purposes. However, numbers should not be printed with more characters than originally typed in the box. If you'd type 4294967297 it would be converted to 4294967296 (in single precision case). But if you typed 0.01, Pd should not print 0.00977648. Katja On Wed, Apr 11, 2012 at 10:01 PM, Miller Puckette m...@ucsd.edu wrote: Hi all - this section 9.3.1 describes how to convert strings to numbers - but isn't the real problem how Pd converts numbers to strings? I think the ideal solution when the number of characters isn't an issue is to specify that whatever prints out should be a string that, when scanned using scanf(%f, ...) (or scanf(%lf, ...)) returned the exact 32-bit number. I'm not 100% sure this is possible, since there might be 32 bit values that scanf can't ever return, but I bet there's a way to get really really close :) Miller On Wed, Apr 11, 2012 at 09:35:14PM +0200, Krzysztof Czaja wrote: On 04/10/2012 02:20 PM, katja wrote: ... http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf Then in section 9 the conversion rules are presented in greatest detail, with 'number to string' in section 9.3.1. Krzysztof, do you think that MaxMsp uses the same rules for printing numbers in boxes? If so, it could be used as a guideline for Pd as well. not really. The old, six decimals after point limit still remains all over Max6. But if you force something more sane into Pd, they'll likely follow... Krzysztof ___ 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] why does PD round numbers? (in tables, in messageboxes, etc)
2012/4/9 IOhannes m zmölnig zmoel...@iem.at: A non-decimal ASCII format instead, would make existing patches unreadable. right; i think this is also the reason why Pd doesn't do any binary storage/transmission: it makes debugging so easy if you can actually understand what is going on without an assembler book besides the keyboard. I mean to say that switching to any format other than decimal ASCII would make it impossible for Pd to interpret patch files using the current format. the major drawback i see right now is, that raising the number of bytes used to transmit a single number will make table updates even more costy than they already are. Large tables are mostly stored in an audio format, rather than text. But indeed, saving and loading large tables as text is already time-consuming with the current format. Text is also used by the [pd] object to transmit numbers / signals. And how about sending over UDP or TCP? Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
