[PD] measuring entropy of a signal?
Hi , i was wondering if anybody have implemented the shannon entropy function in pd? Do anybody have tried measuring entropy of a signal? cheeers R. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] measuring entropy of a signal?
Hi Ronni How do you mean to do it? Shannon entropy is not an independent measurement--the information in a observation is relative to the distribution of all it's possible values. If I just take one sample and it's evenly distributed between -0.98 and 1 and it's quantized in 0.02 increments (to make the math easier), then the information of any value observed is: -0.01*log(0.01) Then--if I had a signal that's N samples long, I have N times as much information. Or perhaps think of it as a rate of information. But for real numbers and continuous distributions, this doesn't work. The information in a single observation diverges. So, doing that with floating point numbers is not practical. You often see Shannon entropy describing digital signals. If the signal just switches between 0 and 1, we can generate a distribution of the data and see what the probability is empirically. The entropy of each new sample is relative to the distribution. Likewise, then if you know the maximum rate of switching, you can figure out the maximum rate of information in the signal. Just a few thoughts... Chuck On Tue, Feb 26, 2013 at 6:09 AM, ronni montoya ronni.mont...@gmail.comwrote: Hi , i was wondering if anybody have implemented the shannon entropy function in pd? Do anybody have tried measuring entropy of a signal? cheeers R. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd META extension
On Mon, 2013-02-25 at 22:10 -0800, Jonathan Wilkes wrote: Hello list, I'd like to extend the syntax of the xlet metadata in the [pd META] subpatch. Currently something like [clip] has this for the inlets: INLET_0 float list INLET_1 float INLET_2 float That gets picked up by the autotips which display the methods in the tooltip. However, for objects that have multiple xlets like [clip], an xlet tip would be more helpful if it included a one or two word description of what the inlet is for. So when the user hovers over the middle inlet the tip can also say something like: Inlet 1 of clip (low value): float and for the right inlet: Inlet 2 of clip (high value): float I just need some clear syntax for separating the inlet description from the methods. Idea #0: semicolon Example: INLET_1 float; low value Nice because there is no chance of ambiguity, since the semi can't be part of a method name. Unfortunately it forces a newline. The semicolon + description part would be optional so there's no need to change any of the current docs. Plus it's easy to parse. What I like about the META format is it is also easy to parse with Pd itself. Thus, I was concerned if your proposed addition would break that. I figured it does not. I don't see any other troubles, but see the benefit of having a separator. Please go ahead. Roman P.S.: While testing Pd parsability, I created an object [sel ;] which immediately collapsed to [sel;] on instantiation. Although it looks weird, it's still functional. It seems something in Pd removes spaces around ';'. (Also try creating a [sel ; sel]) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Slice//Jockey2 beta, compatible with Pd-E 0.43
Finally I have a public beta of Slice//Jockey2 available. Slice//Jockey is a live-sampling tool for Pd-extended. The original version is shared since 2011. Due to discontinuation of lib toxy, some stuff had to be modified to make Slice//Jockey compatible with Pd-E 0.43. While I was at the job, I took the opportunity to upgrade some effects and overall sound quality. Get SliceJockey2test2.zip from my page: http://www.katjaas.nl/slicejockey/slicejockey.html Please do not hesitate to report bugs if you find any. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Going to Tokyo - PD Media Art Scene
Seiichiro, Ryuta! I'll be in Tokyo until saturday. What do you guys think we meetup for a beer or something? Best, leandro On Wed, Feb 13, 2013 at 2:19 AM, Seiichiro MATSUMURA s...@low-tech-ism.comwrote: Hi Leandro, PD and Media Art scene while I'm there - from feb 18th to march 2nd. I will organize the (maybe) first Pd Synthesizer Workshop at Tokyo this weekend but they are only 16-17th. http://low-tech-ism.com/ltb/?p=875 Unfortunately it will be finished before your visit to Tokyo. I will tell to participants about Pecha Kucha Night. What are you going to demonstrate? Numbers of Pd users here in Japan are quite limited yet but we start the Pure Data Japan portal web site very soon expecting users increased from now. Japan Media Arts Festival exhibition will be opened at Roppongi during your stay. Please check it out. http://j-mediaarts.jp/ Best, Sei -- __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ Seiichiro Matsumura s...@low-tech-ism.com http://low-tech-ism.com/ __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ 2013/2/11 Leandro da Mota Damasceno lem...@gmail.com: Hi all! So, I'm going to Tokyo next week to present at the 100th Pecha Kucha Night. I've never been to Japan before and I'm looking forward to get to know the PD and Media Art scene while I'm there - from feb 18th to march 2nd. So, I would love to get to know people from the PD community in Tokyo, visit media labs and hackerspaces if there are any. Any suggestions? best, Leandro ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd META extension
- Original Message - From: Roman Haefeli reduz...@gmail.com To: pd-list@iem.at Cc: Sent: Tuesday, February 26, 2013 8:24 AM Subject: Re: [PD] pd META extension On Mon, 2013-02-25 at 22:10 -0800, Jonathan Wilkes wrote: Hello list, I'd like to extend the syntax of the xlet metadata in the [pd META] subpatch. Currently something like [clip] has this for the inlets: INLET_0 float list INLET_1 float INLET_2 float That gets picked up by the autotips which display the methods in the tooltip. However, for objects that have multiple xlets like [clip], an xlet tip would be more helpful if it included a one or two word description of what the inlet is for. So when the user hovers over the middle inlet the tip can also say something like: Inlet 1 of clip (low value): float and for the right inlet: Inlet 2 of clip (high value): float I just need some clear syntax for separating the inlet description from the methods. Idea #0: semicolon Example: INLET_1 float; low value Nice because there is no chance of ambiguity, since the semi can't be part of a method name. Unfortunately it forces a newline. The semicolon + description part would be optional so there's no need to change any of the current docs. Plus it's easy to parse. What I like about the META format is it is also easy to parse with Pd itself. Thus, I was concerned if your proposed addition would break that. I figured it does not. I don't see any other troubles, but see the benefit of having a separator. Please go ahead. Currently the parsing is extremely simple since it's just a capitalized word followed by atoms and a terminating semicolon (plus filtering out newlines but that's easy). The proposed extension still fits that, except that atoms mean something different depending on which side of a semicolon atom (i.e., a backslashed semicolon) they happen to be. Not to mention the fact that the spaces around the semicolon atom look different depending on whether you're looking at a patch or the patch source as you show below. I could keep the trivial syntax by adding a new tag: INLET_1_DESC low value INLET_2_DESC high value The tag is a little long but it's much easier to parse. For people making abstractions where they want to control tooltip text this is what they want, so it will keep people from mixing methods with free text. -Jonathan Roman P.S.: While testing Pd parsability, I created an object [sel ;] which immediately collapsed to [sel;] on instantiation. Although it looks weird, it's still functional. It seems something in Pd removes spaces around ';'. (Also try creating a [sel ; sel]) ___ 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] file format for GEM
Hello, So, looking at the help file for [pd~], it seems to be primarily for audio. How can I use multiple cores to work purely with GEM? I am trying to have a simple transition between video clips, but if I have two instances of pix_film and then connect them to pix_add, the CPU-ussage skyrockets well above 100... is there a more efficient object for blending two video clips? Best regards, Stephan On Sun, Feb 3, 2013 at 10:54 PM, Thomas Mayer tho...@residuum.org wrote: Hi, On 03.02.2013 22:48, Stephan Elliot Perez wrote: I am talking about PD's CPU meter. I don't have the impression that PD takes full advantage of 2 quad-core processors. When processing audio, anything over 100 in PD's meter will lead to glitched audio. I am just wondering if it will be much more when I load other videos and transition between them. Pd will only use one core, and one core for the GUI. There are ways to distribute the load over several cores, e.g. [pd~] or use several instances of Pd that communicate with each others: http://www.mail-archive.com/pd-list@iem.at/msg33319.html Hth, Thomas -- Spielen Sie Strip Schnipp-Schnapp? (Adam Weishaupt to Johann Wolfgang von Goethe in: Robert Shea Robert A. Wilson, The Golden Apple) http://www.residuum.org/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] file format for GEM
hello, Gem is mostly design to work on the GPU, and not on the CPU. GPU have hundreds of core, they are faster than CPU for image manipulations. pix_add come from the 20th century and should now be avoid since it use cpu not gpu ;-) in order to make a fade transition between 2 videos, you can use transparency on one video. add a [alpha] object after Gemhead, and send number between 0 and 1 in the last inlet of the colorRGB object to make the video appear / disapear. cheers c Le 26/02/2013 21:33, Stephan Elliot Perez a écrit : Hello, So, looking at the help file for [pd~], it seems to be primarily for audio. How can I use multiple cores to work purely with GEM? I am trying to have a simple transition between video clips, but if I have two instances of pix_film and then connect them to pix_add, the CPU-ussage skyrockets well above 100... is there a more efficient object for blending two video clips? Best regards, Stephan On Sun, Feb 3, 2013 at 10:54 PM, Thomas Mayer tho...@residuum.org mailto:tho...@residuum.org wrote: Hi, On 03.02.2013 22:48, Stephan Elliot Perez wrote: I am talking about PD's CPU meter. I don't have the impression that PD takes full advantage of 2 quad-core processors. When processing audio, anything over 100 in PD's meter will lead to glitched audio. I am just wondering if it will be much more when I load other videos and transition between them. Pd will only use one core, and one core for the GUI. There are ways to distribute the load over several cores, e.g. [pd~] or use several instances of Pd that communicate with each others: http://www.mail-archive.com/pd-list@iem.at/msg33319.html Hth, Thomas -- Spielen Sie Strip Schnipp-Schnapp? (Adam Weishaupt to Johann Wolfgang von Goethe in: Robert Shea Robert A. Wilson, The Golden Apple) http://www.residuum.org/ ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] denormals from [cyclone/svf~] on Linux 64 bit
Since last week I have my own Linux 64 bit machine. One of the first issues with Pd-extended on this machine was a strongly increased CPU load when audio input is temporarily shut off from parts of my patch. Subnormals! After three hours of puzzling I identified at least one offender: [cyclone/svf~]. Sorry that most of my posts to this list seem to be about subnormals. That's quite boring. But they're seriously hogging my CPU time like a swarm of grasshoppers. As I got this 64 bit machine so recently I don't know if the issue with [cyclone/svf~] exists in earlier Pd-E versions. Also, I can not understand why it happens, because the object is protected against subnormals with function PD_BIGORSMALL(). This works well on all my other systems. Moreover, it works well for other feedback delay objects like [lop~] on Linux 64 bit. I'd like to know if anyone can confirm the issue. I was planning to do my own state variable filter anyway, but it would be nice to have a working [cyclone/svf~] as well. Check the object with attached patch if you can. To be specific, I have the issue with Pd-E 0.43.4 for Debian Squeeze amd64 from nightly builds. The i386 build is not affected. Katja #N canvas 127 299 620 382 10; #X symbolatom 18 351 72 0 0 0 - - -; #X obj 18 323 makefilename %.70f; #N canvas 0 50 190 245 nan 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 143 * 0; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 6 0; #X connect 2 0 3 0; #X connect 2 1 5 1; #X connect 3 0 5 0; #X connect 4 0 1 0; #X connect 5 0 4 0; #X connect 6 0 2 0; #X restore 18 44 pd nan; #X obj 18 20 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #N canvas 0 50 168 259 inf 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 5 0; #X connect 2 0 3 0; #X connect 2 1 4 1; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 5 0 2 0; #X restore 71 44 pd inf; #X obj 71 20 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 18 181 8 0 0 0 - - -; #X msg 72 114 1; #X msg 72 84 0; #X msg 113 108 \; pd dsp 1; #X msg 113 147 \; pd dsp 0; #X obj 113 85 loadbang; #N canvas 0 50 200 224 unsig~ 0; #X obj 32 40 inlet~; #X obj 32 122 snapshot~; #X obj 61 89 metro 200; #X obj 61 62 tgl 15 1 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 32 153 outlet; #X connect 0 0 1 0; #X connect 1 0 4 0; #X connect 2 0 1 0; #X connect 3 0 2 0; #X restore 18 266 pd unsig~; #X floatatom 18 296 17 0 0 0 - - -; #X text 183 133 Small floats which can't be expressed with the bits of the datatype are also denormal \, more specifically: subnormal. Computations with subnormal numbers are still possible \, but very CPU intensive. Test: click 1 first \, then 0 to see how small the numbers become. If all is OK \, numbers smaller than ~1e-19 are flushed to zero. If not OK \, numbers smaller than 1e-39 are seen. These are subnormals. Check CPU load difference. It is always possible to recover from subnormals by sending a normal number (like 1) in.; #X text 184 320 Katja Vetter Jan 2013; #X text 183 18 NaN and inf are denormal numbers. When inf or nan starts recirculating in a feedback delay line \, the object can't do further calculations \, even if the input goes back to normal. Therefore Pd must avoid writing nan or inf into a feedback delay line. Test: click nan or inf first \, and 1 thereafter. If all is OK \, the output returns to normal. If not OK \, inf or nan will stay at the output and the patch must be reloaded to recover.; #X obj 18 229 svf~ 1; #N canvas 311 334 476 347 lop 0; #N canvas 0 50 190 245 nan 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 143 * 0; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 6 0; #X connect 2 0 3 0; #X connect 2 1 5 1; #X connect 3 0 5 0; #X connect 4 0 1 0; #X connect 5 0 4 0; #X connect 6 0 2 0; #X restore 28 54 pd nan; #X obj 28 30 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #N canvas 0 50 168 259 inf 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 5 0; #X connect 2 0 3 0; #X connect 2 1 4 1; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 5 0 2 0; #X restore 81 54 pd inf; #X obj 81 30 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 28 191 8 0 0 0 - - -; #X msg 82 124 1; #X msg 82 94 0; #N canvas 0 50 200 224 unsig~ 0; #X obj 32 40 inlet~; #X obj 32 122 snapshot~; #X obj 61 89 metro 200; #X obj 61 62 tgl 15 1 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 32 153 outlet; #X connect 0 0 1 0; #X connect 1 0 4 0; #X connect 2 0 1 0; #X connect 3 0 2 0; #X restore 28 276 pd unsig~; #X floatatom 28 306 17 0 0 0 - - -; #X obj 82 215 hsl 100 15 0 200 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 2800 0; #X floatatom 92 240 5 0 0 0 - - -; #X obj 28 239 lop~; #X text 167 27 [lop~] is
[PD] Gem newbee question/antialiasing of edges on boxes
hi list i found this picture http://daimi.au.dk/~vectral/html_gallery_1/pics/Image_00227.jpg which is done in max/jitter on osx and i wonder how do you get them soft edges/lines on them boxes, if its possible at all. when I create a cube or any other 3d object it has that grainy look. Does it have anything to do with the OS/hardware its been running on? best regards ./jc -- http://www.fastmail.fm - mmm... Fastmail... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem newbee question/antialiasing of edges on boxes
hello, if you use a nvidia GPU, you can set antialiasing on the rendering using a FSAA message to gemwin (see gemwin help), before window creation. if you use nvidia or amd gpu, you can force the antialiasing using drivers configuration tools (if available on your os) whatever gpu you are using, you can set per primitive antialiasing using the polygon_smooth object after a gemhead on my experience, this last option can be slower than the 1st one. cheers c Le 26/02/2013 22:25, jamal crawford a écrit : hi list i found this picture http://daimi.au.dk/~vectral/html_gallery_1/pics/Image_00227.jpg which is done in max/jitter on osx and i wonder how do you get them soft edges/lines on them boxes, if its possible at all. when I create a cube or any other 3d object it has that grainy look. Does it have anything to do with the OS/hardware its been running on? best regards ./jc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [announce] [pd-fileutils] released, a command-line tool for managing pd files
Hi all! I am pleased to announce that I just released the first working version of pd-fileutils (https://github.com/sebpiq/pd-fileutils) which is a node.js package and a command-line tool for fiddling with pd files. Right now, the command-line tool only allows you to render .pd files to SVG, but expect more functionalities in the future (I am open to suggestions). If you know JavaScript and node.js, you can also use the API for scripting operations with your pd files. Right now, it can only parse .pd files to a standard JavaScript object, which you can then manipulate easily with JavaScript. This library is a by-product of the WebPd project ( https://github.com/sebpiq/WebPd), which aims at running Pure Data patches on the browser. It is also a proposal for an alternative file format for Pure Data, based on JSON. There was a discussion about that on pd-dev : http://lists.puredata.info/pipermail/pd-dev/2012-06/018436.html and I would like to start it again ;) Cheers! Sébastien Piquemal PS : there will definitely be bugs, so don't hesitate to report them :) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] [pd-fileutils] released, a command-line tool for managing pd files
Hi all! I am pleased to announce that I just released the first working version of pd-fileutils (https://github.com/sebpiq/pd-fileutils) which is a node.js package and a command-line tool for fiddling with pd files. Right now, the command-line tool only allows you to render .pd files to SVG, but expect more functionalities in the future (I am open to suggestions). If you know JavaScript and node.js, you can also use the API for scripting operations with your pd files. Right now, it can only parse .pd files to a standard JavaScript object, which you can then manipulate easily with JavaScript. This library is a by-product of the WebPd project ( https://github.com/sebpiq/WebPd), which aims at running Pure Data patches on the browser. It is also a proposal for an alternative file format for Pure Data, based on JSON. There was a discussion about that on pd-dev : http://lists.puredata.info/pipermail/pd-dev/2012-06/018436.html and I would like to start it again ;) Cheers! Sébastien Piquemal PS : there will definitely be bugs, so don't hesitate to report them :) ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] denormals from [cyclone/svf~] on Linux 64 bit
I, for one, am very happy that you post on denormal issues! Its great to have these hard technical details worked out so that they don't trip us up in future works :) On my Linux Mint Maya 64-bit machine, I get about 3% CPU before it hits the denormal, then about 11% CPU. Hitting 1 jumps it back down to 3%. Is it worth trying bsaylor/svf~? I don't know if it works better in this situation. I don't think cyclone has gotten many 64-bit fixes. As part of the Pd-extended 0.43.4 release, I did do a push to fix a lot of 64-bit issues related to GUI stuff, but there are still a number of cyclone objects that do not have proper 64-bit array support. .hc On 02/26/2013 04:26 PM, katja wrote: Since last week I have my own Linux 64 bit machine. One of the first issues with Pd-extended on this machine was a strongly increased CPU load when audio input is temporarily shut off from parts of my patch. Subnormals! After three hours of puzzling I identified at least one offender: [cyclone/svf~]. Sorry that most of my posts to this list seem to be about subnormals. That's quite boring. But they're seriously hogging my CPU time like a swarm of grasshoppers. As I got this 64 bit machine so recently I don't know if the issue with [cyclone/svf~] exists in earlier Pd-E versions. Also, I can not understand why it happens, because the object is protected against subnormals with function PD_BIGORSMALL(). This works well on all my other systems. Moreover, it works well for other feedback delay objects like [lop~] on Linux 64 bit. I'd like to know if anyone can confirm the issue. I was planning to do my own state variable filter anyway, but it would be nice to have a working [cyclone/svf~] as well. Check the object with attached patch if you can. To be specific, I have the issue with Pd-E 0.43.4 for Debian Squeeze amd64 from nightly builds. The i386 build is not affected. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] denormals from [cyclone/svf~] on Linux 64 bit
Hi Hans, thanks for your response. I don't consider [bsaylor/svf~] a good alternative, it has aliasing noises with some settings. Oddly, I have a simplified version of [cyclone/svf~] (lopass only) which does work well in Linux 64 bit. So one way or another I should be able to fix [cyclone/svf~]. Not at first sight however. Katja On 2/26/13, Hans-Christoph Steiner h...@at.or.at wrote: I, for one, am very happy that you post on denormal issues! Its great to have these hard technical details worked out so that they don't trip us up in future works :) On my Linux Mint Maya 64-bit machine, I get about 3% CPU before it hits the denormal, then about 11% CPU. Hitting 1 jumps it back down to 3%. Is it worth trying bsaylor/svf~? I don't know if it works better in this situation. I don't think cyclone has gotten many 64-bit fixes. As part of the Pd-extended 0.43.4 release, I did do a push to fix a lot of 64-bit issues related to GUI stuff, but there are still a number of cyclone objects that do not have proper 64-bit array support. .hc On 02/26/2013 04:26 PM, katja wrote: Since last week I have my own Linux 64 bit machine. One of the first issues with Pd-extended on this machine was a strongly increased CPU load when audio input is temporarily shut off from parts of my patch. Subnormals! After three hours of puzzling I identified at least one offender: [cyclone/svf~]. Sorry that most of my posts to this list seem to be about subnormals. That's quite boring. But they're seriously hogging my CPU time like a swarm of grasshoppers. As I got this 64 bit machine so recently I don't know if the issue with [cyclone/svf~] exists in earlier Pd-E versions. Also, I can not understand why it happens, because the object is protected against subnormals with function PD_BIGORSMALL(). This works well on all my other systems. Moreover, it works well for other feedback delay objects like [lop~] on Linux 64 bit. I'd like to know if anyone can confirm the issue. I was planning to do my own state variable filter anyway, but it would be nice to have a working [cyclone/svf~] as well. Check the object with attached patch if you can. To be specific, I have the issue with Pd-E 0.43.4 for Debian Squeeze amd64 from nightly builds. The i386 build is not affected. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem newbee question/antialiasing of edges on boxes
hi Cyrille and list yes i found some configuration tools and maxed them up and yes i can see the smoothing now (which still is grainy, but its ok), but it seems like polygon_smooth does nothing. i have no nvidia gpu, so no FSAA for me (but something called ati radeon express m200 from somewhere 2006 on this win box). i guess so far i will be left in a dust (of smoothly rendered boxes), until i'll buy an nvidia gpu. Can anyone advise an nvidia gpu (or some tech specifications) which will be powerfull enough to render the edges as smoothly (cirka) as on that picture, i linked. thank you for very fast reply best regs ./jc On Tue, Feb 26, 2013, at 01:50 PM, Cyrille Henry wrote: hello, if you use a nvidia GPU, you can set antialiasing on the rendering using a FSAA message to gemwin (see gemwin help), before window creation. if you use nvidia or amd gpu, you can force the antialiasing using drivers configuration tools (if available on your os) whatever gpu you are using, you can set per primitive antialiasing using the polygon_smooth object after a gemhead on my experience, this last option can be slower than the 1st one. cheers c -- http://www.fastmail.fm - The professional email service ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-l2ork feedback
This may be because you didn't hide gop titles, in which case pd-l2ork resizes gop size to match the text width. Regarding slow redraw, can you try latest version? I fixed one major inefficiency. On Feb 26, 2013 6:22 PM, András Murányi muran...@gmail.com wrote: Thanks for the reply. The hangup is literally 5 minutes, CPU is maxed out most of the time. The undo takes 5 seconds, again literally. It doesn't occur in pd-extended. Nested gop subpatches should show their outlines and xlets (just like number2 or toggle does as well), shouldn’t they? Well, traditionally they don't and I think they should not. This would be consistent behavior if the borders of every element in the outer GOP subpatch would be visible. *However, I was wrong and actually this is not what's happening.* Rather, it seems that some GOP subpatches have the wrong size, and then they also show thru nested GOPs. See the attached screenshot: at the top left corder of the open subpatch, there are two GOP subpatches (Cut and Res; their guts are shown in the open subpatch window), each wider than they should be. The big gray rectangle at the bottom of the image is a large GOP subpatch itself, and the same nested GOP shows thru it. I couldn't reproduce this symptom from scratch. András On Fri, Feb 22, 2013 at 10:37 PM, Ivica Ico Bukvic i...@vt.edu wrote: One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes? Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way... Is the same slowness perceived on regular pd when moving the said abstraction? On 02/22/2013 03:34 PM, András Murányi wrote: So, I've played around with the last git, here are some things I've noticed: - miXed/toxy is not in pd-l2ork and it's perfectly alrite because some kinds of [widget] work while others not. - [flatgui/popup] is installed by default but it throws an error when clicked on: Invalid command name pdtk_canvas_mouse. - moving a simple GOP abstraction with a single [mknob] in it takes like 5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec). - nested GOP subpatches show off their outlines and xlets. -- Murányi András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-l2ork feedback
On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic i...@vt.edu wrote: This may be because you didn't hide gop titles, in which case pd-l2ork resizes gop size to match the text width. Yes this is indeed the case. I noticed, however, that there was no title to be displayed, meaning that with hide GOP title unchecked, the rectangle was bigger but there was no title (see attachment). And it shows the frame when it's embedded in another GOP. Regarding slow redraw, can you try latest version? I fixed one major inefficiency. I'll try it as soon as I get to it. I noticed meanwhile that during the hangup, this error is thrown to the command line a few times: tcl/tk error: unknown encoding yahoo András On Feb 26, 2013 6:22 PM, András Murányi muran...@gmail.com wrote: Thanks for the reply. The hangup is literally 5 minutes, CPU is maxed out most of the time. The undo takes 5 seconds, again literally. It doesn't occur in pd-extended. Nested gop subpatches should show their outlines and xlets (just like number2 or toggle does as well), shouldn’t they? Well, traditionally they don't and I think they should not. This would be consistent behavior if the borders of every element in the outer GOP subpatch would be visible. *However, I was wrong and actually this is not what's happening.* Rather, it seems that some GOP subpatches have the wrong size, and then they also show thru nested GOPs. See the attached screenshot: at the top left corder of the open subpatch, there are two GOP subpatches (Cut and Res; their guts are shown in the open subpatch window), each wider than they should be. The big gray rectangle at the bottom of the image is a large GOP subpatch itself, and the same nested GOP shows thru it. I couldn't reproduce this symptom from scratch. András On Fri, Feb 22, 2013 at 10:37 PM, Ivica Ico Bukvic i...@vt.edu wrote: One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes? Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way... Is the same slowness perceived on regular pd when moving the said abstraction? On 02/22/2013 03:34 PM, András Murányi wrote: So, I've played around with the last git, here are some things I've noticed: - miXed/toxy is not in pd-l2ork and it's perfectly alrite because some kinds of [widget] work while others not. - [flatgui/popup] is installed by default but it throws an error when clicked on: Invalid command name pdtk_canvas_mouse. - moving a simple GOP abstraction with a single [mknob] in it takes like 5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec). - nested GOP subpatches show off their outlines and xlets. -- Murányi András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list attachment: Screenshot.png___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-l2ork feedback
On 02/26/2013 09:07 PM, András Murányi wrote: On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic i...@vt.edu mailto:i...@vt.edu wrote: This may be because you didn't hide gop titles, in which case pd-l2ork resizes gop size to match the text width. Yes this is indeed the case. I noticed, however, that there was no title to be displayed, meaning that with hide GOP title unchecked, the rectangle was bigger but there was no title (see attachment). And it shows the frame when it's embedded in another GOP. AFAIK embedded GOP objects have always had frames. This is why all iemguis also have frames/inlets/outlets even when embedded inside GOP. I think your background made them hard to distinguish. I could be wrong, though, but I always remember seeing those. As for the text not being displayed, can you send me the slider abstraction? It could be that since you've originally saved the abstraction inside regular pd that it did not get adjusted completely to conform to pd-l2ork's way of dealing with these. Try manually readjusting the GOP size and re-save it. It should either prevent you from resizing it below the text size or do it just fine provided you've disabled the showing of text. As for text not showing in a subpatcher even though it should, this is something I should investigate. Regarding slow redraw, can you try latest version? I fixed one major inefficiency. I'll try it as soon as I get to it. I noticed meanwhile that during the hangup, this error is thrown to the command line a few times: tcl/tk error: unknown encoding yahoo This likely refers to text encoding if you use something unusual/setup-specific. HTH András On Feb 26, 2013 6:22 PM, András Murányi muran...@gmail.com mailto:muran...@gmail.com wrote: Thanks for the reply. The hangup is literally 5 minutes, CPU is maxed out most of the time. The undo takes 5 seconds, again literally. It doesn't occur in pd-extended. Nested gop subpatches should show their outlines and xlets (just like number2 or toggle does as well), shouldn’t they? Well, traditionally they don't and I think they should not. This would be consistent behavior if the borders of every element in the outer GOP subpatch would be visible. *However, I was wrong and actually this is not what's happening.* Rather, it seems that some GOP subpatches have the wrong size, and then they also show thru nested GOPs. See the attached screenshot: at the top left corder of the open subpatch, there are two GOP subpatches (Cut and Res; their guts are shown in the open subpatch window), each wider than they should be. The big gray rectangle at the bottom of the image is a large GOP subpatch itself, and the same nested GOP shows thru it. I couldn't reproduce this symptom from scratch. András On Fri, Feb 22, 2013 at 10:37 PM, Ivica Ico Bukvic i...@vt.edu mailto:i...@vt.edu wrote: One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes? Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way... Is the same slowness perceived on regular pd when moving the said abstraction? On 02/22/2013 03:34 PM, András Murányi wrote: So, I've played around with the last git, here are some things I've noticed: - miXed/toxy is not in pd-l2ork and it's perfectly alrite because some kinds of [widget] work while others not. - [flatgui/popup] is installed by default but it throws an error when clicked on: Invalid command name pdtk_canvas_mouse. - moving a simple GOP abstraction with a single [mknob] in it takes like 5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec). - nested GOP subpatches show off their outlines and xlets. -- Murányi András ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and
Re: [PD] pd-l2ork feedback
On 02/26/2013 09:48 PM, Ivica Ico Bukvic wrote: AFAIK embedded GOP objects have always had frames. This is why all iemguis also have frames/inlets/outlets even when embedded inside GOP. I think your background made them hard to distinguish. I could be wrong, though, but I always remember seeing those. As for the text not being displayed, can you send me the slider abstraction? It could be that since you've originally saved the abstraction inside regular pd that it did not get adjusted completely to conform to pd-l2ork's way of dealing with these. Try manually readjusting the GOP size and re-save it. It should either prevent you from resizing it below the text size or do it just fine provided you've disabled the showing of text. As for text not showing in a subpatcher even though it should, this is something I should investigate. BTW, I just checked on pd-l2ork and everything draws just as it should even with multiply embedded GOPs (ones with text enabled show text and ones with it disabled don't. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
