Pd-list April 2010

pd-list@lists.iem.at

143 participants
284 discussions

Pd gem patch crashes when pushing ctrl+w
by Blinge 06 Apr '10

06 Apr '10

Hi there ppl. I have some problems with a patch. I cant find how it crashes when i try ctrl+w Â¿Can anyone help me to check that? There are no error msgs. Using: gem Pd version 0.41.4-extended on ubuntu 9.10 and 10.04

3 2

GEM: videos with alpha in MacOS?
by Matteo Sisti Sette 06 Apr '10

06 Apr '10

Hi, I try asking again, just in case my previous message has not been read because it was too long. Is there a way to have alpha working with [pix_film] on Mac? That is, read RGBA video files with some transparency (i.e. nontrivial alpha channel) on Mac without ignoring the alpha channel? This works on Windows: [gemhead] | [alpha] | [pix_film] | [pix_texture] | [rectangle] However, on Mac the whole pix is 100% opaque no matter what's in the alpha channel of the video file... thanks m. -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com

4 5

pidip qt problem
by t'es in t'es bat 06 Apr '10

06 Apr '10

hello i'm now on snow leopard and i got a pdp_yqt: unsupported video codec it's the same with pdp_qt... any solutions ???? david -- TNTB t'es in t'es bat 7 place Favier 13210 St Remy de Provence T/: 04 90 26 95 09 P/: 06 86 86 12 19 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| http://www.tntb.net LOVES LePôle travaille sur le fil des accidents, des fractures, des bugs informatiques, vidéos. -]>[-]<<[>+>+<<-]>>[<<+>>-]>>> Lepôle cherche , il cause il triture les matières, les bits, les glitch, les formats. Il sort des cadres. [-]<<<+++++++++<[>>>+<<[>+>[-]<<-]>[<+>-]>[<<++++++++++>>>+< LePôle s'indiscipline dans de multiples tentatives fragile et poetiques. -]<<-<-]+++++++++>[<->-]>>+>[<[-]<<+>>>-]>[-]+<<[>+>-<<-]<<< LePôle improvise avec ses valises pleine de machines improbables et généreuse en surprises visuelles... -]<<-<-]+++++++++>[<->-]>>+>[<[-]<<+>>>-]>[-]+<<[>+>-<<-]<<< LePôle = numerikexperimentatatonnedebitengigaemotionel ////////////////////////////////////////////////////////////////////////// 00000000000000 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ LePôle works on the edge of faults, errors and informatic bugs and videos >+++++++++[<+++++++++++>-]<[>[ -]>[-]<<[>+>+<<-]>>[<<+>>-]>>> LePôle looks for, causes, fiddles with bytes, glitches and formats. Something out of the ordinary. [-]<<<+++++++++<[>>>+<<[>+>[-]<<-]>[<+>-]>[<<++++++++++>>>+< LePôle is undisciplined in many endeavours fragile and poetic -]<<-<-]+++++++++>[<->-]>>+>[<[-]<<+>>>-]>[-]+<<[>+>-<<-]<<< LePôle improvises with its suitcases full of unlikely machines and visual surprises... -]<<-<-]+++++++++>[<->-]>>+>[<[-]<<+>>>-]>[-]+<<[>+>-<<-]<<< LePôle =digitalexperimentationofemotionalgigabytes //////////////////////////////////////////////////////////////////////////

4 10

Project with Pure Data on Embedded device
by Nyamiou Le Galéanthrope 06 Apr '10

06 Apr '10

Hello everyone, I'm on a project of augmented reality, planning to use audio and video effects which will depends of some sensors. The project will use an embedded device made with a Beagleboard (see : beagleboard.org). I know well languages like C, C++, Java but I know nothing of computer music and Pure Data. I'm asking if Pure Data is enough robust and enough fast to be run several hours on a embedded device without problems, I'm also asking if it is hard and long to learn Pure Data because if I'll use it, I will not have much time to learn it. Oh, and can I compile Pd and GEM on a ARM processor ? Thanks.

2 1

dynamic gui masking problem
by Mathieu Bouchard 06 Apr '10

06 Apr '10

> By using [canvasdelete] from the iemguts. It allows to delete certain > objects of a certain canvas by their index number (for instance, 'delete > 12'). The canvas needs a [canvasdelete] in order to add the 'delete' > method to the canvas and a [sendcanvas] to which the 'delete <id>' > message is sent. How do you intend to manage those numbers from Pd without ever getting mixed up ? > Then I ran into another problem: I was creating [cnv] objects in a GOP > and moving them out of the GOP area, which is a way to display something > in the parent patch outside the GOP area. However, when deleting such > gui objects, they remain visible in the parent (as if the parent > wouldn't be refreshed). Why do you want to rely on a bug ? _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

2 1

Re: [PD] pd and multi-core processors
by vedran 06 Apr '10

06 Apr '10

Thanks for the extensive description of the solution. I'm currently working with vvvv on win7 but I'm osx user and this is the main reason why I'd like to switch to pd+gem. I'll work on visual output only, so I won't do any dsp (there is a plan for future but lets not think about it). vvvv also uses only one core per instance (without a solution to somehow split process in one instance) and my current project is quite heavy to handle it this way. There is a solution as with pd, to run two or more instances who communicate and leave the system to handle the multicore spliting. I'll try pd+gem anyway just to see how it will work... thanks, vedran ..................................................... vedran kolac ..................................................... gTalk - vedran.kolac(a)gmail.com ..................................................... skype - vedrankolac ..................................................... +385 (0) 91 567 07 17 ..................................................... http://www.onoxo.net http://www.projectmoe.net ..................................................... On Mon, Apr 5, 2010 at 8:43 PM, Matteo Sisti Sette < matteosistisette(a)gmail.com> wrote: > (this is a little OT respect to the thread) > > > > nicely enough, pd's graphical interface and the actual process, > > are separate threads, > > The communication between the engine of Pd ("Pd") and the graphical > interface ("GUI") is not as efficient as you may expect it to be - at least > not as much as I expected it to be. > > When you send a message to a GUI object, such as for example a "set" > message to the receive-symbol of a slider, the Pd process sends a message to > the GUI process and the GUI process actually redraws what it has to redraw: > so the Pd process is not "blocked" while all the (embarassingly cpu > consuming) draw operation is performed. So you would expect that the time > needed to send a message to a GUI object is just the time needed to send a > message through a TCP socket. > > Not quite so. > I don't know why, but when you send a message to a GUI object it takes > significantly much more CPU time to the Pd process than simply sending a > message through TCP, though much less than it takes to actually redraw > things. I _guess_ the Pd process probably waits for some kind of > aknowledgement or respose from the GUI process or something like that, but > this is only a guess. > > I found this out because I create patches that have to be used "on the > stage" by users that are not "pd-ers", so I make extensive use of GUI. All > significant parameters or values that can be changed and/or need to be > monitored are displayed on the GUI. So I send a lot of messages to the GUI. > I also store "snapshots" of configuration that are then called (_not_ loaded > from disk at the moment of calling them), so there often are "massive" > bursts of messages to a lot of GUI objects in zero logical time (I already > reduced the messages to only the actually needed ones). So, soon I began to > have a lot of audio dropouts. > > So I tried out a solution that seemed ridiculous at first: I made an > "engine" patch which does all the audio and midi stuff but has no GUI, and > an "interface" patch that has only the GUI stuff, and exchanges control data > (in both senses of course) with the engine patch. And obviously I run them > on two different instances of Pd. > > My "protocol" of communication between the two patches is not even very > optimized, so I send a lot of messages that could actually be avoided (don't > tell anybody). > Well with this system, despite the huge quantity of messages to and from > GUI, I get no dropouts at all, everything works fine. > > I have indeed replicated "at the patch level" the engine-GUI architecture > that is already implemented in Pd. When I did it, I really was afraid that I > was doing something stupid; but it did work, and it makes an enormous > difference (well I did do some test before, that seemed to indicate that it > may work). > So the time it takes (meaning the time during which the Pd process is > either blocked or busy) to send a message through a [netsend] (with even a > little overhead: passing through a [s] and a [r], a [list prepend send] and > a [list trim] at the very least) is significantly less than the time it > takes to send a message to a GUI object. > > I am curious to know whether this overhead in the communication between the > two processes of Pd is entirely necessary (to robustly guarantee consistency > for example) - and in case it is not, whether it is going to be addressed in > the gui-rewrite...... > > -- > Matteo Sisti Sette > matteosistisette(a)gmail.com > http://www.matteosistisette.com > > _______________________________________________ > > Pd-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >

1 0

Re: [PD] 24 bit / 96 k issue
by András Murányi 05 Apr '10

05 Apr '10

OK, for latest version you shall have (a self-built one from CVS or) the latest autobuild from http://autobuild.puredata.info/auto-build/latest/ As i hardly ever do audio in Pd i only have this vague memory from the list that [readanysf] has recently undergone much development and is very capable when it comes to massive WAV files. Andras On Sun, Apr 4, 2010 at 9:21 PM, David Schaffer <schafferdavid(a)hotmail.com>wrote: > I'm on WIn XP, latest version of PD extended and I'm loading the file with > soundfiler and wrinting it to two arrays. The file is 24bits 96Khz stéréo. > THe same object reads 16bits 44.1 khz without a problem. > > Thanks > > David > > > > http://www.flickr.com/photos/schafferdavid/ > > http://audioblog.arteradio.com/David_Schaffer/ > > > > > ------------------------------ > From: muranyia(a)gmail.com > Date: Sat, 3 Apr 2010 23:49:56 +0200 > To: pd-list(a)iem.at > Subject: Re: [PD] 24 bit / 96 k issue > > > > > On Sat, Apr 3, 2010 at 11:41 PM, David Schaffer <schafferdavid(a)hotmail.com > > wrote: > > Hi there, > > I'm trying to use 96 k/24 bits WAV file in pd for the first time and > something weird is happening: when I open such a file, I get an "no such > oject" error in the console, althou I haven't put any unknown object in my > patch, then, some GUI elements freeze (knobs, faders...) and I can't use my > patch anymore (but the sound seems to play). "Find last error" doesn't lead > me anywhere. > Can anyone telle me what's going on or explain me how one to deal with 96k > 24 bits sounds in Pd (setup changes, soundcard settings...) I've noticed > that switching pd to 96k mode in Pd doesn't affect my ASIO soundcard's > settings (it stil shows 16bits, 44100 hz) so I'm kind of mixed up... > > Thank you > > D.S > > > > Hello David, > > which Pd version, which version of Windows or OSX are you using and which > object are you trying to load the WAV with? > > Andras > > ------------------------------ > Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up > now. <https://signup.live.com/signup.aspx?id=60969> > -- Muranyi Andras

2 1

[PD-announce] vinyl tracking externals
by komika 05 Apr '10

05 Apr '10

hi list we have released some externals for timecoded vinyl tracking for pure data. It is all still in development but it would be great if some people could test the externals and give us some feedback. So if you know anyone who could be interested please tell them. You can find the externals here http://www.komika.org/komika/overview/time_tunnelxl/50950 By the way could anyone help compiling the project on other platforms then osx? linux and windows would be great! Thanks for any help cheers komika _______________________________________________ Pd-announce mailing list Pd-announce(a)iem.at http://lists.puredata.info/listinfo/pd-announce

1 0

Re: [PD] pd and multi-core processors
by Matteo Sisti Sette 05 Apr '10

05 Apr '10

(this is a little OT respect to the thread) > nicely enough, pd's graphical interface and the actual process, > are separate threads, The communication between the engine of Pd ("Pd") and the graphical interface ("GUI") is not as efficient as you may expect it to be - at least not as much as I expected it to be. When you send a message to a GUI object, such as for example a "set" message to the receive-symbol of a slider, the Pd process sends a message to the GUI process and the GUI process actually redraws what it has to redraw: so the Pd process is not "blocked" while all the (embarassingly cpu consuming) draw operation is performed. So you would expect that the time needed to send a message to a GUI object is just the time needed to send a message through a TCP socket. Not quite so. I don't know why, but when you send a message to a GUI object it takes significantly much more CPU time to the Pd process than simply sending a message through TCP, though much less than it takes to actually redraw things. I _guess_ the Pd process probably waits for some kind of aknowledgement or respose from the GUI process or something like that, but this is only a guess. I found this out because I create patches that have to be used "on the stage" by users that are not "pd-ers", so I make extensive use of GUI. All significant parameters or values that can be changed and/or need to be monitored are displayed on the GUI. So I send a lot of messages to the GUI. I also store "snapshots" of configuration that are then called (_not_ loaded from disk at the moment of calling them), so there often are "massive" bursts of messages to a lot of GUI objects in zero logical time (I already reduced the messages to only the actually needed ones). So, soon I began to have a lot of audio dropouts. So I tried out a solution that seemed ridiculous at first: I made an "engine" patch which does all the audio and midi stuff but has no GUI, and an "interface" patch that has only the GUI stuff, and exchanges control data (in both senses of course) with the engine patch. And obviously I run them on two different instances of Pd. My "protocol" of communication between the two patches is not even very optimized, so I send a lot of messages that could actually be avoided (don't tell anybody). Well with this system, despite the huge quantity of messages to and from GUI, I get no dropouts at all, everything works fine. I have indeed replicated "at the patch level" the engine-GUI architecture that is already implemented in Pd. When I did it, I really was afraid that I was doing something stupid; but it did work, and it makes an enormous difference (well I did do some test before, that seemed to indicate that it may work). So the time it takes (meaning the time during which the Pd process is either blocked or busy) to send a message through a [netsend] (with even a little overhead: passing through a [s] and a [r], a [list prepend send] and a [list trim] at the very least) is significantly less than the time it takes to send a message to a GUI object. I am curious to know whether this overhead in the communication between the two processes of Pd is entirely necessary (to robustly guarantee consistency for example) - and in case it is not, whether it is going to be addressed in the gui-rewrite...... -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com

1 0

Re: [PD] Displaying as two digits
by Ben Baker-Smith 05 Apr '10

05 Apr '10

>Hey All >I'm working on a game on PD. Part of which is a timer set out minutes:seconds. However, when the seconds variable is below 10 it's >displaying as a single digit. So most of the time this looks right (e.g. 2:56), but at the start of each minute it looks a little unusual (0:1). I'm >displaying this using [text3d]. >Any ideas how I can fix this? >Andrew I'm not sure where / how you're displaying the timer, but you could convert to a symbol. See the attached patch for 2 examples. -Ben

1 1

← Newer
1
...
21
22
23
24
25
26
27
28
29
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 April 2010