Pd-list May 2007

pd-list@lists.iem.at

160 participants
312 discussions

Re: [PD] future directions for threading in Pd (Was: Re: puredata evolution)
by Mathieu Bouchard 30 May '07

30 May '07

On Wed, 30 May 2007, Phil Stone wrote: > And now to hear it's being thought about in DD...this is so cool! I really > hope it can happen. Please keep us posted on any developments. When I had this discussion I had GridFlow in mind, not DesireData, but I always think about how one idea connects to the rest of what exists, so I always think of possible future expansion. Features of GridFlow that need not be specific to GridFlow, are usually designed to make sense for pd at large, even if those features are still only bundled with GridFlow. Generally, GridFlow is closer to the concepts that are in Pd itself, than other video plugins are. DesireData has been almost on hold since sometime in January. My plan is to resume working on it this week and finish what I already started. This certainly won't include threads. I don't even think that a threaded GridFlow is for 2007. Brainstorming is not a promise of software and a promise of software is not software. (note that even though I post this I have no idea what's been on pd-list since March and I don't expect to read pd-list anytime soon) _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

1 0

Arduino to PD Re: PD-list Digest, Vol 26, Issue 149
by kent straub-jones 30 May '07

30 May '07

Arduino2PD So I am trying the Arduino2PD set up from the Arduino website and the document is hit or miss. It worked last wednesday, and then as soon as I restarted my computer it stopped working. I began recieving Tx-Overruns messages, then I restarted again, and today I am recieving no error messages but its not showing any data being recieved, any help? I have tried the other documents but arduino2pd seems like the easiest way to recieve inputs, and that's all I need to do. kent

2 1

Re: [PD] opencv motion tracker external HELP!
by martin.peach＠sympatico.ca 30 May '07

30 May '07

Alain wrote: > void window_getframe(t_window *x, t_symbol *sym) > { > char* decode; > char symstr; > x->sym->s_name = decode; > symstr = atol(decode); > frame = symstr; > } Is this the receiving function? I would write it more like: void window_getframe(t_window *x, t_symbol *sym) { IplImage * frame; frame = (IplImage *)atol(sym->s_name); } Martin

1 0

Fwd: Re: hid compiling problem.
by Diego Azar 30 May '07

30 May '07

Note: forwarded message attached. --------------------------------- Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.

1 0

Re: [PD] opencv motion tracker external HELP!
by nosehair911＠bellsouth.net 30 May '07

30 May '07

Martin, Thanks for all your help. I have a final question about the sprintf solution. I have managed to get the out going(I think) but I am not quite undestanding the atol()inlet part. I have this. void window_getframe(t_window *x, t_symbol *sym) { char* decode; char symstr; x->sym->s_name = decode; symstr = atol(decode); frame = symstr; } But I get invalid conversion from 'char' to "IplImage*'. I have to read some more. If I used sprintf to write to an array a string/image formatted as a pointer and then turned that pointer to a symbol, how do i now convert the symbol back to a pointer of the original image, which I assume should still be in buffer? Alain > You can only work with atoms in pd's message system, and each atom usually contains a bang, a float or a symbol. You could convert the pointer to a float but it probably won't work because the pointer is a large integer that won't be accurately represented as a float. You could convert the pointer to a symbol using something like: > char symstr[10]; > t_symbol sym; > sprintf(symstr, "%p", frame); > sym = gensym(symstr); > ...then send sym through the outlet and convert it back to a pointer at the receiving end by extracting the string from the s_name field of the symbol and passing it to atol(). > > Martin >

1 0

M$ invents the reacTable
by Cesare Marilungo 30 May '07

30 May '07

http://money.cnn.com/2007/05/30/technology/microsoft.reut/index.htm?cnn=yes c. -- http://www.cesaremarilungo.com

1 0

Re: [PD] Opencv & pd
by martin.peach＠sympatico.ca 30 May '07

30 May '07

IOhannes m zmoelnig wrote: > i thought that you should integrate your openCV objects into Gem and not > brew your own objects. I too would like to make some objects in Gem. I have already done some openGL externals for max/msp (see lifeGL and lifeTorus at http://www.billvorn.concordia.ca/menuall.html) and would like to port them to pd. It seems the alternatives are to set a tcl/tk drawable as openGL, or Gem. Is there any documentation about the Gem API or is it all in the Gem source? Martin

1 0

"Theory and Techniques" book available from World Scientific Press
by Miller Puckette 30 May '07

30 May '07

Hi all, The book, Theory and Techniques of Electronic Music, is now available on paper from World Scientific Press: http://www.worldscibooks.com/compsci/6277.html It's still maintained on-line at the usual location: http://crca.ucsd.edu/~msp/techniques.htm cheers Miller

5 6

Re: [PD] Opencv & pd
by nosehair911＠bellsouth.net 30 May '07

30 May '07

IO, I understand what you where saying. I just figured it would be easier to make a self contained external than to try to figure out how to convert things so that Gems GL stuff could use it. From what you are saying I was probably wrong. I just could not figure it out really and there was no how to for Gem like the how to you wrote for Pd (althogh the Gem sorce is documented well). Nanodust, When I said "have you used pix_multiblob before" I was not trying to be inflamatory I was just asking. >From your reply I think it might have come out that way but it was not ment that way. I appreciate all input. Thanks to all, Alain > > From: IOhannes m zmoelnig <zmoelnig(a)iem.at> > Date: 2007/05/30 Wed AM 09:57:55 EDT > To: nosehair911(a)bellsouth.net > CC: pd-list(a)iem.at > Subject: Re: [PD] Opencv & pd > > nosehair911(a)bellsouth.net wrote: > > I dont know if you have ever used pix_multiblob before. This would be my first option and I already > > just to make sure that we do not misunderstand each other: > i had no intention in saying that you should stick to the existing objects. > i thought that you should integrate your openCV objects into Gem and not > brew your own objects. > > the problems you described (sending pointers to and fro), show that you > do not create Gem objects (which would handle this stuff for you). > > > mfg.asdr > IOhannes >

1 0

Re: [PD] Opencv & pd
by nosehair911＠bellsouth.net 30 May '07

30 May '07

I dont know if you have ever used pix_multiblob before. This would be my first option and I already had built a huge project using pix_multiblob before I realized that just tracking 5 blobs with pix_multiblob on a G5 dual 2Ghz with a Radeon 9800 XT and 3 gig of ram it was using up 98-104 percent of my cpu on just tracking lone. Try the pix_multiblob example. The opencv app I built running on a powerbook g4 1.5Ghz with 512mb of ram only uses 38-45 of my cpu with the same movie. In my project I am going to need to track at least 15 to 20 blobs if not more. You do the math. The reason I want to build it into an external is for convenience and for the learning process. If you have any help to give I will be happy to learn from you. Alain > > From: "nanodust" <nanodust(a)gmail.com> > Date: 2007/05/30 Wed AM 08:07:45 EDT > To: <pd-list(a)iem.at> > Subject: Re: [PD] Opencv & pd > > > > For the last 2 weeks I have been trying to write a motion tracking > > > external using the blob motion tracker in opencv. I had success > > > with writing a program that recieves a path to an avi and motion > > > tracks the blobs and prints their position. Now I am writing the > > IOhannes m zmoelnig wrote: > > > otoh, why don't you just use the Gem framework? > > My thoughts *EXACTLY* > > Why spend time re-doing what exists? (for fun, perhaps ;) > > As it is, pix_blob works quite well - and if you need multiblob, update > pd/gem from CVS - pix_multiblob works very well also, and is quite fast. > > *instancing* / id tracking is rare (not inherent to openCV either), but I > was able to hack it well enough for my purposes. > > > if nothing else works, it might be simplest to just write your own > > application (without pd) and send the data to pd via your favourite > > protocol (FUDI, OSC, SMTP...) > > Indeed - for more complicated operations (face & body recognition) I used > opencv's haars, then sent the coordinates to GEM via OSC for various visual > effects. > > From pd context, I don't see what benefit opencv blobs have over > pix_multi/blob; but perhaps I am missing something! > > > _______________________________________________ > PD-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >

2 1

← Newer
1
2
3
4
5
6
7
8
...
32
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 May 2007