Re: [PD] latency solutions... and then some
Unnoticeable latency usually refers to the musician not noticing the difference in time between when they press the key and when the sound comes out. Any time you add a delayed signal to the original signal, you will notice it. The slap-back happens at longer latencies, but at shorter latencies you will hear *very* noticeable comb-filtering. And since no computer-based solution is latency-free, I think you need to re-examine what you are expecting Pd to do. Either that, or go with a dedicated DSP board (and learn the accompanying programming!) which would give you a more guitar-pedal-like zero-latency system. Maybe Marco Donnarumma could give a few words here on processing instruments live. His set uses an electric bass through Pd. My guess is that even the un-processed signal goes through Pd to avoid echos or comb filtering due to latency. Best, Derek Jeffrey Concepcion wrote: * in terms of processor capacity, hardware, and sound card configuration, what would be the minimum requirements to achieve unnoticeable latency (not hear the affected signal as a slap-back type of effect)? i've read that 11ms can be achieved and is unnoticeable. -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 18: Balance the consistency principle with the inconsistency principle ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Floats and negative numbers over OSC
Hi Martin, Thank you for your response. I am attaching the patch used to produce the following results. This was tested on Pd version 0.41.4-extended, running on WinXP SP3. The OSC data were sent by GlovePIE running the following code. --- SendOSC(127.0.0.1, 9997, /test, 0) wait 1 second SendOSC(127.0.0.1, 9997, /test, 1.5) wait 1 second SendOSC(127.0.0.1, 9997, /test, -1) wait 1 second --- I was expecting [routeOSC] to output 0, 1.5, -1. --- Output --- raw: 47 116 101 115 116 0 0 0 44 105 0 0 0 0 0 0 unpacked: /test 0 routed: 0 raw: 47 116 101 115 116 0 0 0 44 102 0 0 63 63 0 0 unpacked: /test 0.746094 routed: 0.746094 raw: 47 116 101 115 116 0 0 0 44 105 0 0 63 63 63 63 unpacked: /test 1.06111e+009 routed: 1.06111e+009 Thank you again for your help. -- David Shimamoto PSPunch wrote: Hi Calude, I don't know if mrpeach osc and net objects work on Windows, but if they do they should be preferred to the OSCx objects. (snip) OSCx library is old, buggy, unmaintained, broken I've tried the two libraries prior to my post. They both work well on Windows to the extent that I saw neither having disadvantages over the other. A problem I see commonly among the two mentioned sets of libraries is that they output incorrect values when receiving float or negatives. Integers and zero are fine. Recent versions of [packOSC] and [unpackOSC] should work properly. If not, please post some examples. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list routeOSC-test.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] latency solutions... and then some
Hi Jeffrey! I ve been trying to minimize latency in Pd for a year now, experimenting with various OS and hardware. I m using Pd for the same purpose, that is live processing of electric instruments (mainly a guitar). I would recommend using a Linux distro, because they have realtime kernels, and the JACK server, plus you can get the hid object in Pd (which does not exist on windows). If you want to play live you want to go for latencies below 7 or 6 ms. I get a 5 ms latency on an old Dell laptop (1 Ghz) with the latest Fedora with the CCRMA realtime kernel. I can also give you a couple of hints about the interface (I personnaly have hacked a cheap gamepad and it works great). You can reasonably expect to get a low-latency live set at a very low cost, provided that you have a quite recent laptop to work with. Pierre 2010/1/31 Derek Holzer de...@umatic.nl Unnoticeable latency usually refers to the musician not noticing the difference in time between when they press the key and when the sound comes out. Any time you add a delayed signal to the original signal, you will notice it. The slap-back happens at longer latencies, but at shorter latencies you will hear *very* noticeable comb-filtering. And since no computer-based solution is latency-free, I think you need to re-examine what you are expecting Pd to do. Either that, or go with a dedicated DSP board (and learn the accompanying programming!) which would give you a more guitar-pedal-like zero-latency system. Maybe Marco Donnarumma could give a few words here on processing instruments live. His set uses an electric bass through Pd. My guess is that even the un-processed signal goes through Pd to avoid echos or comb filtering due to latency. Best, Derek Jeffrey Concepcion wrote: * in terms of processor capacity, hardware, and sound card configuration, what would be the minimum requirements to achieve unnoticeable latency (not hear the affected signal as a slap-back type of effect)? i've read that 11ms can be achieved and is unnoticeable. -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 18: Balance the consistency principle with the inconsistency principle ___ 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] latency solutions... and then some
Hello, latency delay is noticeable at ~25ms, below there are artefacts grain caused by phase decay if the source and the processed signal are played together at the same place with almost same amplitude. 11ms is only the buffer size, and other elements in sound processing need to be taken in consideration like the distance expressed by the sound speed in the air (about 340m/s at sea level 15°C), so you can add about 3ms per meter, also almost all effects needs a processing window so the more processing power you have, the lower the achievable latency. Any other digital processor added to this chain would add latency, like digital guitar pedals and amplifiers. The dsp needs realtime access, so the Operating System have to be configured for giving high priority to PureData, and a low latency audio driver needs to be used directly from pd or through jack, anyhow there are much possibilities with jack server. Selon Pierre Massat pimas...@gmail.com: Hi Jeffrey! I ve been trying to minimize latency in Pd for a year now, experimenting with various OS and hardware. I m using Pd for the same purpose, that is live processing of electric instruments (mainly a guitar). 2010/1/31 Derek Holzer de...@umatic.nl Unnoticeable latency usually refers to the musician not noticing the difference in time between when they press the key and when the sound comes even the un-processed signal goes through Pd to avoid echos or comb filtering due to latency. Jeffrey Concepcion wrote: type of effect)? i've read that 11ms can be achieved and is unnoticeable. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Floats and negative numbers over OSC
PSPunch wrote: Hi Martin, Thank you for your response. I am attaching the patch used to produce the following results. This was tested on Pd version 0.41.4-extended, running on WinXP SP3. The OSC data were sent by GlovePIE running the following code. --- SendOSC(127.0.0.1, 9997, /test, 0) wait 1 second SendOSC(127.0.0.1, 9997, /test, 1.5) wait 1 second SendOSC(127.0.0.1, 9997, /test, -1) wait 1 second --- I was expecting [routeOSC] to output 0, 1.5, -1. --- Output --- raw: 47 116 101 115 116 0 0 0 44 105 0 0 0 0 0 0 unpacked: /test 0 routed: 0 raw: 47 116 101 115 116 0 0 0 44 102 0 0 63 63 0 0 unpacked: /test 0.746094 routed: 0.746094 raw: 47 116 101 115 116 0 0 0 44 105 0 0 63 63 63 63 unpacked: /test 1.06111e+009 routed: 1.06111e+009 Hmmm, if I try sending the same values from packOSC to routeOSC I get: routed: 0 unpacked: /test 0 raw: 47 116 101 115 116 0 0 0 44 105 0 0 0 0 0 0 routed: 1.5 unpacked: /test 1.5 raw: 47 116 101 115 116 0 0 0 44 102 0 0 63 192 0 0 routed: -1 unpacked: /test -1 raw: 47 116 101 115 116 0 0 0 44 105 0 0 255 255 255 255 It looks like GlovePIE is sending the wrong numbers. Does it send anything except 63 for a value? The integer -1 should be 255 255 255 255, or 4294967295 (32 ones), but your device is sending 1061109567, as though the two most significant bits of each byte are being set to zero. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building Pd for Android
On Sat, 30 Jan 2010 17:53 +0100, Georg Holzmann g...@mur.at wrote: Hallo! Hans-Christoph Steiner schrieb: Ok, made some progress on building Pd for Android. It builds fine, but its not quite working yet. But give it a shot and join in the fun: http://puredata.info/docs/developer/BuildingPdForAndroid Nice ! I also wanted to try it today, but I have the following problem: cannot checkout the branch https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-mobile-0.43, it doesn't seem to exist ... Maybe you did not commit it yet ? Did you also try the C-Java JNI audio interface ? Thanks for any hints, LG Georg Hey Georg, That's the wrong URL for SVN, sorry. I fixed it in the wiki page. It should build now then on Tuesday, we are meeting up to get the audio I/O working. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pda site down?
http://pd-anywhere.sf.net .hc On Sat, 30 Jan 2010 17:44 +0100, marius schebella marius.schebe...@gmail.com wrote: hi, I wanted to test pda on a N900, but it seems like http://gige.xdv.org/pda is down. does someone have a local copy? marius. ___ 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] Building Pd for Android
Hallo! That's the wrong URL for SVN, sorry. I fixed it in the wiki page. It should build now then on Tuesday, we are meeting up to get the audio I/O working. Thanks - then I will try again on wednesday ;) LG Georg ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building Pd for Android
On Sun, 31 Jan 2010 20:10 +0100, Georg Holzmann g...@mur.at wrote: Hallo! That's the wrong URL for SVN, sorry. I fixed it in the wiki page. It should build now then on Tuesday, we are meeting up to get the audio I/O working. Thanks - then I will try again on wednesday ;) LG Georg Actually, it would be good to try building it before we meet, in case you find any problems, then we can fix it. Currently its in a works for me state. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building Pd for Android
Hallo! Actually, it would be good to try building it before we meet, in case you find any problems, then we can fix it. Currently its in a works for me state. OK - but I still cannot checkout from the repository: :~/projects/android/android-ndk-1.6_r1/apps$ svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-mobile-0.43 svn: Die URL »https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-mobile-0.43« existiert nicht (the URL does not exist) LG Georg ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] latency solutions... and then some
His set uses an electric bass through Pd. My guess is that even the un-processed signal goes through Pd to avoid echos or comb filtering due to latency. In my (2 cent) experience to let the un-processed signal go _through Pd_ is still unsatisfying, because anyway you have to deal with some latency hiding around. Instead I usually let my external soundcard output a small amount of direct monitor. This way my clean signal goes through the hardware to the PA with no latency (or at least a fairly un-noticeable latency), then the processed signal/s get overlapped with the minimum latency I can get. This is the cheapest and more satisfying workaround I found so far, even though it's not reliable in every condition and setup. Besides, as already said, when you trigger digital effects with an external hardware you can add more latency; to avoid it, I analyze the un-processed input signal, recognize the notes being played and trigger effects when a note is recognized. Thus I just deal with the latency created while the un-processed input reach the analysis patch. At the same time I route the un-processed signal to the effects bank. Not rocket science but hope this helps. M ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Quick processor question
Hey Folks I'm aware that cutting the signal from an [osc~] will not actually reduce it's processor drain, nor, to my knowledge, does the frequency affect CPU usage. However, does anyone know if it'll take less processor, while not using the output of the object, to give it an argument of 0? That is to say, while the output has [*~] + 0 that zero is also set to the frequency of the [osc~] will this be any more efficient? Thanks Andrew _ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Quick processor question
Hi, I m not sure if i actually got your question, but if you're trying to turn off the oscillator you should use the [switch~] object. It turns audio computation off locally. This means that if you put it in your patch it will turn audio computation on and off for the entire patch, but if you put it in a subpatch (with, say, only your osc~ inside) it will only have an effect at the subpatch level. this is a very useful object when it comes to limiting your CPU load. Pierre 2010/1/31 Andrew Faraday jbtur...@hotmail.com Hey Folks I'm aware that cutting the signal from an [osc~] will not actually reduce it's processor drain, nor, to my knowledge, does the frequency affect CPU usage. However, does anyone know if it'll take less processor, while not using the output of the object, to give it an argument of 0? That is to say, while the output has [*~] + 0 that zero is also set to the frequency of the [osc~] will this be any more efficient? Thanks Andrew -- Not got a Hotmail account? Sign-up now - Freehttp://clk.atdmt.com/UKM/go/19780/direct/01/ ___ 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] Quick processor question
The main loop of the object will still compute the value for a zero Hz signal (always 1), and output blocks. So, in this case an argument of zero shouldn't use any less CPU. On Sun, 31 Jan 2010 22:12:19 + Andrew Faraday jbtur...@hotmail.com wrote: Hey Folks I'm aware that cutting the signal from an [osc~] will not actually reduce it's processor drain, nor, to my knowledge, does the frequency affect CPU usage. However, does anyone know if it'll take less processor, while not using the output of the object, to give it an argument of 0? That is to say, while the output has [*~] + 0 that zero is also set to the frequency of the [osc~] will this be any more efficient? Thanks Andrew _ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/ -- --- Sent from my 3 (http://three.co.uk) mobile broadband Third world internet for a first world economy. * 20 bytes/second * 99% packet loss * 60 second latency All for only £20/month (Odious and predatory terms apply) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Quick processor question
That looks like it might work. Particularly with things like a patch when I may want to turn parts of my texture on or off depending on inputting data. I could cut out a whole synth algorithm etc. Thanks for that. Date: Sun, 31 Jan 2010 23:23:05 +0100 Subject: Re: [PD] Quick processor question From: pimas...@gmail.com To: jbtur...@hotmail.com CC: pd-list@iem.at Hi, I m not sure if i actually got your question, but if you're trying to turn off the oscillator you should use the [switch~] object. It turns audio computation off locally. This means that if you put it in your patch it will turn audio computation on and off for the entire patch, but if you put it in a subpatch (with, say, only your osc~ inside) it will only have an effect at the subpatch level. this is a very useful object when it comes to limiting your CPU load. Pierre 2010/1/31 Andrew Faraday jbtur...@hotmail.com Hey Folks I'm aware that cutting the signal from an [osc~] will not actually reduce it's processor drain, nor, to my knowledge, does the frequency affect CPU usage. However, does anyone know if it'll take less processor, while not using the output of the object, to give it an argument of 0? That is to say, while the output has [*~] + 0 that zero is also set to the frequency of the [osc~] will this be any more efficient? Thanks Andrew Not got a Hotmail account? Sign-up now - Free ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list _ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pix_video error -9402
___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Floats and negative numbers over OSC
Hi Martin, So it seems like a problem with GlovePIE not formatting the bytes according to the OSC specs.. I will review the format and if find it relevant, contact the author. Thanks again for investigating. -- David Shimamoto PSPunch wrote: Hi Martin, Thank you for your response. I am attaching the patch used to produce the following results. This was tested on Pd version 0.41.4-extended, running on WinXP SP3. The OSC data were sent by GlovePIE running the following code. --- SendOSC(127.0.0.1, 9997, /test, 0) wait 1 second SendOSC(127.0.0.1, 9997, /test, 1.5) wait 1 second SendOSC(127.0.0.1, 9997, /test, -1) wait 1 second --- I was expecting [routeOSC] to output 0, 1.5, -1. --- Output --- raw: 47 116 101 115 116 0 0 0 44 105 0 0 0 0 0 0 unpacked: /test 0 routed: 0 raw: 47 116 101 115 116 0 0 0 44 102 0 0 63 63 0 0 unpacked: /test 0.746094 routed: 0.746094 raw: 47 116 101 115 116 0 0 0 44 105 0 0 63 63 63 63 unpacked: /test 1.06111e+009 routed: 1.06111e+009 Hmmm, if I try sending the same values from packOSC to routeOSC I get: routed: 0 unpacked: /test 0 raw: 47 116 101 115 116 0 0 0 44 105 0 0 0 0 0 0 routed: 1.5 unpacked: /test 1.5 raw: 47 116 101 115 116 0 0 0 44 102 0 0 63 192 0 0 routed: -1 unpacked: /test -1 raw: 47 116 101 115 116 0 0 0 44 105 0 0 255 255 255 255 It looks like GlovePIE is sending the wrong numbers. Does it send anything except 63 for a value? The integer -1 should be 255 255 255 255, or 4294967295 (32 ones), but your device is sending 1061109567, as though the two most significant bits of each byte are being set to zero. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building Pd for Android
On Jan 31, 2010, at 2:20 PM, Georg Holzmann wrote: Hallo! Actually, it would be good to try building it before we meet, in case you find any problems, then we can fix it. Currently its in a works for me state. OK - but I still cannot checkout from the repository: :~/projects/android/android-ndk-1.6_r1/apps$ svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-mobile-0.43 svn: Die URL »https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-mobile-0.43 « existiert nicht (the URL does not exist) Sorry, it seems the update didn't take. I fixed it, plus here's the URL: https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/by-author/eighthave/pd-mobile-0.43 .hc There is no way to peace, peace is the way. -A.J. Muste ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
