Pd-list November 2009

pd-list@lists.iem.at

129 participants
189 discussions

[PD-announce] [RjDj] The New York reactive music experience
by Frank Barknecht 30 Nov '09

30 Nov '09

RjDJ News item - Friday, November 27th, The New York reactive music experience We finally managed to jump over the big pond and will land in New York with the premier of our new child the RJC-1000 [1] on the 11th of December and an RjDj workshop on the 12th of December. Both events will be kindly hosted by our friends at Eyebeam [2]. So all you RjDj lovers in New York, it would be great meeting you at the first Reactive Music Experience in New York. The RJC-1000 is our top secret project that we were working on for the last couple of months and which we will release soon. We will present the software on the 11th and also play it live on the event. This is good news for everyone interested in creating his own RjDj scenes. In the workshop on the 12th of december we will also give deeper insights into how to use PD to create RjDj scenes. Check out the New York experience page for more details about the event: http://eyebeam.org/events/rjdj-new-software-release-party Yours, Michael Breidenbruecker [1] http://more.rjdj.me/rjc1000/ [2] http://eyebeam.org/events/rjdj-new-software-release-party _______________________________________________ Pd-announce mailing list Pd-announce(a)iem.at http://lists.puredata.info/listinfo/pd-announce

1 0

Netsend/receive crashes
by matthem5＠vt.edu 29 Nov '09

29 Nov '09

We have discovered an issue with the netsend and/or netreceive objects. If a patch which is sending of receiving network data is closed with the connection still open and transmitting/receiving data at a high rate, it seems that the connection is sometimes not closed properly. If the same patch is reopened without closing PD sometimes the connection claims to be valid, as in it gives the error "error: netsend_connect: already connected", but data will not transmit and closing the patch crashes PD. What could be causing the patch to close improperly? If you would like to try to recreate the error, I have included the text version of our test patch. After opening the patch, connect the netsend object and the toggle the metro on to send data. Without doing anything else to the patch, simply close it with the X in the top right corner. Then reopen the patch, without quitting PD and trying to connect the netsend object again. When we did this, it sometimes gave us an error and closing the patch killed PD. Sometimes it took a few times closing and reopening the patch for this to occur. Could this be a race condition when freeing objects in a patch? Any help would be greatly appreciated, thank you. Our test patch: #N canvas 568 250 450 300 10; #X obj 105 179 netsend 1; #X obj 237 113 + 1; #X msg 237 91 1; #X floatatom 268 161 5 0 0 0 - - -; #X obj 300 19 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 147 144 prepend send; #X obj 101 207 netreceive 9997 1; #X obj 100 234 prepend set; #X msg 103 264 7101; #X obj 282 55 metro 10; #X msg 110 36 connect localhost 9997; #X connect 1 0 3 0; #X connect 1 0 5 0; #X connect 2 0 1 0; #X connect 3 0 1 1; #X connect 4 0 9 0; #X connect 5 0 0 0; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 9 0 2 0; #X connect 10 0 0 0;

2 1

Re: [PD] problem with MIDI (linux)
by chi ball 29 Nov '09

29 Nov '09

> iirc, you should use the same user to start jackd and Pd. > so if you run Pd as user "chi", than you should also run jackd as user >"chi". the same if you use root (which i don't recommend; you should >rather fix your /etc/security/limits.conf to be able to run realtime >processes as member of the audio-group). Thanks.. I've resolved the problem of "user" adding (as root) those rows in /etc/security/limits.conf: @audio - rtprio 80 @audio - memlock 288000 #288000 because my RAM is 576 MB @audio - nice -10 and I set user in "audio" member group. _______________________ In JACK setup I set: realtime, priority 80 midi driver: seq _______________________ So now I can open qjackctl and start JACK correctly (play), but give me this error: cannot use real-time scheduling (FIFO at priority 90) [for thread -1238557840, from thread -1238557840] (1: Operation not permitted) Now I open pd, and in "media" I select: JACK, and ALSA-MIDI. Then I open JACK connections: I see 2 windows: AUDIO and MIDI. Here, in both windows, I connect pd with my SB LIVE! sound card. ____________________________________________ Now, running some patch in pd, happen this: 1)in a audio patch (for example a simple oscillator with a slide..) *I can listen sound correctly* (even if with a fastidious background noise) and I can change frequency well with the slide. 2)in a midi patch (a patch certainly correct, tested in o.s. Windows..!) *I can't listen anything*. I see numbers change, but *no sound*. PD give me this error: audio I/O error history: seconds ago error type 1.39 A/D/A sync 3.25 A/D/A sync 3.28 A/D/A sync 3.37 A/D/A sync 3.38 A/D/A sync (..etc..etc..similarly) Thank you in advance, cb _________________________________________________________________ Carica e scarica in un clic. Fino a 25 GB su SkyDrive http://www.windowslive.it/skyDrive.aspx

3 3

Blending mode directly on objects, not pixes?
by Matteo Sisti Sette 29 Nov '09

29 Nov '09

Hi, Now, I don't know if this is possible at all. Suppose I have a [rectangle] (or whatever primitive indeed) with a texture, and something behind the rectangle. Is it possible to have the rectangle "blend" with the background with some blending mode (such as add, multiply, etc)? (without having to render all the rest of the scene except the rectangle into a texture via gemframebuffer, and then blending the two textures with pix_add and friends)??? Isn't it a matter of shaders? I guess it could be achieved using openGL functions... but is there a "simple" way? Thanks m. -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com

5 28

Re: [PD] Finding "$0" and dealing with it in messages
by Frank Barknecht 29 Nov '09

29 Nov '09

Hallo, jurgen hat gesagt: // jurgen wrote: > Didn't see an article about messages... please try to point to the article. It's here: http://puredata.info/dev/PdMessages Or search for "messages". Ciao -- Frank

1 0

Dynamically move object boxes
by William Brent 29 Nov '09

29 Nov '09

Hi all, Can someone point me in the right direction for how to move elements in a patch dynamically? I need the positions of some comments, bangs, and sliders to be shuffled now and then. Thanks... William -- William Brent www.williambrent.com “Great minds flock together” Conflations: conversational idiom for the 21st century www.conflations.com

3 4

pix_snap CPU consumption question
by Matteo Sisti Sette 27 Nov '09

27 Nov '09

Hi, I have a [pix_snap 0 0 2400 2400] 'under' a [gemframebuffer] of the same size. I think it would make no difference if there wasn't the [gemframebuffer] and the [gemwin] had the same size (namely 2400 by 2400). I attach the patch I'm using, though a much simpler test patch could be used to illustrate the question. Now, I am observing the following: - despite the large size of the framebuffer, even when pix_snap is continuously receiving the gemlist, CPU consumption is low, not significantly higher than the same patch with a smaller window size - When I send one bang to pix_snap (by enabling the spigot above it which immediately disables itself), so that it takes a snapshot, then CPU consumption increases, and then it stays high forever!!! I'm not surprised by the sudden CPU consumption increase: I'm surprised by the fact that then it doesn't immediately go back to its previous level: cpu consumption stays high, as if, starting from the moment the firse snaphot is taken, pix_snapshot had to continuously process the picture or something. Is it normal??? I don't really understand why there should be a difference between the cpu consumption before and after the moment the snapshot is taken. I could understand a temporary increase _during_ the moment the snapshot is taken. If I disconnect the left inlet of pix_snapshot so it does not receive the gemlist anymore, then CPU consumption drops again. That wouldn't be that much surprising if it wasn't that after disconnecting the inlet of pix_snap, the image is still displayed. So, it means pix_snap does not need to "output" the image continuously (no surprise here either), but then, what is it continuously doing when receiving the gemlist and NOT capturing, that makes it consume CPU?? It seems that, whatever it is, it is useless. Is it a bug? Or is there an explanation? (well the two things are not mutually exclusive) -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com #N canvas 9 18 1246 745 12; #X obj 788 659 gemwin; #X msg 740 558 dimen 800 600 \, create \, 1; #X msg 796 608 destroy; #X obj 100 194 gemframebuffer; #X obj 166 114 loadbang; #X obj 99 292 t a a a a; #X obj 99 251 translateXYZ 0 0 -4; #X obj 661 540 separator; #X obj 596 680 pix_texture; #X obj 596 716 square 4 4; #X obj 351 458 separator; #X obj 349 503 t a b; #X obj 386 539 spigot; #X obj 383 572 t b b; #X obj 432 510 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X msg 472 547 0; #X obj 344 693 pix_texture; #X obj 408 391 s mainchain; #X obj 140 366 separator; #X obj 160 448 spigot; #X obj 210 425 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X msg 250 462 0; #X obj 126 548 t a b; #X obj 126 621 t b a; #X obj 45 491 loadbang; #X msg 19 519 file aaa 95; #X obj 42 18 gemhead 50; #X obj 1092 507 gemhead 52; #X obj 1101 667 pix_texture; #X obj 1095 707 square 4 4; #X obj 1044 137 r mainchain; #X obj 1043 206 pix_video; #X obj 1040 236 pix_info ----------; #X obj 1079 293 -; #X obj 1078 324 / 2; #X obj 1038 359 pix_crop; #X obj 1044 170 separator; #X obj 1036 386 pix_texture; #X obj 1121 423 s videotexture; #X obj 378 13 r mainchain; #X obj 381 66 separator; #X obj 379 93 pix_texture; #X obj 460 60 r videotexture; #X obj 607 8 r mainchain; #X obj 617 71 separator; #X obj 618 101 pix_texture; #X obj 699 68 r videotexture; #X obj 354 193 r mainchain; #X obj 354 252 separator; #X obj 355 273 pix_texture; #X obj 436 240 r videotexture; #X obj 593 201 r mainchain; #X obj 592 255 separator; #X obj 594 281 pix_texture; #X obj 675 248 r videotexture; #X obj 337 350 square 2 2; #X obj 361 140 translateXYZ -2 -2 0; #X obj 600 148 translateXYZ 2 -2 0; #X obj 337 320 translateXYZ -2 2 0; #X obj 576 328 translateXYZ 2 2 0; #X obj 360 167 square 2 2; #X obj 601 177 square 2 2; #X obj 576 356 square 2 2; #X obj 349 43 spigot; #X obj 326 5 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1 ; #X obj 616 43 spigot; #X obj 718 1 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1 ; #X obj 358 224 spigot; #X obj 460 188 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 608 232 spigot; #X obj 710 196 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 161 487 t a b; #X obj 41 45 t a a; #X obj 101 91 spigot; #X obj 13 172 spigot; #X obj 153 15 r recmode; #X obj 35 123 * -1; #X obj 34 147 + 1; #X obj 1090 588 spigot; #X obj 1112 557 r recmode; #X obj 970 435 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 970 455 s recmode; #X msg 166 143 dimen 2400 2400; #X obj 126 589 pix_snap 0 0 2400 2400; #X obj 128 649 pix_write 0 0 2400 2400; #X obj 918 371 loadbang; #X msg 920 404 1; #X obj 346 663 pix_snap 0 0 2400 2400; #X obj 544 420 r recmode; #X obj 545 447 select 1 0; #X msg 511 484 2400 2400; #X msg 478 487 0 0; #X msg 563 536 600 600; #X msg 508 537 100 0; #X text 944 558 <- 1)HERE; #X text 742 -2 <- 2) any of these 4 \, or all; #X text 457 504 <- 3) TAKE THE PICTURE: observe cpu increase; #X text 740 13 <- 4) (opt) turn them off if you want to see the snapshot ; #X text 352 608 <- 5) if you disconnect this \, CPU consumption drops ; #X text 393 625 but the image is still displayed; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 6 0; #X connect 3 1 28 1; #X connect 4 0 82 0; #X connect 5 0 18 0; #X connect 5 1 10 0; #X connect 5 2 17 0; #X connect 5 3 7 0; #X connect 6 0 5 0; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 10 0 11 0; #X connect 11 0 87 0; #X connect 11 1 12 0; #X connect 12 0 13 0; #X connect 13 0 87 0; #X connect 13 1 15 0; #X connect 14 0 12 1; #X connect 15 0 14 0; #X connect 16 1 8 1; #X connect 18 0 19 0; #X connect 19 0 71 0; #X connect 20 0 19 1; #X connect 21 0 20 0; #X connect 22 0 83 0; #X connect 22 1 83 0; #X connect 23 0 84 0; #X connect 23 1 84 0; #X connect 24 0 25 0; #X connect 25 0 84 0; #X connect 26 0 72 0; #X connect 27 0 78 0; #X connect 28 0 29 0; #X connect 30 0 36 0; #X connect 31 0 32 0; #X connect 32 0 35 0; #X connect 32 1 33 0; #X connect 32 2 33 1; #X connect 32 2 35 1; #X connect 32 2 35 2; #X connect 33 0 34 0; #X connect 34 0 35 3; #X connect 35 0 37 0; #X connect 36 0 31 0; #X connect 37 1 38 0; #X connect 39 0 63 0; #X connect 40 0 41 0; #X connect 41 0 56 0; #X connect 42 0 41 1; #X connect 43 0 65 0; #X connect 44 0 45 0; #X connect 45 0 57 0; #X connect 46 0 45 1; #X connect 47 0 67 0; #X connect 48 0 49 0; #X connect 49 0 58 0; #X connect 50 0 49 1; #X connect 51 0 69 0; #X connect 52 0 53 0; #X connect 53 0 59 0; #X connect 54 0 53 1; #X connect 56 0 60 0; #X connect 57 0 61 0; #X connect 58 0 55 0; #X connect 59 0 62 0; #X connect 63 0 40 0; #X connect 64 0 63 1; #X connect 65 0 44 0; #X connect 66 0 65 1; #X connect 67 0 48 0; #X connect 68 0 67 1; #X connect 69 0 52 0; #X connect 70 0 69 1; #X connect 71 0 22 0; #X connect 71 1 21 0; #X connect 72 0 74 0; #X connect 72 1 73 0; #X connect 73 0 3 0; #X connect 74 0 5 0; #X connect 75 0 73 1; #X connect 75 0 76 0; #X connect 76 0 77 0; #X connect 77 0 74 1; #X connect 78 0 28 0; #X connect 79 0 78 1; #X connect 80 0 81 0; #X connect 82 0 3 0; #X connect 83 0 23 0; #X connect 85 0 86 0; #X connect 86 0 80 0; #X connect 87 0 16 0; #X connect 88 0 89 0; #X connect 89 0 90 0; #X connect 89 0 91 0; #X connect 89 1 92 0; #X connect 89 1 93 0; #X connect 90 0 87 2; #X connect 91 0 87 1; #X connect 92 0 87 2; #X connect 93 0 87 1;

1 0

GridFlow binaries for Linux
by Mathieu Bouchard 26 Nov '09

26 Nov '09

Here is a GridFlow 0.9.6 binary as made last week by Patrick Boivin. It was made for Ubuntu 9.10 but it probably works on other OSes as well. It's not a .deb, just a .tar.gz, therefore it'll be less picky about version numbers. http://gridflow.ca/download/packages/ http://gridflow.ca/download/packages/gridflow-0.9.6-ubuntu-karmic-i386.tar.… I would like some feedback about whether it works for you. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

2 1

Re: [PD] Pure Data and Processing
by András Murányi 25 Nov '09

25 Nov '09

Hi Raul, i copy this back to the list as it may interest more people than me. Well, a lot of complicated Windows programs do run on Linux/Wine, and I think it's not unrealistic to imagine a version of your one that is so independent that has no problems with Wine. Of course i'm interested in the Pd and the Processing patches and will be glad if you post them. Thanks, Andras 2009/11/25 raul diaz <raul.lete(a)gmail.com> > Hi András! > > Sorry, but I can't check the application on linux. > I've uploaded a pc version on my website with an .exe, so it's normal you > can't run it on Linux. > If you're interested in the application I can send you both Processing > applet and Pd patch, and I suposse you can compile it and run it on Linux > without problem. > > Let me now if you're interested on that. > > Thanks for your feedback. > > Regards! > > > 2009/11/19 András Murányi <muranyia(a)gmail.com> > >> >> >> On Wed, Nov 18, 2009 at 10:58 AM, raul diaz <raul.lete(a)gmail.com> wrote: >> >>> Hi! >>> >>> You can take a look to my tr909 emulation, which uses Processing for the >>> graphical interface, and Pd for the audio engine: >>> >>> - http://rauldiazpoblete.com/project.php?p1=1&p2=1&lang=en* >>> * >>> I hope that can help you*. >>> * >>> >> >> Hi Raul, >> can i make this run on Linux? Wine starts it up but then Processing says >> it cannot ShellExecute. >> >> Thanks, >> Andras >> >> > > > -- > Raul Diaz Poblete > ************************* > http://rauldiazpoblete.com/ > > raul.lete(a)gmail.com > Barcelona [Spain] >

2 1

PD and equal loudness: any ideas on approaching good live sound?
by Dan Wilcox 25 Nov '09

25 Nov '09

Howdy, I have some questions regarding methods to get optimal live sound in pd. Using my electric guitar, I keep running into situations where the mix and loudness levels vary widely form place to place and system to system. I am used to this happening with regular analog gear, but not with the rather annoying difficulties it adds in pd. I run into feedback problems with the guitar or the mic, the mix sounds weak, etc. I just cannot seem to get a good, consistent live sound when using the electric and a live mic .. *sigh*. So my questions are: What do you guys do for your live set? Do you do some sort of EQ/compression on the final stage before going out the the dac~? I found this post about the ears response to certain frequencies at different sound pressure levels http://gabesrocklog.blogspot.com/2009/08/eq-or-how-to-turn-down-suck-knob.h…. Should I try using these curves on an eq going out? Does anyone know how commercial software deals with this? It seems to me that Logic, Live, etc must have some sort of input/output compensation that I would need to replicate in order to have a more uniform sound across the board? Is this just subjective and /or not possible? Thanks for any ideas ... -------- Dan Wilcox danomatika.com robotcowboy.com

4 4

← Newer
1
2
3
4
5
6
7
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list November 2009