Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
katja, you can see the error as an amplitude fluctuation in the array (i think thats the error) it gets more and more dominant with higher frequencies and at some point you hear a deep note, which seems to be the amplitude modulation coming into the hearable range. or am i wrong? i also could not tell a hearable difference in accuracy with upsampled against non upsampled version. here is the attachment again, maybe it got lost last time, or i was to tired :-) simon sinetosawtooth-II.pd Description: Binary data On 30 Apr 2014, at 23:04, katja katjavet...@gmail.com wrote: 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
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
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 - 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
Re: [PD] ALSA broken pipe on pd-extended on Beaglebone?
Alsa is only supposed to work with One application at a Time. Am 29.04.2014 um 17:15 schrieb David Welch nicederangem...@gmail.com: Hi all, I am currently working on an embedded device made up of some hardware, Arduino, Beaglebone running Debian white with audio cape. I am attaching a pd file that works on a laptop. For the beaglebone, basically I change the serial port argument to 4 for [comport] but get a Broken Pipe error ALSA input error (restart failed): Broken pipe restarting input device from state 2 ALSA output error (restart failed): Broken pipe But ALSA seems to be working okay as long as only 1 application tries to use it. I followed most of the directions here to get it working (http://www.csounds.com/journal/issue18/beagle_pi.html and http://puredata.info/docs/embedded/bbb/) I installed pd-extended by adding the repository to /etc/apt/sources.list with directions from here (http://puredata.info/docs/faq/debian). I know sound is okay: speaker-test works ok. pd-extended works including sound, at least for a simple patch (also attached). Jack is not installed (doesn't seem necessary for single headless instance of pd-extended). Hmm...any help would be greatly appreciated! David Welch musicalquilt_28Apr14.pd simple_PD_test.pd ___ 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!!!
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~] 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
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
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 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
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
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 not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
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 not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50
[PD] pitch to voltage
dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because the samphold~ object is inaccurate. but i then saw that the sawtooth wave from the rpole~ object has no constant amplitude even with the input frequency not changing. so it seems that either rpole~ or change~ is not accurate. or the problem is that i sample in the middle of the rising and not at the top ( as described earlier) attached the sinetosawtooth patch. set your sound card to 44100 or change the 22050 in fexpr~ to half the sampling frequency. i would really appreciate if somebody could have a look at this, thanks, simon sinetosawtooth.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UDOO Quad and Generic Guitar to USB link issues
do you use the hardware or the plugin tab in the pd preferences? i found that i had to use the plugin and not the hardware to get results without distortion. also you should use debian hard float image and not linaro, it works better with puredata. and, i would not use jack but alsa directly with puredata. On 11 Apr 2014, at 01:54, Carlos Sanchez csanchez...@gmail.com wrote: Neat project sir! I have tried what you mentioned Brian and I cant get the system to even play sounds with the right device. Using aplay file.wav works with the default output but when i try to specify the output like so aplay -D hwplug;2,0 file.wav nothing comes up. I got these commands somewhere on the net, can you vouch for them? Also, when listing the devices with alsamixer, my soundcard lists a mic input which is odd since it has a mono in and stereo out... If this is of any use, here is the output of aplay -l: List of PLAYBACK Hardware Devices card 0: vt1613audio [vt1613-audio], device 0: HiFi vt1613-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: imxhdmisoc [imx-hdmi-soc], device 0: IMX HDMI TX mxc-hdmi-soc-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 My soundcard is the card 2 and I can not get any sound out of it via aplay! On Tue, Apr 8, 2014 at 5:26 PM, Brian Fay ovaltinevor...@gmail.com wrote: The reason I suggested trying arecord | aplay is because it would be running input and output simultaneously. In Audacity, you're doing one after the other. Unfortunately, I'm not sure exactly what is going wrong here. Does your soundcard work as expected on other computers? Was it fine on the BeagleBone Black? On the Raspberry Pi, I'm running a multi-effects pedal, all built in Pd. There's two parallel chains of processes, (each can run up to eight effects). The effects I'm using are a looper, delay, waveshaper distortion, flanger, granular synthesis (sort of limited implementation), reverb, and EQ. I'm controlling things with a QuNeo MIDI controller and a push button attached to the GPIO pins on the Pi. By default, each of the eight effects in each chain are set to bypass, which simply passes the signal onto the next effect. However, you can adjust this on the fly for the effects to be whatever you want, so I can set up something like: Chain A: looper - distortion - flanger - delay - granular - reverb - EQ - bypass - output Chain B: delay - bypass - bypass - bypass - bypass - bypass - bypass - bypass - output I can independently control volume of each chain, so I could use Chain A to build up some sort of droning ambience, and then solo over it using Chain B. In practice, there is definitely a limit to the ability of the Raspberry Pi. I think the example I just mentioned would probably run, but if I try throwing too many effects on at once, (flanger, reverb, distortion, and granular are all pretty intensive), I will start getting glitches - huge crackles and jitters in audio. Turning off a few effects will stop the glitches, but I all I can do to prevent them is to be conservative about how many effects I turn on. Just uploaded a little demo to Soundcloud of a recording I made with a somewhat similar FX setup to what I mentioned. It was recorded with my cell-phone, so it's a bit awful sound quality-wise (also really really quiet, whoops...). https://soundcloud.com/ovaltine-vortex/raspberry-improv If you're curious about the patches and stuff, it's all here, but it's hard-coded to MIDI values on the QuNeo and might be a bit confusing: https://github.com/YottaSecond/thesisRepo On Sun, Apr 6, 2014 at 2:37 PM, Carlos Sanchez csanchez...@gmail.com wrote: Hey list, Thanks for your prompt replies and helpfulness! I could not get qjackctl to work, the audio will not go through and the PD CPU load gets abnormally high at around 67%... I had already played with the sample rate and I had noticed that augmenting the frequency yields better results but the noise was still very present. The sound card itself works correctly with Audacity so I am sure it would work with the arecord and aplay commands Brian suggested. Weirdly, it is only with PD that it is struggling... On a more encouraging note, as Brian suggested, it seems that the problem (or one possibility) is the duplex audio. I haven't thought about using the card as an output only device before and it did work! But afterwards, I was not able to change the settings back and use the noisy duplex audio any more, I was only able to switch the output devices... @Brian: What type of software are you using for the signal processing with the Raspberry Pi? I am very curious because I had first attempted to build this project on a BeagleBone Black but the heavy PD patches made it unstable or
Re: [PD] pitch to voltage
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 not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because the samphold~ object is inaccurate. but i then saw that the sawtooth wave from the rpole~ object has no constant amplitude even with the input frequency not changing. so it seems that either rpole~ or change~ is not accurate. or the problem is that i sample in the middle of the rising and not at the top ( as described earlier) attached the sinetosawtooth patch. set your sound card to 44100 or change the 22050 in fexpr~ to half the sampling frequency. i would really appreciate if somebody could have a look at this, thanks, simon ___ 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] pitch to voltage
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 not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because the samphold~ object is inaccurate. but i then saw that the sawtooth wave from the rpole~ object has no constant amplitude even with the input frequency not changing. so it seems that either rpole~ or change~ is not accurate. or the problem is that i sample in the middle of the rising and not at the top ( as described earlier) attached the sinetosawtooth patch. set your sound card to 44100 or change the 22050 in fexpr~ to half the sampling frequency. i would really appreciate if somebody could have a look at this, thanks, simon ___ 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] pitch to voltage
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 not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because the samphold~ object is inaccurate. but i then saw that the sawtooth wave from the rpole~ object has no constant amplitude even with the input frequency not changing. so it seems that either rpole~ or change~ is not accurate. or the problem is that i sample in the middle of the rising and not at the top ( as described earlier) attached the sinetosawtooth patch. set your sound card to 44100 or change the 22050 in fexpr~ to half the sampling frequency. i would really appreciate if somebody could have a look at this, thanks, simon ___ 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] pitch to voltage
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 not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because the samphold~ object is inaccurate. but i then saw that the sawtooth wave from the rpole~ object has no constant amplitude even with the input frequency not changing. so it seems that either rpole~ or change~ is not accurate. or the problem is that i sample in the middle of the rising and not at the top ( as described earlier) attached the sinetosawtooth
Re: [PD] pd on debian hardfloat on udoo
yeah, but that page is somewhat misleading, the 12.04 linaro (based on ubuntu) in the udoo download section is not hf. i used the debian hf image they provide. here is the “sound card” i use: http://www.dx.com/p/usb-3d-sound-adapter-color-assorted-5831#.UzHt6Nzoah0 On 25 Mar 2014, at 10:56, Alexandros Drymonitis adr...@gmail.com wrote: On Tue, Mar 25, 2014 at 11:51 AM, Alexandros Drymonitis adr...@gmail.com wrote: On Tue, Mar 25, 2014 at 12:00 AM, Simon Iten itensi...@gmail.com wrote: just a quick update: pd runs definitely smoother on the udoo with the debian hard float image. Also, it might be obvious to some, but which one is the debian hard float image? Is it in Udoo's website? Sorry to bother the whole list, just found this page which mentions the hard float flavors: Debian Wheezy, Ubunt Studio and Ubuntu 12.04 ___ 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] udoo board sound issues
hey dan and list, i gave pd on the debian hardfloat image a try and can not run it. it compiles just fine. this is what i get on the console... debian@udoo-debian-hfp:~$ pd -verbose Pd-0.45.4 () compiled 14:17:43 Mar 24 2014 port 5400 TCL_LIBRARY=/usr/local/lib/pd/lib/tcl/library TK_LIBRARY=/usr/local/lib/pd/lib/tk/library wish /usr/local/lib/pd/tcl//pd-gui.tcl 5400 Waiting for connection request... /usr/local/lib/pd/bin/pd-watchdog watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... then a watchdog-signaling loop... this also happens with the version installed via synaptic. any thoughts? cheers On Sat, Mar 15, 2014 at 4:50 PM, Dan Wilcox danomat...@gmail.com wrote: Yeah, I wanted to use the hard float image but I was under time pressure and more things seemed to work out of the box with the Linaro one. I'll have more time to revisit it later. On Mar 15, 2014, at 12:46 PM, Simon Iten itensi...@gmail.com wrote: hmm, well to me 12ms is way to much. but then again i play a lot of fast attack notes in up-tempo pieces :-) thanks for your notes anyway, they helped a lot! and write back when you tried with the debian hardfloat image. i tried it for a short time and it was not very stable with pd. but then again i did not try a lot of things to fix this. cheers On 15 Mar 2014, at 13:10, Dan Wilcox danomat...@gmail.com wrote: Check this page: http://www.michalkaszczyszyn.com/en/tutorials/latency.html#acceptable I was wrong, the guitar to amp latency at 1 meter away is roughly 3 ms. The accumulation of a monitors and an effect or two gets you to 8ms. Acceptable latency is 12 ms. Again, I haven't measured my rig or the latency of my old wearable rig, both both were responsive to me, so they must e at least around 12 ms. Sorry for being unscientific about it. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Mar 15, 2014, at 5:49 AM, Simon Iten itensi...@gmail.com wrote: dan, no 15 ms is in no way tolerable for live use (if you have effects that should react in realtime) it is of course ok for delay and reverb stuff. the latency from an amp because of cable length and stuff is totally different, since your ear actually hears where the sound comes from and can adapt. but for studio use for example, 15 ms on a headphone is really two attacks for evey attack. heck even 10ms is evil :-) of course your/anyones mileage may vary. but i only wanted the box to output delay and reverb soundscape stuff away, so i might be good. i will add analog circuitry that mixes the dry and effect part of the signal, so i get no (very very little) latency on the unaffected part of the signal. no worries as far as the script goes. i had no problems at all to follow it. but i worked with linux a lot before. i was just suggesting, that the typical ubuntu user would not get some of the steps in between your steps :-) On 15 Mar 2014, at 02:10, Dan Wilcox danomat...@gmail.com wrote: I haven't run any latency tests, so that might be what I'm getting. If so, it's acceptable for what I do. From what I've read, guitar - effects - amp latencies are already closer to 20ms. Sorry I haven't gotten back to the UDOO and pulled the relevant scripts etc off of it yet. I'm trying to get a few things done before I head out of town for work the next 2 weeks. I might be abel to get to it Sunday, but no promises. On Mar 14, 2014, at 8:41 PM, Simon Iten itensi...@gmail.com wrote: hi dan, tried your setup/instructions. thanks, it now works down to 15ms. at 12ms i start to get clicks here and there... your script has some errors (missing instructions a novice would not understand how to deal with). do you want me to post them, or do you overdo it anyway? thanks again simon On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote: Thanks. I was just waiting to redo my website, edit the video, put the pics together, etc etc but life and freelance work get in the way. Man, I could use a clone right about now :P On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote: Also interested in the UDOO setup instructions so thank you. A bit OT but, Dan, love your work (that onward to mars patch is awesome) thanks for the links. I think people should post more of this sort of thing to the list, celebrate what we make. =) On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com wrote: FWIW: here's a picture of my UDOO setup inside my Mars space suit backpack: http://www.flickr.com/photos/danomatika/13115604285/ Media of the backpack in use https://twitter.com/danomatika/status/433273394122207232/photo/1 https://vimeo.com/86670103 (not my video, I'll put out a different edit soon) On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote: I will do that later tonight when I boot the udoo and pull my run scripts
Re: [PD] udoo board sound issues
nevermind, found the solution. here it is.. http://lists.puredata.info/pipermail/pd-list/2012-09/097892.html cheers On Mon, Mar 24, 2014 at 2:43 PM, Simon Iten itensi...@gmail.com wrote: hey dan and list, i gave pd on the debian hardfloat image a try and can not run it. it compiles just fine. this is what i get on the console... debian@udoo-debian-hfp:~$ pd -verbose Pd-0.45.4 () compiled 14:17:43 Mar 24 2014 port 5400 TCL_LIBRARY=/usr/local/lib/pd/lib/tcl/library TK_LIBRARY=/usr/local/lib/pd/lib/tk/library wish /usr/local/lib/pd/tcl//pd-gui.tcl 5400 Waiting for connection request... /usr/local/lib/pd/bin/pd-watchdog watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... then a watchdog-signaling loop... this also happens with the version installed via synaptic. any thoughts? cheers On Sat, Mar 15, 2014 at 4:50 PM, Dan Wilcox danomat...@gmail.com wrote: Yeah, I wanted to use the hard float image but I was under time pressure and more things seemed to work out of the box with the Linaro one. I'll have more time to revisit it later. On Mar 15, 2014, at 12:46 PM, Simon Iten itensi...@gmail.com wrote: hmm, well to me 12ms is way to much. but then again i play a lot of fast attack notes in up-tempo pieces :-) thanks for your notes anyway, they helped a lot! and write back when you tried with the debian hardfloat image. i tried it for a short time and it was not very stable with pd. but then again i did not try a lot of things to fix this. cheers On 15 Mar 2014, at 13:10, Dan Wilcox danomat...@gmail.com wrote: Check this page: http://www.michalkaszczyszyn.com/en/tutorials/latency.html#acceptable I was wrong, the guitar to amp latency at 1 meter away is roughly 3 ms. The accumulation of a monitors and an effect or two gets you to 8ms. Acceptable latency is 12 ms. Again, I haven't measured my rig or the latency of my old wearable rig, both both were responsive to me, so they must e at least around 12 ms. Sorry for being unscientific about it. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Mar 15, 2014, at 5:49 AM, Simon Iten itensi...@gmail.com wrote: dan, no 15 ms is in no way tolerable for live use (if you have effects that should react in realtime) it is of course ok for delay and reverb stuff. the latency from an amp because of cable length and stuff is totally different, since your ear actually hears where the sound comes from and can adapt. but for studio use for example, 15 ms on a headphone is really two attacks for evey attack. heck even 10ms is evil :-) of course your/anyones mileage may vary. but i only wanted the box to output delay and reverb soundscape stuff away, so i might be good. i will add analog circuitry that mixes the dry and effect part of the signal, so i get no (very very little) latency on the unaffected part of the signal. no worries as far as the script goes. i had no problems at all to follow it. but i worked with linux a lot before. i was just suggesting, that the typical ubuntu user would not get some of the steps in between your steps :-) On 15 Mar 2014, at 02:10, Dan Wilcox danomat...@gmail.com wrote: I haven't run any latency tests, so that might be what I'm getting. If so, it's acceptable for what I do. From what I've read, guitar - effects - amp latencies are already closer to 20ms. Sorry I haven't gotten back to the UDOO and pulled the relevant scripts etc off of it yet. I'm trying to get a few things done before I head out of town for work the next 2 weeks. I might be abel to get to it Sunday, but no promises. On Mar 14, 2014, at 8:41 PM, Simon Iten itensi...@gmail.com wrote: hi dan, tried your setup/instructions. thanks, it now works down to 15ms. at 12ms i start to get clicks here and there... your script has some errors (missing instructions a novice would not understand how to deal with). do you want me to post them, or do you overdo it anyway? thanks again simon On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote: Thanks. I was just waiting to redo my website, edit the video, put the pics together, etc etc but life and freelance work get in the way. Man, I could use a clone right about now :P On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote: Also interested in the UDOO setup instructions so thank you. A bit OT but, Dan, love your work (that onward to mars patch is awesome) thanks for the links. I think people should post more of this sort of thing to the list, celebrate what we make. =) On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com wrote: FWIW: here's a picture of my UDOO setup inside my Mars space suit backpack: http://www.flickr.com/photos/danomatika/13115604285/ Media of the backpack in use https://twitter.com/danomatika/status/433273394122207232/photo/1 https
[PD] pd on debian hardfloat on udoo
just a quick update: pd runs definitely smoother on the udoo with the debian hard float image. i am now down to 10ms with no problems (and a very cheap usb-soundcard dongle) 8ms gives some crackles but still works… this is with the usual rtprio and memlock stuff and -rt and for now with a gui. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Raspberry Pi Wolfson Audio Card
hi, nice! one question: On 18 Mar 2014, at 12:02, Winfried Ritsch rit...@iem.at wrote: Am Donnerstag, 13. März 2014, 16:01:20 schrieb Rafael Vega: Anyone wants to share their experience with the BeagleBoneBlack? Yes. Since autumn, i am trying to set up an kit hardware+software with BBB for computer-musicians as stomp box, works quite well, after successfully installed it in a long term sound installation (headless): some points short: system: + BBB moved to Debian since this year (good) + USB Audio works fine und better now with kernel = 3.12 + Network performance works better with kernel = 3.12 - IO support doenst use device-tree overlays anymore on kernel 3.8 + an iio-backend for Jack2 to use the internal AD's in jack for processing sensor data in PD ;-))) but tricky does this mean, we get a “sound” i.e adc~ in from the internal ad’s? sound: + down to 10ms with PD and cheap 8 channel out, 2 in USB soundcard Logilink 7.1(EUR 19.90) + 5ms with Logilink stereo USB (EUR 3,90) + success with audio-cape (stereo, but too expensive for the quality) - sound quality is normally as bad as on most notebooks, tablets and so on + but with a trick: filtered 5V supply for the USB-card not the USB power it seems to get reasonable quality (They have all the same chips like expensive USB cards: C-Media) I just made a blog on this, but it is not public only for intern usage, if anyone is interested in the IEM-embedded-Sound-Kit (doing some audio over ethernet stuff) i can make it open (after some polishing, especially the english) and release the PD-lib (GPIO,AD,I2C,... interfacing) for these devices. This dev's should also work for Cubie-boards, Wand-boards, UDOO and other arm based boards. mfg winfried PS: Maybe we can start an own thread on this. On Thu, Mar 13, 2014 at 3:11 PM, Brian Fay ovaltinevor...@gmail.com wrote: While I'm sure that Dan is right that the UDOO is the better choice for USB audio, I do have to say that I've had decent success using my Raspberry Pi as a guitar effects processor, with the Behringer UCG102 interface. There's definitely a lot of quirkiness to getting it running... for example ALSA gets in an infinite restart loop when attempting low latency on pd-extended, but vanilla starts up fine under the same settings. And then there's the fact that an issue in the kernel screws up USB audio on major distros like Raspbian. I'm using the Satellite CCRMA distro right now with much better success. So far I've got various delays, a looper, and a waveshaper distortion running within the same patch, at 20ms latency with very few noticeable dropouts. Parameters are adjustable with a QuNeo MIDI controller and with a button attached to the GPIO pins. The Pi is a bit more affordable than the UDOO boards, but then again I had to buy a powered USB hub. Ultimately for one audio input the Raspberry Pi could probably serve most purposes, while the UDOO is more likely to scale to bigger installations. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- --- Ritsch, Winfried, Ao.Univ.Prof. Dipl.-Ing. Institut 17 Elektronische Musik und Akustik 8010 Graz, Inffeldgasse 10/III E-Mailrit...@iem.at Homepage http://iem.at/ritsch Mobil ++436642439369 --- ___ 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] Raspberry Pi Wolfson Audio Card
nifty! On 21 Mar 2014, at 14:31, Winfried Ritsch rit...@iem.at wrote: Am Freitag, 21. März 2014, 09:04:00 schrieb Simon Iten: hi, nice! one question: On 18 Mar 2014, at 12:02, Winfried Ritsch rit...@iem.at wrote: Am Donnerstag, 13. März 2014, 16:01:20 schrieb Rafael Vega: Anyone wants to share their experience with the BeagleBoneBlack? Yes. Since autumn, i am trying to set up an kit hardware+software with BBB for computer-musicians as stomp box, works quite well, after successfully installed it in a long term sound installation (headless): some points short: system: + BBB moved to Debian since this year (good) + USB Audio works fine und better now with kernel = 3.12 + Network performance works better with kernel = 3.12 - IO support doenst use device-tree overlays anymore on kernel 3.8 + an iio-backend for Jack2 to use the internal AD's in jack for processing sensor data in PD ;-))) but tricky does this mean, we get a “sound” i.e adc~ in from the internal ad’s? yes, so we use PD dsp-objects to process the data. but samplerate can be different. mfg winfried -- --- Ritsch, Winfried, Ao.Univ.Prof. Dipl.-Ing. Institut 17 Elektronische Musik und Akustik 8010 Graz, Inffeldgasse 10/III E-Mail rit...@iem.at Homepagehttp://iem.at/ritsch Mobil ++436642439369 --- ___ 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] Raspberry Pi Wolfson Audio Card
hey dan, do you have to tell pd to use it’s own core on udoo, or does it so automagically? has this something to do with the cpu group from your script (it did not exist on my system) cheers On 13 Mar 2014, at 15:46, Dan Wilcox danomat...@gmail.com wrote: I don't know the latency. I can try testing that at let you know, but it's definitely good enough for what I need. It is at least lower than 20ms. Acceptable latency for guitar is 12ms, and I think I got around 16ms out of my old setup running on the Pentium III 500Mhz wearable. The main deal with the UDOO, is that it's multiple cores (2 or 4 depending on the board you buy). This way, the kernel has a core, pd has a core, and there are 2 cores left over for other things (my HID-OSC device daemon, etc). On Thu, Mar 13, 2014 at 4:32 AM, Pierre Massat pimas...@gmail.com wrote: Hey Dan, Looks like the UDOO is much better indeed from what you recently posted here. Could you tell us what latency you're achieving ? And which version you're using (with or w/o wifi) ? Cheers, Pierre. 2014-03-13 0:49 GMT+01:00 Dan Wilcox danomat...@gmail.com: Ok for small projects, but you're not going to interface a real stage mic or guitar easily. Would be much better if the next pi version comes with an onboard usb controller, which is the main problem for usb audio on the current pi. For now, the UDOO is where it's at for that. On Mar 12, 2014, at 7:10 PM, pd-list-requ...@iem.at wrote: From: me.grimm megr...@gmail.com Subject: [PD] [OT] Raspberry Pi Wolfson Audio Card Date: March 12, 2014 at 6:38:43 PM EDT To: pd_list Listserve pd-list@iem.at You all see this? http://www.element14.com/community/community/raspberry-pi/raspberry-pi-accessories/wolfson_pi what do you think? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Dan Wilcox danomatika.com robotcowboy.com ___ 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] udoo board sound issues
well, i play a lot in an orchestra. (doublebass) and i can assure you it’s a problem you don’t get used to. (and that is not just me) sure you can adapt to the situation but it is not ideal. let a pipe organ player play with a conductor and orchestra and the fun begins :-) it works but it needs a lot of practice and constant forward-conducting” from the conductor. i also play a lot with an orchestra that focuses on film-music. basically the movie is going on a screen and we play the filmmusic live to it. the conductor (ludwig wicki) has a small screen with the movie and a click on his notestand, and it’s his job to get the orchestra in sync with the movie. he always has to conduct way before the click to even get close to the right spot. so you could say the latency is even worse for the conductor! also i yet have to find an orchestra that plays highly rhythmically fast stuff in sync :-) it’s just a different way of making music. my education is that of a jazz-bassplayer and i had to get into the orchestra “groove” (or the lack of it), before i could understand why they play so non-precise rhythms :-) but it is the only way to stay in sync with each-other and the orchestra. try a symphonic orchestra with a rock-drummer :-) he will get crazy. and to the latencies inherent in wooden instruments: on the doublebass (which many consider as the wooden instrument with the largest latency) the situation is complex. as a player you feel the strings and you have immediate response when you bow or pluck them. so there is no latency for your body. the tone that you hear as a player by the instrument is also there very fast (mostly the attack) but the tone that people here in the audience comes in much later (mostly not the attack) and depends on frequency and volume and if the bass is plucked or bowed. it’s a “problem” with digital instruments or effects when the body experience is non existant and you have to rely solely on your ears. imho this makes a huge difference. cheers simon so i think we should try to make latencies as small as possible, since it helps a lot :-) On 16 Mar 2014, at 02:36, Simon Wise simonzw...@gmail.com wrote: On 15/03/14 23:03, Dan Wilcox wrote: I guess I don't get that since I've been playing that relative latency for years. How is 10-15 ms not real time? It's not even really perceivable unless you're doing lots of high rate short attack decay stuff. At least as far as I can tell. I must be slow. :D Then again, I might be wrong. I'll probably try the hard float Debian UDOO image next. That might give us some room. Musicians in orchestras have been playing with, dealing with, much longer latencies for centuries. An orchestra cannot all be within a metre or so of each other, they are 10s of metres apart, and that is on top of the different set of differences in distance to the audience. In a pit in an opera or ballet it gets much worse. Any modern PA adds substantial latencies to achieve a good sound in the audience, and mostly use mics and foldback in other kinds of performances, and make the musicians life easier by avoiding the natural latency issues of an acoustic performance. Organ players have dealt with huge latencies for as long as there have been big pipe organs. Percussionists using real instruments don't get the attack from their instruments till well after they initiate the note by starting to move their stick toward the cymbal. Wood and metal instruments all have considerable latencies, some much more than others, it is all part of playing that particular instrument. Electric guitar players rely on the latency between amp and pickup (this time only a few milliseconds) for their sound. Any digital instrument also has latencies. Basically it is a matter of playing the instrument you are using. Simon ___ 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] udoo board sound issues
dan, no 15 ms is in no way tolerable for live use (if you have effects that should react in realtime) it is of course ok for delay and reverb stuff. the latency from an amp because of cable length and stuff is totally different, since your ear actually hears where the sound comes from and can adapt. but for studio use for example, 15 ms on a headphone is really two attacks for evey attack. heck even 10ms is evil :-) of course your/anyones mileage may vary. but i only wanted the box to output delay and reverb soundscape stuff away, so i might be good. i will add analog circuitry that mixes the dry and effect part of the signal, so i get no (very very little) latency on the unaffected part of the signal. no worries as far as the script goes. i had no problems at all to follow it. but i worked with linux a lot before. i was just suggesting, that the typical ubuntu user would not get some of the steps in between your steps :-) On 15 Mar 2014, at 02:10, Dan Wilcox danomat...@gmail.com wrote: I haven't run any latency tests, so that might be what I'm getting. If so, it's acceptable for what I do. From what I've read, guitar - effects - amp latencies are already closer to 20ms. Sorry I haven't gotten back to the UDOO and pulled the relevant scripts etc off of it yet. I'm trying to get a few things done before I head out of town for work the next 2 weeks. I might be abel to get to it Sunday, but no promises. On Mar 14, 2014, at 8:41 PM, Simon Iten itensi...@gmail.com wrote: hi dan, tried your setup/instructions. thanks, it now works down to 15ms. at 12ms i start to get clicks here and there… your script has some “errors” (missing instructions a novice would not understand how to deal with). do you want me to post them, or do you overdo it anyway? thanks again simon On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote: Thanks. I was just waiting to redo my website, edit the video, put the pics together, etc etc but life and freelance work get in the way. Man, I could use a clone right about now :P On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote: Also interested in the UDOO setup instructions so thank you. A bit OT but, Dan, love your work (that onward to mars patch is awesome) thanks for the links. I think people should post more of this sort of thing to the list, celebrate what we make. =) On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com wrote: FWIW: here's a picture of my UDOO setup inside my Mars space suit backpack: http://www.flickr.com/photos/danomatika/13115604285/ Media of the backpack in use https://twitter.com/danomatika/status/433273394122207232/photo/1 https://vimeo.com/86670103 (not my video, I'll put out a different edit soon) On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote: I will do that later tonight when I boot the udoo and pull my run scripts off of it. I'll post everything to GitHub so we can share resources. On Mar 12, 2014, at 5:44 AM, Jamie Bullock ja...@jamiebullock.com wrote: Hi Dan, Thanks for sharing these notes. They arrived in my inbox to coincide nicely with the delivery of my quad Udoo this morning! It would be great to see a full writeup of your Udoo setup at some point as I think many people will want to be doing a similar thing. All best, Jamie On 11 Mar 2014, at 14:14, Dan Wilcox danomat...@gmail.com wrote: Heres a trim of my notes: Enable realtime audio priority (if you haven't done it already): sudo su -c 'echo @audio - rtprio 99 /etc/security/limits.conf' sudo su -c 'echo @audio - memlock 25 /etc/security/limits.conf' sudo su -c 'echo @audio - nice -10 /etc/security/limits.conf' I disable pulseaudio. Make sure pulseaudio does not respawn itself (from http://voices.canonical.com/david.henningsson/2012/07/13/top-five-wrong-ways-to-fix-your-audio): echo autospawn=no ~/.pulse/client.conf Also add the following to ~/.bash_login to kill pulse audio if it's running on login: # kill pulse audio if it was spawned pulseaudio -k I'm not looking at the udoo run script, but I'm pretty sure I'm using the following with the US-25EX USB soudcard: pd -rt -nogui -alsa -audiodev 5 Use pd -listdev to get the device list from alsa. I chose 5 as the first 4 (from memory) are 1-2 (built in hardware plugin) 2-3 (HDMI audio hardware plugin). 5 is the USB hardware alsa dev. On Mar 11, 2014, at 4:05 AM, Simon Iten itensi...@gmail.com wrote: without jack i should add... On 11 Mar 2014, at 08:55, Simon Iten itensi...@gmail.com wrote: hey dan, unfortunately i’m in switzerland :-) would be great if you could post your setup somewhere or send the infos! i compiled pd from source as well. i start it from console (with -rt) and it works without problems with the builtin sound card. maybe the cheap
Re: [PD] udoo board sound issues
hmm, well to me 12ms is way to much. but then again i play a lot of fast attack notes in up-tempo pieces :-) thanks for your notes anyway, they helped a lot! and write back when you tried with the debian hardfloat image. i tried it for a short time and it was not very stable with pd. but then again i did not try a lot of things to fix this. cheers On 15 Mar 2014, at 13:10, Dan Wilcox danomat...@gmail.com wrote: Check this page: http://www.michalkaszczyszyn.com/en/tutorials/latency.html#acceptable I was wrong, the guitar to amp latency at 1 meter away is roughly 3 ms. The accumulation of a monitors and an effect or two gets you to 8ms. Acceptable latency is 12 ms. Again, I haven't measured my rig or the latency of my old wearable rig, both both were responsive to me, so they must e at least around 12 ms. Sorry for being unscientific about it. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Mar 15, 2014, at 5:49 AM, Simon Iten itensi...@gmail.com wrote: dan, no 15 ms is in no way tolerable for live use (if you have effects that should react in realtime) it is of course ok for delay and reverb stuff. the latency from an amp because of cable length and stuff is totally different, since your ear actually hears where the sound comes from and can adapt. but for studio use for example, 15 ms on a headphone is really two attacks for evey attack. heck even 10ms is evil :-) of course your/anyones mileage may vary. but i only wanted the box to output delay and reverb soundscape stuff away, so i might be good. i will add analog circuitry that mixes the dry and effect part of the signal, so i get no (very very little) latency on the unaffected part of the signal. no worries as far as the script goes. i had no problems at all to follow it. but i worked with linux a lot before. i was just suggesting, that the typical ubuntu user would not get some of the steps in between your steps :-) On 15 Mar 2014, at 02:10, Dan Wilcox danomat...@gmail.com wrote: I haven't run any latency tests, so that might be what I'm getting. If so, it's acceptable for what I do. From what I've read, guitar - effects - amp latencies are already closer to 20ms. Sorry I haven't gotten back to the UDOO and pulled the relevant scripts etc off of it yet. I'm trying to get a few things done before I head out of town for work the next 2 weeks. I might be abel to get to it Sunday, but no promises. On Mar 14, 2014, at 8:41 PM, Simon Iten itensi...@gmail.com wrote: hi dan, tried your setup/instructions. thanks, it now works down to 15ms. at 12ms i start to get clicks here and there… your script has some “errors” (missing instructions a novice would not understand how to deal with). do you want me to post them, or do you overdo it anyway? thanks again simon On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote: Thanks. I was just waiting to redo my website, edit the video, put the pics together, etc etc but life and freelance work get in the way. Man, I could use a clone right about now :P On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote: Also interested in the UDOO setup instructions so thank you. A bit OT but, Dan, love your work (that onward to mars patch is awesome) thanks for the links. I think people should post more of this sort of thing to the list, celebrate what we make. =) On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com wrote: FWIW: here's a picture of my UDOO setup inside my Mars space suit backpack: http://www.flickr.com/photos/danomatika/13115604285/ Media of the backpack in use https://twitter.com/danomatika/status/433273394122207232/photo/1 https://vimeo.com/86670103 (not my video, I'll put out a different edit soon) On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote: I will do that later tonight when I boot the udoo and pull my run scripts off of it. I'll post everything to GitHub so we can share resources. On Mar 12, 2014, at 5:44 AM, Jamie Bullock ja...@jamiebullock.com wrote: Hi Dan, Thanks for sharing these notes. They arrived in my inbox to coincide nicely with the delivery of my quad Udoo this morning! It would be great to see a full writeup of your Udoo setup at some point as I think many people will want to be doing a similar thing. All best, Jamie On 11 Mar 2014, at 14:14, Dan Wilcox danomat...@gmail.com wrote: Heres a trim of my notes: Enable realtime audio priority (if you haven't done it already): sudo su -c 'echo @audio - rtprio 99 /etc/security/limits.conf' sudo su -c 'echo @audio - memlock 25 /etc/security/limits.conf' sudo su -c 'echo @audio - nice -10 /etc/security/limits.conf' I disable pulseaudio. Make sure pulseaudio does not respawn itself (from http://voices.canonical.com/david.henningsson
Re: [PD] udoo board sound issues
hi dan, tried your setup/instructions. thanks, it now works down to 15ms. at 12ms i start to get clicks here and there… your script has some “errors” (missing instructions a novice would not understand how to deal with). do you want me to post them, or do you overdo it anyway? thanks again simon On 13 Mar 2014, at 05:21, Dan Wilcox danomat...@gmail.com wrote: Thanks. I was just waiting to redo my website, edit the video, put the pics together, etc etc but life and freelance work get in the way. Man, I could use a clone right about now :P On Mar 13, 2014, at 12:19 AM, Richie Cyngler glitch...@gmail.com wrote: Also interested in the UDOO setup instructions so thank you. A bit OT but, Dan, love your work (that onward to mars patch is awesome) thanks for the links. I think people should post more of this sort of thing to the list, celebrate what we make. =) On Thu, Mar 13, 2014 at 11:09 AM, Dan Wilcox danomat...@gmail.com wrote: FWIW: here's a picture of my UDOO setup inside my Mars space suit backpack: http://www.flickr.com/photos/danomatika/13115604285/ Media of the backpack in use https://twitter.com/danomatika/status/433273394122207232/photo/1 https://vimeo.com/86670103 (not my video, I'll put out a different edit soon) On Mar 12, 2014, at 10:28 AM, Dan Wilcox danomat...@gmail.com wrote: I will do that later tonight when I boot the udoo and pull my run scripts off of it. I'll post everything to GitHub so we can share resources. On Mar 12, 2014, at 5:44 AM, Jamie Bullock ja...@jamiebullock.com wrote: Hi Dan, Thanks for sharing these notes. They arrived in my inbox to coincide nicely with the delivery of my quad Udoo this morning! It would be great to see a full writeup of your Udoo setup at some point as I think many people will want to be doing a similar thing. All best, Jamie On 11 Mar 2014, at 14:14, Dan Wilcox danomat...@gmail.com wrote: Heres a trim of my notes: Enable realtime audio priority (if you haven't done it already): sudo su -c 'echo @audio - rtprio 99 /etc/security/limits.conf' sudo su -c 'echo @audio - memlock 25 /etc/security/limits.conf' sudo su -c 'echo @audio - nice -10 /etc/security/limits.conf' I disable pulseaudio. Make sure pulseaudio does not respawn itself (from http://voices.canonical.com/david.henningsson/2012/07/13/top-five-wrong-ways-to-fix-your-audio): echo autospawn=no ~/.pulse/client.conf Also add the following to ~/.bash_login to kill pulse audio if it's running on login: # kill pulse audio if it was spawned pulseaudio -k I'm not looking at the udoo run script, but I'm pretty sure I'm using the following with the US-25EX USB soudcard: pd -rt -nogui -alsa -audiodev 5 Use pd -listdev to get the device list from alsa. I chose 5 as the first 4 (from memory) are 1-2 (built in hardware plugin) 2-3 (HDMI audio hardware plugin). 5 is the USB hardware alsa dev. On Mar 11, 2014, at 4:05 AM, Simon Iten itensi...@gmail.com wrote: without jack i should add... On 11 Mar 2014, at 08:55, Simon Iten itensi...@gmail.com wrote: hey dan, unfortunately i’m in switzerland :-) would be great if you could post your setup somewhere or send the infos! i compiled pd from source as well. i start it from console (with -rt) and it works without problems with the builtin sound card. maybe the cheap card from dx.com just does not work properly with udoo. but please post your setup. thanks On 09 Mar 2014, at 22:26, Dan Wilcox danomat...@gmail.com wrote: I've tried my both Roland Edirol UA-25 UA-25EX and both work great. The dedicated USB controller makes these guys work as compared to an RPI where I can't get full duplex without tons of dropouts. I'm using a Linaro install which boots to the console and runs the PD through scripting. The speed is great as compared to my old wearable computer. 4 cores makes a difference. I had to recompile my kernel to add midi support, but that's working great. It's not too bad, actually. I also built Pd-vanilal from source which was pretty easy using ./configure + make. I also have a script which fetches externals and builds/installs the agains vanilla so I have the few externals I need. As with my previous experience running Pd + embedded Ubuntu, I get great performance with RT permissions, the -rt startup flag, and ALSA. Jack is needless overheard unless you want to work with other Jack-enabeld apps. Same with X windows, although my setup was running great in X with pd + ALSA in testing. From your description, it sounds like your main issue is jack pd are probably not running in realtime. I can sent you my install notes if you want (or put them online, as I've been meaning to). Also, are based in the NE within driving distance to Pittsburgh? We could do a patching circle/UDOO setup afternoon :D On Mar 9, 2014, at 5:14 PM, pd-list-requ
Re: [PD] udoo board sound issues
hey dan, unfortunately i’m in switzerland :-) would be great if you could post your setup somewhere or send the infos! i compiled pd from source as well. i start it from console (with -rt) and it works without problems with the builtin sound card. maybe the cheap card from dx.com just does not work properly with udoo. but please post your setup. thanks On 09 Mar 2014, at 22:26, Dan Wilcox danomat...@gmail.com wrote: I've tried my both Roland Edirol UA-25 UA-25EX and both work great. The dedicated USB controller makes these guys work as compared to an RPI where I can't get full duplex without tons of dropouts. I'm using a Linaro install which boots to the console and runs the PD through scripting. The speed is great as compared to my old wearable computer. 4 cores makes a difference. I had to recompile my kernel to add midi support, but that's working great. It's not too bad, actually. I also built Pd-vanilal from source which was pretty easy using ./configure + make. I also have a script which fetches externals and builds/installs the agains vanilla so I have the few externals I need. As with my previous experience running Pd + embedded Ubuntu, I get great performance with RT permissions, the -rt startup flag, and ALSA. Jack is needless overheard unless you want to work with other Jack-enabeld apps. Same with X windows, although my setup was running great in X with pd + ALSA in testing. From your description, it sounds like your main issue is jack pd are probably not running in realtime. I can sent you my install notes if you want (or put them online, as I've been meaning to). Also, are based in the NE within driving distance to Pittsburgh? We could do a patching circle/UDOO setup afternoon :D On Mar 9, 2014, at 5:14 PM, pd-list-requ...@iem.at wrote: From: Miller Puckette m...@ucsd.edu Subject: Re: [PD] udoo board sound issues Date: March 9, 2014 at 5:07:54 PM EDT To: Simon Iten itensi...@gmail.com Cc: PD list pd-list@iem.at H iSimon - I haven't tried any but the built-in yet but I have a few USB interfaces around here that I can try. I'm about to go on an intense trip but should be able to do some tests when I get back, assuming nobody else has figured this out first. cheers Miller On Sun, Mar 09, 2014 at 09:57:45PM +0100, Simon Iten wrote: hey list, does anybody that uses an udoo board have any recommendations on a usb-soundcard? should be very compact. i tried a cheap one from dx and i could not get any good results (loads of xruns even with periods 3 and 1024 and up frames in qjackctl) this is on the ubuntu version from udoo. are there some tweaks i can do to improve usb-sound capabilities? i thought maybe recompile the kernel with only usb-1 support since there is no option as on the pi to disable usb-2 via config, or am i missing something? is it better to use the usb-soundcard without jack (pd does not like the usb-soundcard either when i tried briefly)? the internal sound-input is to noisy for my application (guitar effect) cheers. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] udoo board sound issues
without jack i should add... On 11 Mar 2014, at 08:55, Simon Iten itensi...@gmail.com wrote: hey dan, unfortunately i’m in switzerland :-) would be great if you could post your setup somewhere or send the infos! i compiled pd from source as well. i start it from console (with -rt) and it works without problems with the builtin sound card. maybe the cheap card from dx.com just does not work properly with udoo. but please post your setup. thanks On 09 Mar 2014, at 22:26, Dan Wilcox danomat...@gmail.com wrote: I've tried my both Roland Edirol UA-25 UA-25EX and both work great. The dedicated USB controller makes these guys work as compared to an RPI where I can't get full duplex without tons of dropouts. I'm using a Linaro install which boots to the console and runs the PD through scripting. The speed is great as compared to my old wearable computer. 4 cores makes a difference. I had to recompile my kernel to add midi support, but that's working great. It's not too bad, actually. I also built Pd-vanilal from source which was pretty easy using ./configure + make. I also have a script which fetches externals and builds/installs the agains vanilla so I have the few externals I need. As with my previous experience running Pd + embedded Ubuntu, I get great performance with RT permissions, the -rt startup flag, and ALSA. Jack is needless overheard unless you want to work with other Jack-enabeld apps. Same with X windows, although my setup was running great in X with pd + ALSA in testing. From your description, it sounds like your main issue is jack pd are probably not running in realtime. I can sent you my install notes if you want (or put them online, as I've been meaning to). Also, are based in the NE within driving distance to Pittsburgh? We could do a patching circle/UDOO setup afternoon :D On Mar 9, 2014, at 5:14 PM, pd-list-requ...@iem.at wrote: From: Miller Puckette m...@ucsd.edu Subject: Re: [PD] udoo board sound issues Date: March 9, 2014 at 5:07:54 PM EDT To: Simon Iten itensi...@gmail.com Cc: PD list pd-list@iem.at H iSimon - I haven't tried any but the built-in yet but I have a few USB interfaces around here that I can try. I'm about to go on an intense trip but should be able to do some tests when I get back, assuming nobody else has figured this out first. cheers Miller On Sun, Mar 09, 2014 at 09:57:45PM +0100, Simon Iten wrote: hey list, does anybody that uses an udoo board have any recommendations on a usb-soundcard? should be very compact. i tried a cheap one from dx and i could not get any good results (loads of xruns even with periods 3 and 1024 and up frames in qjackctl) this is on the ubuntu version from udoo. are there some tweaks i can do to improve usb-sound capabilities? i thought maybe recompile the kernel with only usb-1 support since there is no option as on the pi to disable usb-2 via config, or am i missing something? is it better to use the usb-soundcard without jack (pd does not like the usb-soundcard either when i tried briefly)? the internal sound-input is to noisy for my application (guitar effect) cheers. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] udoo board sound issues
hey list, does anybody that uses an udoo board have any recommendations on a usb-soundcard? should be very compact. i tried a cheap one from dx and i could not get any good results (loads of xruns even with periods 3 and 1024 and up frames in qjackctl) this is on the ubuntu version from udoo. are there some tweaks i can do to improve usb-sound capabilities? i thought maybe recompile the kernel with only usb-1 support since there is no option as on the pi to disable usb-2 via config, or am i missing something? is it better to use the usb-soundcard without jack (pd does not like the usb-soundcard either when i tried briefly)? the internal sound-input is to noisy for my application (guitar effect) cheers. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] udoo board sound issues
hi miller fantastic, thanks On 09 Mar 2014, at 22:07, Miller Puckette m...@ucsd.edu wrote: H iSimon - I haven't tried any but the built-in yet but I have a few USB interfaces around here that I can try. I'm about to go on an intense trip but should be able to do some tests when I get back, assuming nobody else has figured this out first. cheers Miller On Sun, Mar 09, 2014 at 09:57:45PM +0100, Simon Iten wrote: hey list, does anybody that uses an udoo board have any recommendations on a usb-soundcard? should be very compact. i tried a cheap one from dx and i could not get any good results (loads of xruns even with periods 3 and 1024 and up frames in qjackctl) this is on the ubuntu version from udoo. are there some tweaks i can do to improve usb-sound capabilities? i thought maybe recompile the kernel with only usb-1 support since there is no option as on the pi to disable usb-2 via config, or am i missing something? is it better to use the usb-soundcard without jack (pd does not like the usb-soundcard either when i tried briefly)? the internal sound-input is to noisy for my application (guitar effect) cheers. ___ 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] mac os9 version
i think there was…at least according to the wiki of tcl/tk here for example: http://wiki.tcl.tk/12987 cheers On 26 Feb 2014, at 17:29, Miller Puckette m...@ucsd.edu wrote: Hi al - As far as I know there was never any version of Pd for Mac OS9 - the stumbling block (as I recall perhaps imperfectly) was that Tcl/Tk wasn't available for it. cheers Miller On Wed, Feb 26, 2014 at 09:21:05AM +0100, Jean-Marie Adrien wrote: pd vintage edition the true pure root thing ! :) Le 26 févr. 2014 à 08:40, Simon Iten a écrit : too bad, thanks. On 25 Feb 2014, at 16:19, Peter P. p8...@aol.com wrote: * Simon Iten itensi...@gmail.com [2014-02-25 14:31]: is there or better was there ever a version of pure data for mac os9? the bits i find on the net seem to indicate no. but maybe a call here will reveal a version. (miller?) The only thing I have ever seen was GEM for Max under OS9. best, P ___ 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] mac os9 version
is there or better was there ever a version of pure data for mac os9? the bits i find on the net seem to indicate no. but maybe a call here will reveal a version. (miller?) thanks ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mac os9 version
too bad, thanks. On 25 Feb 2014, at 16:19, Peter P. p8...@aol.com wrote: * Simon Iten itensi...@gmail.com [2014-02-25 14:31]: is there or better was there ever a version of pure data for mac os9? the bits i find on the net seem to indicate no. but maybe a call here will reveal a version. (miller?) The only thing I have ever seen was GEM for Max under OS9. best, P ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] check this out
https://getmyo.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [helmholtz~]
hi phil, what are you trying to do? do you need midi from your electric bass? or just a way to make a synth in pd? i ask because i built a gr-300 emulation for bass that works very well and with almost no latency. you can drive any oscillator within pd from that. it's all signalpath though. ideally you would use such a thing with a hexaphonic (or quadraphonic) pickup, because it's monophonic. but the same is true for helmholtz i guess. cheers, simon On Feb 14, 2013, at 1:24 AM, Phil Stone pkst...@ucdavis.edu wrote: Hi Katja, I'm looking with great interest at your [helmholtz~] pitch tracking object. I'm not asking to be lazy (I'm going to try it out for myself!), but I'm wondering if you have any general impressions of its performance as to how it compares with [sigmund~]. I'm particularly interested as to how it will do for tracking a fretless electric bass. It looks like an excellent piece of work, and I've enjoyed reading your detailed page about it. Phil Stone ___ 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] [helmholtz~]
I'm not home at the moment but I will send you the snippet I used for pitch tracking when I get home. Have a nice day On Feb 14, 2013 5:13 PM, Phil Stone pkst...@ucdavis.edu wrote: Hi Simon, I've been using [sigmund~] with pretty good results, tracking the bass and using it to drive various things in a complex Pd setup. I'm always interested in alternative pitch trackers, though. I play a Steinberger XL, so I won't likely be carving it up to put in a hex pickup; that's kept me a way from Roland's approach (that plus the cost!). I'm still quite intrigued by what you've done; do you have any documentation about it? Thanks for writing, Phil On 2/14/13 12:48 AM, Simon Iten wrote: hi phil, what are you trying to do? do you need midi from your electric bass? or just a way to make a synth in pd? i ask because i built a gr-300 emulation for bass that works very well and with almost no latency. you can drive any oscillator within pd from that. it's all signalpath though. ideally you would use such a thing with a hexaphonic (or quadraphonic) pickup, because it's monophonic. but the same is true for helmholtz i guess. cheers, simon On Feb 14, 2013, at 1:24 AM, Phil Stone pkst...@ucdavis.edu wrote: Hi Katja, I'm looking with great interest at your [helmholtz~] pitch tracking object. I'm not asking to be lazy (I'm going to try it out for myself!), but I'm wondering if you have any general impressions of its performance as to how it compares with [sigmund~]. I'm particularly interested as to how it will do for tracking a fretless electric bass. It looks like an excellent piece of work, and I've enjoyed reading your detailed page about it. Phil Stone __**_ 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] Message from the boss of Raspberry Pi Foundation !
pierre wrote in his blog that he can go as low as 10ms, later in the settings he writes about 16ms. On Feb 8, 2013, at 1:57 PM, i go bananas hard@gmail.com wrote: sorry, i don't think this is the thread i should be asking this in, but how low latency can you get with pd on a pi ? ___ 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] Max's [rate~] implementation...
What are you trying to accomplish? On Dec 6, 2012 2:48 PM, Alexandros Drymonitis adr...@gmail.com wrote: How can one implement Max's [rate~] in Pd? [rate~] takes a signal from a [phasor~] and according to its argument it scales the frequency (roughly speaking). So [phasor~ 1] | [rate~ 1.5] will actually give a [phasor~ 1.5]. I thought of [wrap] but that won't do the trick with non-integers. Any ideas? ___ 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] firm delay scheduling
If you have a multicore machine you should be fine...
On Oct 31, 2012 12:31 AM, Jonathan Wilkes jancs...@yahoo.com wrote:
- Original Message -
From: Cyrille Henry c...@chnry.net
To: pd-list@iem.at
Cc:
Sent: Tuesday, October 30, 2012 1:52 PM
Subject: Re: [PD] firm delay scheduling
hello,
if your problem is detecting when cpu is over 100% so that delay is not
acurate,
then the best solution is some kind of external watchdog.
just send a message every 10 ms to an other software, if this external
software
did not receive anything during the last 20ms, then there is a cpu
problem on
the pd side...
the external software can be an other pd, a shell script (using
pdreceive, or
anything else.
How is the second pd going to complete its computations on time when the
CPU
is over 100%?
cheers
c
Le 30/10/2012 18:13, Jean-Marie Adrien a écrit :
Hello
I'm trying to launch security procedures in case of trouble, that will
respond in less than 250 msec.
The fundamental question is :
Is there an object to schedule an event in the future with firm
absolute
delay ?
{realtime} measures time AFTER the problem (no scheduling)
{del} schedules things but the delay is kind of elastic, depending on
the
CPU load.
thanks
JM
___
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] Stream phone call to pd?
I think the obvious way to do this is to hack a Bluetooth headset. You could attach the headset with cables to an existing audiointerface... The user just connects to a regular headset. On Oct 29, 2012 12:56 PM, 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 ___ 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] Question on getting the amount of values in a table and setting table to zero
Check william brent's tabletool On Oct 4, 2012 5:50 PM, Rick T ratull...@gmail.com wrote: Greetings All 1) I'm trying to find a way to get the total amount of values in a table. I found arraysize but that doesn't seem to give me the correct output Example: If I create a table with ; arrayx 0 .1 .3 .5 .3 .1 I'm trying to get the output to be 5 since there are 5 values in it. 2) I'm also trying to set all values in array to zero with out having to zero each index. Example If I create a table with ; arrayx 0 .1 .3 .5 .3 .1 is there an option to set all indexes values back to zero (or set the entire array back to zero) without creating another object like this; arrayx 0 0 0 0 0 0 Thanks Rick PS: I'm using ubuntu 10.04 64bit pd .42.5 extended ___ 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] attackless guitar synth :-)
hey pierre, maybe something for your blog? it's a very simple patch based on dryUP~ by william brent. i misused his object to get only the predicted part which sounds really nice. a lot like the pog without attack and octaver :-) i attached a version of the external for 32-bit linux. if you run mac or windows you can find compiled versions on his site. check it out cheers simon dryupguitar.tar.gz Description: GNU Zip compressed data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] instantaneous pitch follower
Patrick, I will post it at some point. However it is not finished yet and the gui not very intuitive atm. The filter part is very easy, the important part is that you get a separate signal from each string with a divided pickup...and then you need one of these patches for every string. Cheers On Aug 29, 2012 3:04 PM, patrick pured...@11h11.com wrote: hi simon, first of all thanks for sharing this patch. i would like to know if you could share also the patch that you are using for your doublebass? i am not sure i understand the filter part. also any audio demo? cheers __**_ 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
[PD] instantaneous pitch follower
hi list, i found a way to get the pitch from a signal without any analyzing. it's a side effect of a gr-300 patch i've worked on in my spare time. maybe this is very obvious but for me this is great!! also note that i'm a musician, so sorry for any mistakes. it tracks with almost no latency and outputs pitch continuously. it all happens in the signal domain. if the pitch changes the follower ramps to the new pitch. so if you play fast notes you get some smearing. sounds worse than it is (aka sounds) to my ears :-) this works great on my double-bass and i just wanted to share. it's very simple and far from perfect. try it out and let me know! simon pitchfollower.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gr-300 simulation (guitar/bass synthesizer)
hey, i am having some troubles with my computer at the moment (expresscard port not working) which makes it impossible to use my soundcard. therefore the audio samples have to wait for now. the synth is coming along very nice though. i'll keep you updated. simon On Jul 31, 2012, at 12:45 AM, Tyler Leavitt wrote: How about some audio examples? I don know when I will get around to getting 6 inputs for my guitar =) Tyler On Thu, Jul 19, 2012 at 12:00 PM, Pierre Massat pimas...@gmail.com wrote: Cool, thanks for sharing ! I'll try it next week when I have time and will give you some feedback. Cheers! Pierre. 2012/7/18 Simon Iten itensi...@gmail.com some of you asked me to post this when it's finished. well it's not but it works extremely well on my setup! you need an output from each string of your instrument and feed that into pd. i use it with a 5-string doublebass but i guess you can easily adapt it for 6-string guitar or violin or whatever :-) you want to play with the bp~ object in each string subpatch and adjust it to the frequency of the respective open string. i am honestly quite surprised that this thing works so great. tracking with almost no latency down to the open e :-) and it even tracks flageoletts... if anyone cares to try, go ahead. i guess you can also try it with just a monophonic guitar input. the filter part will not work that great though :-) thanks for the help claude heiland-allen! cheers, simon ___ 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] 2009-2010 Macbook Pro 2.2GHz Latency?
Well from a musicians point of view (me) everything above 8ms is not very playable. This is obvioulsy only true if the generated sound has instant attack, otherwise latency does not really matter :-) On Jul 27, 2012 2:30 PM, Charles Henry czhe...@gmail.com wrote: On Thu, Jul 26, 2012 at 8:50 PM, Tyler Leavitt thecryofl...@gmail.com wrote: 10ms is around the human-ear latency, so anything at that level or below should be good enough for guitar/drumming (this is anectodtal... Iḿ not sure the exact science behind it). Ive never had a problem with my friends older 13 MacBook Pro used as a guitar FX box. Tyler I believe the phenomenon you're describing is called loudness integration. However, I can't find any good citations available on the internet to back it up--here's something that *might* be applicable: Plack, C. J., Moore, B. C. J. (1990). Temporal window shape as a function of frequency and level. Journal of the Acoustical Society of America, 87, 2178–2187. The basic idea is that the cochlea is fed a series of waves and a particular place on the basilar membrane resonates most for a given frequency. The instantaneous power delivered is low, so the power needs to accumulate before the stimulus is strong enough to be perceived. As I recall, it takes about 20 ms to reach a steady state, but it's been a while since I've read anything about it. Chuck ___ 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] 2009-2010 Macbook Pro 2.2GHz Latency?
On Jul 27, 2012 6:19 PM, wrote: ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] +=~ object for pd
Sure! The thing is though that i'm going for the real thing here. :-) so in order to use my patch you have to have audio output from each string of your guitar. no midi. i do this by using an active breakout box from bill baxendale. check: http://billbax.110mb.com/ cheers, simon On Jul 17, 2012, at 9:19 AM, Dan Wilcox wrote: Yeah, let us know when you got it working ... I'd like to see and perhaps try with my midi guitar. On Jul 17, 2012, at 2:58 AM, Pierre Massat wrote: Hi, I'm interested in everything related to guitar sound processing, and I write a blog to share guitar effect patches. Would you be willing to share some of your work with us? Cheers, Pierre. 2012/7/17 Simon Iten itensi...@gmail.com PERFECT!! that did the trick! now i'm one step closer to my gr-300 simulation :-) thanks! On Jul 17, 2012, at 12:59 AM, Claude Heiland-Allen wrote: On 16/07/12 22:26, Simon Iten wrote: [+=~] the object adds all the values it receives and can be reset with a signal (in my case a pulse) is there an equivalent in pd? i can't seem to find one. [rpole~] right inlet 0 to reset right inlet 1 to accumulate ___ 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 Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] +=~ object for pd
hi list, i have a hard time getting a max patch ported to pd. the one object in max that bugs me is a signal accumulator. [+=~] the object adds all the values it receives and can be reset with a signal (in my case a pulse) is there an equivalent in pd? i can't seem to find one. i try to create some kind of ramped up signal that gets reset everytime a pulse arrives. this gives me a sawtooth-like wave, the amplitude is determined by the frequency of the pulse. lower frequency of the pulse gives higher amplitude and vice versa. the important part is, that everything has to be done at signal rate, no messages :-) here is how it looks and works in max/msp: [sig~ 1] pulsesignal \/ [+=~] | [/~ 44100] (divided by current samplerate) | sawtooth with amplitude depending on frequency of the pulse is there a way to achieve this without the signal accumulator object? i feel like there should be an easy solution but i can't seem to find it. any hints? thanks, simon___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] +=~ object for pd
this seems like a great approach. thanks! my only concern is, that there will be nothing fast enough to detect my 30-1200 pulses per second... and i also don't think bangs can be sent that precisely, or can they? On Jul 17, 2012, at 12:13 AM, Funs Seelen wrote: Hi Simon, On Mon, Jul 16, 2012 at 11:26 PM, Simon Iten itensi...@gmail.com wrote: is there a way to achieve this without the signal accumulator object? i feel like there should be an easy solution but i can't seem to find it. any hints? If you mean the following, where x is the input and y the output.. y += x; and that for each sample.. then [biquad~] might be a solution: [sig~ 1] | | [clear( | / [biquad~ 1 0 1 0 0] | This adds the last output to the current input. The [clear( message resets biquad~ to 0. Now you just have to find a method to translate your pulse to a bang. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] +=~ object for pd
PERFECT!! that did the trick! now i'm one step closer to my gr-300 simulation :-) thanks! On Jul 17, 2012, at 12:59 AM, Claude Heiland-Allen wrote: On 16/07/12 22:26, Simon Iten wrote: [+=~] the object adds all the values it receives and can be reset with a signal (in my case a pulse) is there an equivalent in pd? i can't seem to find one. [rpole~] right inlet 0 to reset right inlet 1 to accumulate ___ 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] Problem with HID in Ubuntu
look into udev permissions, you have to make a rule for your device. i don't remember exactly how to do it, but there should be plenty of instructions on the ubuntu forum. On Sat, 2010-01-16 at 13:50 +0100, Pierre Massat wrote: Hi , I having trouble using [hid] in Ubuntu 8.04. Pd doesn't seem to have access to input devices, unless i launch it with sudo. When i do a print with [hid], i don't get any device listed if i run Pd normally. I think this has to do with the access rights that ubuntu grants to applications, but i have no idea how i can fix that. Any suggestion? Thanks! 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] Virtual keyboard
yes yes yes there is a very simple software-midikeyboard, it's called vkeybd. i always connect midi things via alsa in linux. that means you have to set midi to alsa in puredata and then use a software like alsa patchbay to connect the vkeybd to puredata. if you use the excellent jack for audio, you probably use qjackctl to set things up, qjackctl has a alsa patchbay tab as well. hope this helps On Fri, 2010-01-15 at 04:28 +0100, meino.cra...@gmx.de wrote: Hi, (I am using a recent version of Gentoo-Linux) ...again a very newbish question: Since I have no midi-hardware I like to know whether there is some software-keyboard which sends midi signals and which I can connect to PureData? And -- if yes -- how can I connect it to PureData? Thank you very much in advance for any help! Have a nice weekend! Best regards, mcc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Advice on how to handle latency in linux with Pd, jack and ardour
i asked about this issue on the ardour forum and paul davis (the main developer of ardour) gave this answer: All JACK clients can report latency on their ports. Pd is not reporting latency correctly on its JACK ports. If it did, the result of the send via Pd would still be aligned correctly. To correct this you need to use an artificial latency plugin (in the SWH plugin set) to fake the latency that Pd is adding. There's no way to know what the number is so you just have to play with it until ardour does the right thing. Oh, and you need to know one other thing: Ardour only does latency updates at each transport stop, so you need to adjust/stop/roll/adjust/stop as necessary. furthermore, there seems to be latency correction for other jack apps, if they report it. hope this helps. is the jack implementation in pd reporting the latency? On Tue, 2009-12-22 at 17:23 -0300, Simon Iten wrote: thanks for the clarification. i'll ask about the latency correction for jack-clients in the ardour forum. lately there have been some jack plugins around (linuxdsp) so there would be a need for this there as well. On Tue, 2009-12-22 at 11:41 -0800, Justin Glenn Smith wrote: Jack cannot automatically know that PD is reading from jack and then sending back to re-record. Because of how jack is designed, there is an inevitable and predictable delay there - determined by jack, not by pd. This has been brought up, ardour already automatically compensates for ladspa plugin latency when it has the proper information, so the infrastructure is theoretically there (ideally they could add a one jack period worth of latency correction toggle to the UI for each track). Simon Iten wrote: afaik all the latency introduced by jack is automatically corrected by ardour. so the latency you observe when rerecording in ardour comes from puredata only. there's not much you can do about this, except optimizing your patch. i'm not aware of any manual latency correction in ardour, but maybe i'm wrong, you should ask this on the ardour forum. you could start your sourceaudio with a short and loud click sound, that way it's easier to align later... regards, simon On Thu, 2009-12-03 at 11:50 +0100, Lorenzo wrote: I've been lately messing around with a fairly straight forward configuration sending audio from ardour to Pd's adc~ (through jack) and back to ardour via MIDI (for controlling automations) or audio (trivially re-recording Pd's dac~ output). In the case of MIDI latency seems no perceptible problem. In the case of audio, where the audio is of course 'processed' in the Pd patch and eventually 'goes back' to ardour, there is latency. This of course is expected for the nature itself of jack, what I'd like to know at this stage is not how to remove latency but the best way(s) to handle it (possibly even through raising the latency itself, as for the moment I'm not doing real-time), for example if there were some way to compensate it automatically (or at least in some 'smart' way). At the moment the best solution is to manually re-align the slightly delayed audio. Any input welcome. Kind regards, Lorenzo. ___ 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] Advice on how to handle latency in linux with Pd, jack and ardour
afaik all the latency introduced by jack is automatically corrected by ardour. so the latency you observe when rerecording in ardour comes from puredata only. there's not much you can do about this, except optimizing your patch. i'm not aware of any manual latency correction in ardour, but maybe i'm wrong, you should ask this on the ardour forum. you could start your sourceaudio with a short and loud click sound, that way it's easier to align later... regards, simon On Thu, 2009-12-03 at 11:50 +0100, Lorenzo wrote: I've been lately messing around with a fairly straight forward configuration sending audio from ardour to Pd's adc~ (through jack) and back to ardour via MIDI (for controlling automations) or audio (trivially re-recording Pd's dac~ output). In the case of MIDI latency seems no perceptible problem. In the case of audio, where the audio is of course 'processed' in the Pd patch and eventually 'goes back' to ardour, there is latency. This of course is expected for the nature itself of jack, what I'd like to know at this stage is not how to remove latency but the best way(s) to handle it (possibly even through raising the latency itself, as for the moment I'm not doing real-time), for example if there were some way to compensate it automatically (or at least in some 'smart' way). At the moment the best solution is to manually re-align the slightly delayed audio. Any input welcome. Kind regards, Lorenzo. ___ 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] Advice on how to handle latency in linux with Pd, jack and ardour
thanks for the clarification. i'll ask about the latency correction for jack-clients in the ardour forum. lately there have been some jack plugins around (linuxdsp) so there would be a need for this there as well. On Tue, 2009-12-22 at 11:41 -0800, Justin Glenn Smith wrote: Jack cannot automatically know that PD is reading from jack and then sending back to re-record. Because of how jack is designed, there is an inevitable and predictable delay there - determined by jack, not by pd. This has been brought up, ardour already automatically compensates for ladspa plugin latency when it has the proper information, so the infrastructure is theoretically there (ideally they could add a one jack period worth of latency correction toggle to the UI for each track). Simon Iten wrote: afaik all the latency introduced by jack is automatically corrected by ardour. so the latency you observe when rerecording in ardour comes from puredata only. there's not much you can do about this, except optimizing your patch. i'm not aware of any manual latency correction in ardour, but maybe i'm wrong, you should ask this on the ardour forum. you could start your sourceaudio with a short and loud click sound, that way it's easier to align later... regards, simon On Thu, 2009-12-03 at 11:50 +0100, Lorenzo wrote: I've been lately messing around with a fairly straight forward configuration sending audio from ardour to Pd's adc~ (through jack) and back to ardour via MIDI (for controlling automations) or audio (trivially re-recording Pd's dac~ output). In the case of MIDI latency seems no perceptible problem. In the case of audio, where the audio is of course 'processed' in the Pd patch and eventually 'goes back' to ardour, there is latency. This of course is expected for the nature itself of jack, what I'd like to know at this stage is not how to remove latency but the best way(s) to handle it (possibly even through raising the latency itself, as for the moment I'm not doing real-time), for example if there were some way to compensate it automatically (or at least in some 'smart' way). At the moment the best solution is to manually re-align the slightly delayed audio. Any input welcome. Kind regards, Lorenzo. ___ 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] help patch for sigmund object
hi list, could somebody post the pd help patch for sigmund~ ? i can't find it on my system... thanks in advance, simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] help patch for sigmund object
thanks! it wasn't there... On Sat, 2009-12-12 at 20:17 +0100, ypatios wrote: #N canvas 167 -7 580 617 12; #X text 42 4 sigmund~ - sinusoidal analysis and pitch tracking; #N canvas 432 117 573 597 using-with-tables 0; #X obj 29 368 print peak; #N canvas 0 0 450 300 (subpatch) 0; #X array insignal 1024 float 2; #X coords 0 1 1023 -1 200 140 1; #X restore 83 426 graph; #X obj 314 513 phasor~; #X obj 294 429 loadbang; #X obj 314 461 440; #X floatatom 313 488 5 0 0 0 - - -; #X obj 305 544 tabwrite~ insignal; #X obj 290 516 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 114 11 Using sigmund~ on arrays; #X text 42 33 If invoked with the -t flag (as a creation argument) \, sigmund~ analyzes waveforms stored in arrays. Instead of an incoming signal \, feed it list messages with the following arguments:; #X text 37 118 table name (a symbol); #X text 38 137 number of points; #X obj 29 342 sigmund~ -t -npeak 10 -maxfreq 5000 peaks; #X msg 29 316 list insignal 1024 0 44100 0; #X text 37 158 index of first point; #X text 39 179 sample rate; #X text 38 200 debug flag (print debugging info if nonzero); #X text 23 232 In this mode \, only the env \, pitch \, and peaks outputs are meaningful.; #X text 31 294 click here to test:; #X connect 2 0 6 0; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 5 0 2 0; #X connect 5 0 7 0; #X connect 7 0 6 0; #X connect 12 0 0 0; #X connect 13 0 12 0; #X restore 330 553 pd using-with-tables; #X obj 40 512 phasor~; #X obj 40 425 loadbang; #X floatatom 40 471 5 0 120 0 - - -; #X floatatom 39 561 5 0 0 0 - - -; #X floatatom 245 563 5 0 0 0 - - -; #X obj 40 490 mtof; #X obj 40 448 69; #X text 38 579 pitch; #X text 222 582 envelope; #X text 13 28 Sigmund~ analyzes an incoming sound into sinusoidal components \, which may be reported individually or combined to form a pitch estimate. Possible outputs are specified as creation arguments:; #X text 56 95 pitch - output pitch continuously; #N canvas 518 74 588 728 setting-parameters 0; #X msg 182 66 print; #X floatatom 192 92 5 0 0 0 - - -; #X msg 192 113 minpower \$1; #X obj 182 139 sigmund~ -minpower 40; #X text 39 14 You can set parameters either by creation arguments \, or else using messages. The print message gives you the current values of all the parameters:; #X text 28 169 npts: number of points used in an analysis. Must be a power of two \, at least 128 The minimum frequency that can be tracked is about 2(sample_rate)/npts.; #X text 26 219 hop: number of points between analyses. Must be a power of two \, at least the DSP vector size (usually 64). This regulates the number of analyses done per unit of time.; #X text 28 271 npeak: maximum number of sinusoidal peaks to look for. The computation time is quadratic in the number of peaks actually found (this number only sets an upper limit). Use it to balance CPU time with quality of results.; #X text 30 336 maxfreq: maximum frequency of sinusoidal peaks to look for. This can be useful in situations where background noise creates high-frequency \, spurious peaks..; #X text 37 388 vibrato: maximum deviation from pitch to accept as normal vibrato (affects notes output only). If the value is too small. vibratos will appear as trills. If too large \, very small melodic intervals may not be reported as new notes.; #X text 33 457 stabletime: time period to wait before reporting a note (affects notes output only). The pitch must be present and must not vary more than vibrato for this entire period to report a note. If too large \, the notes will be unnecessarily delayed. If too small \, spurious notes get output.; #X text 31 551 minpower: minimum measured RMS level to report a pitch (affects pitch and notes output only). Signals quieter than this will be assumed to be crosstalk and ignored.; #X text 32 602 growth: minimum measured RMS growth to report a new note (affects notes output only). The RMS level must rise by this many dB (within a time period given by stabletime) to report a repetition of a note at or near the previously output pitch.; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X restore 330 531 pd setting-parameters; #N canvas 67 29 641 815 sinusoid-tracking 0; #X obj 124 267 sigmund~ -npeak 10 peaks; #X obj 124 214 phasor~; #X obj 124 144 loadbang; #X floatatom 124 190 5 0 120 0 - - -; #X obj 124 295 route 0 1 2 3 4 5 6 7 8 9; #X obj 82 339 unpack 0 0 0 0; #X floatatom 82 461 5 0 0 0 - - -; #X floatatom 122 431 5 0 0 0 - - -; #X floatatom 162 406 5 0 0 0 - - -; #X obj 124 167 440; #X floatatom 203 380 5 0 0 0 - - -; #X obj 322 349 unpack 0 0 0 0; #X floatatom 322 471 5 0 0 0 - - -; #X floatatom 362 441 5 0 0 0 - - -; #X floatatom 402 416 5 0 0 0 - - -; #X floatatom 443 390 5 0 0 0 - - -; #X text 385 475 frequency (Hz.); #X text 419 442 peak amplitude (linear); #X text 464 416 cosine component; #X text 499 390 sine component;
Re: [PD] noteout issue
the way i understood midi, is that you can't have to events going on at the same time, since it is a stream, i might be wrong though. maybe the windows version of noteout (or the windows midi driver) does some ordering, that the linux one doesn't. if you add a delay 1 object to one of the messages, that should solve the problem without audible differences. hope this helps simon On Wed, 2009-12-02 at 18:58 +, Silvio Almeida wrote: Hi list, Probably not a 'pure' puredata issue but: [bang( | \ [36 100( [40 100( | / | / (both to inlet one) [noteout 10] triggers : - only one of the two notes (Linux Debian 5/Ubuntu 9.10) - two notes simultaneasly (Windows XP) i suspect it is something on the midi settings of alsa or something. thanks in advance. Sílvio Almeida __ Mantenha os seus amigos actualizados - mesmo quando não tem sessão iniciada. ___ 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
