Re: [PD] 0 latency
On Sat, 2008-12-27 at 19:48 +0100, Damian Stewart wrote: > Jaime Oliver wrote: > > 15-20 ms should be perceptually enough (visual-sound or motor-sound), > > some people put it at 40, but a percussionist would definitely notice > > it. I suppose one has to learn it and make it part of the instrument, > > latency in an acoustic piano can be as high as 100ms... > > > > But the problem is that the pad probably makes a noise, and the > > perceptual latency for two sounds to fuse is not more than 5ms... > > > > J > > i've been playing hands-on live electroacoustic music with 50ms latency for > about three years now. my ears/hands have just adjusted to the delay - if i > want something to happen at a particular time, i just start moving 50ms > earlier... I also mainly use the Pd default 50ms setting for the 'live electronics' work I do, but mostly my music involves gradual change over parameters, or changes in advance so this is OK for me. I think for more gestural control e.g. DJ-style scratching or note-based control 50ms is unacceptable. For example it's feasible that the entire physical gesture (or note) could be complete before sound has even started to respond. I set up a 'record scratch' patch for a DJ recently and we had to take the Pd delay setting down to 12ms before he found it responsive enough to perform with. It would have been nice to have gone even lower, but after that the audio started breaking up. Jamie -- www.postlude.co.uk http://www.linkedin.com/in/jamiebullock ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] a flawed Gem (Was: Re: pdp/pidip on win32?)
hello, 1-> i don't know where the problem is. But i don't think it is in Gem, since Gem does only control the graphic card. upgrade you graphic card could help. 2-> Yes, the Gemhead concept in Gem is different than pd concept. it is this way because Gem is very close to openGL concept, and that's why Gem works so efficiently. See documentation about OpenGL for more info. 3-> what you describe is a missing sinc to vblank. Be aware that once you set this parametter on the driver, you have to choose on wich screen to sinc, and to restart pd/Gem. Nvidia driver are the same for lot's of different hardware, it's possible that you have this option in your drivers, but your hardware is not able to do it. 3b-> i don't have a firwire cam to test, but i saw strange thing in you patch : -why do you use spigot? -why do you connect many time on the same camera? can you try the attached patch, and tell us if it is still crashing? 4-> i think there was some bug report about this issue regarding pix_record on linux. don't have time to check. 6-> pix_motionblur does affect images in the buffer, because Gem did not copy images from the buffer before using them. This is the way to have good performance. of course, you can force Gem to copy the image, using pix_separator. Sending 1 mail for 1 problem would be easier to discuss. Cyrille John Harrison a écrit : As promised, here's a couple of patches to show a few of my concerns about Gem. Interestingly, after creating the patches on the target machine, I tried the same patches on my laptop and got slightly better results (recording suddenly started working again and I was able to avoid one referenced segfault in the patch. I made a note of both of these changes inside the patch.) I'd love to get these concerns addressed and would like to help to accomplish this in whatever would be most effective. It would be amazing to really get this tool ready for artists ready to explore this medium in the classes I teach. I built these patches on ubuntu 8.10 32 bit on Pd-extended 0.40.3 with video card referred to by lspci as nVidia GeForce 6150SE nForce 430 (a2). You'll need a firewire video capture device to try them. The patches also create and reference a recorded video file: /tmp/test.mov. Perhaps the name would need to be changed if trying on OSX or Windows. This is just a start on some of the problems I have had. If it is helpful I can provide more feedback like this. Thanks, -John ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list #N canvas 714 433 450 300 10; #N canvas 51 160 450 300 1.GemWindowFreezes 0; #X text 12 9 My troubles with Gem started when I opened any help patch on the target machine. When a Gem window was opened \, the machine would freeze when the Gem window was moved or other windows were moved to overlap with the Gem window. The freeze would last up to 30 seconds then the machine would be OK again. The target machine was an AMD 64 bit dual core. lspci reported an nVidia GeForce 6150SE nForce 430 (rev a2) as the graphics card. This behavior was observed with both ubuntu 8.10-64 bit and ubuntu 8.10-32 bit \, both running the nVidia proprietary driver. I tried several different versions of the nVidia driver and this did not change the behavior. For some reason \, changing from Gnome/metacity to Gnome/compiz helped \, making the problem less consistent. The machine was considered still suitable for the project since running in full screen mode the freezes would not happen once the full screen was drawn. But it was a constant annoyance throughout development. Another target machine \, identical to the first target machine except with only a single core AMD \, would freeze but would never come back from freezing until it was hard-reset. That machine was running ubuntu 7.10-32 bit with an nVidia driver. That machine was abandoned. I tried the open source nVidia driver but that had more serious problems that I do not completely recall at this time. Changing kernels on these machines did not help either.; #X restore 8 44 pd 1.GemWindowFreezes; #N canvas 90 142 581 591 3.IEEE1394video 0; #X text -33 2 Gem video quality from the IEEE1394 cameras was OK but a bit disappointing. Images moving quickly across the screen seemed to have jagged lines around them and some artifacts related to redraw and buffering. I experimented with Gem single and double buffering but got nowhere. My guess is that Gem is by default double-buffering but I was never really sure. I also experimented with various nVidia driver settings (sync to vblank etc.) which did not offer any significant improvement. I tried 2 different cameras and both had these artifacts. The artifacts were not present when capturing video in Kino with the same cameras and target machine.; #N canvas 596 1
Re: [PD] Vasp: main help file missing
Hi João, what exactly do you mean with "build"? pd-extended? I'm only providing binaries (external objects) for download and accompanying patches on svn. For more info see http://puredata.info/Members/thomas/vasp gr~~~ Am 27.12.2008 um 00:43 schrieb João Pais: > Hi, > > this is just a small post to remember Thomas Grill that the main > help file > in Vasp - vasp-help.pd is missing in the build I have (which is of end > july 08, the latest for windows). Is this file going to be taken > off the > package? I always found it very useful. > > Best, > > João Pais > > -- > Friedenstr. 58 > 10249 Berlin (Deutschland) > Tel +49 30 42020091 | Mob +49 162 6843570 > jmmmp...@googlemail.com | skype: jmmmpjmmmp > > ___ > 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] a flawed Gem (Was: Re: pdp/pidip on win32?)
ben baker-smith wrote: > I have really enjoyed using Gem, especially the particle systems but > also using it to manipulate live video feeds. However, I also would > like to see it streamlined so that the gemlist actually travels from > top to bottom. this would break about 100% of existing Gem patches. Gem has been around for more than 12 years, i would prefer to avoid such a thing. As it is now there are a lot of weird issues where > objects can be left out of a Gemlist chain but still affect it, or > where things just work in ways that are counter-intuitive to how PD > generally works. Certain effects like [pix_motionblur] for example > will affect the Gemlist output even if their branch of the Gemlist > doesn't actually get sent to a texture. For example, in the case of > [pix_motionblur] I had to rig my patch to set it to zero whenever I well, i guess this is something that could do better. anyhow, in the meantime use [pix_separator] to prevent pix-branches to have side-effects on each other. (this could be automated; feel free to create a feature-request; the reason you have to do it manually is performance) in order to prevent openGL-states in different branches to influence each other, use [separator]. this is something that will not be automated, mainly for performance reasons. fmgar- IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] a flawed Gem (Was: Re: pdp/pidip on win32?)
John Harrison wrote: > As promised, here's a couple of patches to show a few of my concerns > about Gem. Interestingly, after creating the patches on the target > machine, I tried the same patches on my laptop and got slightly better > results (recording suddenly started working again and I was able to > avoid one referenced segfault in the patch. I made a note of both of > these changes inside the patch.) > > I'd love to get these concerns addressed and would like to help to > accomplish this in whatever would be most effective. It would be amazing > to really get this tool ready for artists ready to explore this medium > in the classes I teach. no time to check your patches right now, but did you know that there is a separate bug-tracker for Gem? check it out at http://sf.net/projects/pd-gem (if the patches document to separatebugs, please post separate items in the bug-tracker) fgmasr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] dc_blocker
Hi all FYI and as APOC a dc-blocker as suggested by Josh peace/slp #N canvas 122 23 416 538 10; #X text 11 35 y(n) = x(n) - x(n-1) + R*y(n-1); #X obj 18 269 outlet~; #X obj 19 170 inlet~; #X text 11 8 http://www.dsprelated.com/dspbooks/filters/DC_Blocker.html ; #X obj 188 104 bang~; #X obj 18 133 table \$0-out 64; #X obj 17 102 table \$0-in 64; #X obj 18 199 tabsend~ \$0-in; #X obj 18 231 tabreceive~ \$0-out; #X obj 188 192 until; #X obj 188 256 f; #X obj 220 256 + 1; #X obj 241 157 0; #X obj 128 363 t f f; #X obj 126 397 -; #X obj 126 447 +; #X obj 158 447 * 0.995; #X obj 188 281 t f f; #X obj 128 321 tabread \$0-in; #X obj 186 483 tabwrite \$0-out; #X text 32 493 s...@2008; #X obj 188 165 64; #X obj 188 134 t b b; #X connect 2 0 7 0; #X connect 4 0 22 0; #X connect 8 0 1 0; #X connect 9 0 10 0; #X connect 10 0 11 0; #X connect 10 0 17 0; #X connect 11 0 10 1; #X connect 12 0 10 1; #X connect 13 0 14 1; #X connect 13 1 14 0; #X connect 14 0 15 0; #X connect 15 0 16 0; #X connect 15 0 19 0; #X connect 16 0 15 1; #X connect 17 0 18 0; #X connect 17 1 19 1; #X connect 18 0 13 0; #X connect 21 0 9 0; #X connect 22 0 21 0; #X connect 22 1 12 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] dc_blocker
Hallo, Steffen Leve Poulsen hat gesagt: // Steffen Leve Poulsen wrote: > FYI and as APOC a dc-blocker as suggested by Josh You could also do this by implementing the transfer function directly using rzero~ and rpole~, see attached. But generally a [hip~ 5] is good as well. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ dc_block~.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] dc_blocker
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: > You could also do this by implementing the transfer function directly > using rzero~ and rpole~, see attached. But generally a [hip~ 5] is > good as well. Ups, in the example patch, the [hip~ 5] should be after the [sig~] of course. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ dc_block~.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] pdp capture from built-in iSight on MacBook with os X 10.4.11?
Running Pd-extended 0.40.3 on Intel MacBook os X 10.4.11. [pdp_ieee1394] captures video from firewire webcam no problem. Is there a way however to capture video from the built-in iSight camera using pdp on these machines? I know I could capture with Gem but am wondering if something might exist natively in pdp for this on OS X. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended windows typo bug
I am not sure I understand everything. I think you mean "type" instead of "typo", but I don't know what a "different police size" is. It sounds to me like there are font/type problems on Windows. Do you have any screenshots? A bug report would be useful too, with as much detail as possible, plus any example patches and images. .hc On Dec 28, 2008, at 5:29 AM, Nicolas Montgermont wrote: > Hi Hans & list, > > I used the last release (0.40.3) of pd-extended last week on a > windows XP. > Sometimes, the typos are totally messed up : > > I figured out that this was due to the use of different police size in > the main patch and in abstractions. > The bug happens only when you open an abstraction with a different > police size. Here all the polices are smaller that they should be. > When you close the abstraction and come back to the main patch, the > text > goes out of the boxes and the dragging selection tool does not > correspond to the position of the mouse pointer. > > Using the same typo size everywhere corrects the problem. > > I prefer to post even I've not so much precisions (no more acces to a > windows machine), cause this makes pd very difficult to use when you > don't find the solution. > This doesn't seem to happen with precedent releases. > > Hope this can help, > > Nicolas > -- > http://nim.on.free.fr > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd extended windows typo bug
sorry bad translations: "typos" and "police" both refer to "font". is the bug clear now? n Hans-Christoph Steiner a écrit : > > I am not sure I understand everything. I think you mean "type" > instead of "typo", but I don't know what a "different police size" is. > > It sounds to me like there are font/type problems on Windows. Do you > have any screenshots? A bug report would be useful too, with as much > detail as possible, plus any example patches and images. > > .hc > > On Dec 28, 2008, at 5:29 AM, Nicolas Montgermont wrote: > >> Hi Hans & list, >> >> I used the last release (0.40.3) of pd-extended last week on a >> windows XP. >> Sometimes, the typos are totally messed up : >> >> I figured out that this was due to the use of different police size in >> the main patch and in abstractions. >> The bug happens only when you open an abstraction with a different >> police size. Here all the polices are smaller that they should be. >> When you close the abstraction and come back to the main patch, the text >> goes out of the boxes and the dragging selection tool does not >> correspond to the position of the mouse pointer. >> >> Using the same typo size everywhere corrects the problem. >> >> I prefer to post even I've not so much precisions (no more acces to a >> windows machine), cause this makes pd very difficult to use when you >> don't find the solution. >> This doesn't seem to happen with precedent releases. >> >> Hope this can help, >> >> Nicolas >> -- >> http://nim.on.free.fr >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > -- http://nim.on.free.fr ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd extended: .bak extensions for pdp and pidip on OS 10.4?
It was a mistake, I think it is already fixed, but it would be good to check it to be sure or file a bug report. .hc On Dec 28, 2008, at 10:23 PM, John Harrison wrote: > I've been trying pdp/pidip on Pd-extended 0.40.3 and many objects > for those libraries will not create...I think largely because all of > the help files in 5.reference/pdp and 5.reference/pidip end in .bak. > This breaks things like pdp_help_input and pdp_help_output. Is there > a reason all of these files end in .bak or is this just a mistake we > can easily fix for the nightly autobuilds? > > -John > ___ > 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] pdp capture from built-in iSight on MacBook with os X
I haven't done much video, but I have the same set up you have, and the iSight "just works," with [pdp_ieee1394] in example patches. The iSight is on the firewire bus, I guess. oops, it just crashed! Have fun! Collin > Message: 5 > Date: Mon, 29 Dec 2008 08:44:32 -0600 > From: "John Harrison" > Subject: [PD] pdp capture from built-in iSight on MacBook with os X > 10.4.11? > To: PD-List > Message-ID: > <7aa995dd0812290644w1569d981qccb54d203...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Running Pd-extended 0.40.3 on Intel MacBook os X 10.4.11. > [pdp_ieee1394] > captures video from firewire webcam no problem. Is there a way > however to > capture video from the built-in iSight camera using pdp on these > machines? I > know I could capture with Gem but am wondering if something might > exist > natively in pdp for this on OS X. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [GEM] pix_record trouble
Hello, I have two patches: In one of them I am playing something with pix_film and I can record a movie test.mov with no problems. In the other one I have a video captured live, some processing and now pix_record grabs only one frame with a green mask (blended with the image) and coordinate distorition. It is in auto mode... anyone has had this problem? I am in GEM cvs 0.91, pd 0.41-4, fc8 J -- Jaime E Oliver LR joliv...@ucsd.edu www.realidadvisual.org/jaimeoliver www-crca.ucsd.edu/ www.realidadvisual.org 858 202 1522 9168 Regents Rd. Apt. G La Jolla, CA 92037 USA ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] Otherside server alive again
The Otherside server has been repaired once again and is now fully functional. Since it is built from scraps taken from many different and most importantly, OLD computers, it will most likely fail again in the future. Do not fear, most of the functionality is mirrored. http://otherside.servebeer.com - Original, fully functional http://otherside.gnufunk.org - Mirror, contains most of the important stuff. http://netpd.org/~ilias - APT mirror only here Good luck!! Millions of thanks to everyone who has helped to keep this going by donating computer parts, server-space, beer, and so on.. -Ilias ___ 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
[PD] [PD-announce] pd 0.42-0 test 08 released
Hi all, Pd 0.42-0 test 08 is out on the usual http://crca.ucsd.edu/~msp/software.html and on subversion in SourceForge. I'm hoping to finalize it next weekend - bug reports welcome. cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Nice distortion
Frank Barknecht wrote: > Hallo, > > oops, I sent a version with a missing connectin to the rpole~ > coefficient. Please use this one instead. > > Ciao > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > I've been having a blast with this effect -- really great, Frank! It doesn't seem too CPU-hungry, either, though that's just an impression not yet quantified. One little thing...the meaning of wet/dry seems to be reversed; i.e. 0 gives full effect, 1 gives no effect. Thanks for making this available. Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
