Pd-dev January 2003

pd-dev@lists.iem.at

33 participants
41 discussions

Re: [PD-dev] [GEM] more on YUV (was: postrendering crashes)
by chris clepper 11 Jan '03

11 Jan '03

>I do not see why there should be things that can be done on one >platform and on the other not. Actually I think that platform independency >is very important for GEM. > >I am not a specialist in graphics, but for me, YUV,RGB etc is just a >different way of handling images, which boils down to additions, >multiplications, etc... > >Can you explain how the Operating System comes into play here ? >Or is it the processor rater ? There are lots of differences between the GEM versions already, a large one being the way video files are handled. The QuickTime API on Mac and Windows* extends far beyond the simple handling of video files, and includes support for things like VR and streaming. Also, the OpenGL implementations are different for every platform, the OSX version is using features specific to it like Rectangular Textures and YUV Texturing. My argument here is to not hold back development on one platform based on lack of features on the others. The core features of GEM would be the same, but the 'extras' would capitalize on strengths of each platform. Right now GEM doesn't even play the same video files on every platform. There are platform/device specific objects like pix_DV and tablet etc. so these differences already exist. Maybe the structure of the CVS needs to be changed to accommodate these differences. BTW, what's gemee? I've never seen or heard of this before. It's not mentioned in the GEM docs or on any GEM site that I've seen. cgc *the Windows version of GEM doesn't use QuickTime right now, but it could be added fairly easily. Does this interest anyone? >Greetings, > Guenter --

4 3

pd and jackd
by Ryan Gallagher 11 Jan '03

11 Jan '03

Howdy all, Using planet ccrma pd 35 patched for jackd and envoking jackd thusly - jackd -R -d alsa -d hw -p 480 -n 4 pd -jack gives me solid red dio errors and a screen full of "Partial readPartial readPartial readPartial" and jack says "subgraph starting at PureData1234 timed out (subgraph_wait_fd=13, status = 480, state = Triggered)" jackd -R -d alsa -d hw and pd -jack work fine but I'm using ardour which requires the unusual buffer settings. Any ideas? thanks, ryan ===== --r-- __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

3 2

Re: [PD] problems installing GEM 0.88-1 on linux...
by tigital 10 Jan '03

10 Jan '03

> >make[1]: Entering directory `/home/marcell/download/Gem/src/yuv' >make[1]: *** No targets specified and no makefile found. Stop. > >it has Makefile.in and Make.source in yuv dir... i tried with all:: >making new Makefile file but still didn't work.... > hi marcell, ...yuv_* isn't really supported on any platforms other than OS X, Yet...but we're working on it! You may wish to remove that directory, or change the make file so that it doesn't try to compile that stuff... l8r, jamie

3 4

Re: [PD] Re: [PD-announce] PiDiP version 0.6.1 [ motion detection ]
by bbogart＠ryerson.ca 10 Jan '03

10 Jan '03

Hmmm how about a PDP version using altivec. :) A great framework for a number of things (like pix_trees?) :) Ben ----- Original Message ----- From: /voldemars / d9 <voldemars(a)parks.lv> Date: Wednesday, January 8, 2003 9:20 pm Subject: [PD] Re: [PD-announce] PiDiP version 0.6.1 [ motion detection ] > on 09.01.03 03:52, Yves Degoyon at ydegoyon(a)free.fr wrote: > > anyone's planning to port PiDiP for OSX use? > point-to-point video communication sounds soo good. > > /v > > > hi, > > > > that's now PiDiP v0.6.1, i added the following objects : > > > > pdp_mgrid : grid-based motion detection > > > > it allows you to trigger some funny things > > whenever something moves in a region > > of the captured image )) > > > > pdp_o/pdp_i : PD to PD streaming > > > > it allows you to send your video processed data > > to a peer running PD ( linux ), so it's not really > > streaming, just point-to-point communication. > > it also requires a huge bandwidth, > > i'll optimize it soon. > > > > + doing an object for MPG4 streaming is not that easy ... > > > > enjoy !! > > > > sevy/yves > > > > > > _______________________________________________ > > PD-announce mailing list > > PD-announce(a)iem.kug.ac.at > > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-announce > > > _______________________________________________ > PD-list mailing list > PD-list(a)iem.kug.ac.at > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list >

5 6

[PD-dev Announce] New syncgrain~ in CVS
by Frank Barknecht 09 Jan '03

09 Jan '03

Hi, I did some work on my syncgrain~ external in SF-CVS. The big change is, that sgrain~ doesn't load wav/riff files as grain sources anymore, but instead depends on standard Pd table/array objects. This was implemented by using flext's buffer class, which I used for the first time, so there probably are major bugs in syncgrain~. One known bug is, that Pd crashes if you delete the array, that was set to be the grain source for syncgrain~. So don't do that. If anyone has a fix, I'd be glad to incorporate it. Also I kind of hacked together the (linux only) makefile, that now is a bit, well, personal, but it works. (I didn't arrive at the Make-chapter of Eric de Castro Lopo's "Teach Yourself C for Linux Programming in 21 Days" yet ;) So please, try syncgrain, but be careful (for example: don't do "pd -realtime") ciao -- Frank Barknecht _ ______footils.org__

1 0

Re: [PD-dev] [GEM] new postrender crashes OS X
by bbogart＠ryerson.ca 08 Jan '03

08 Jan '03

Hey guys, As for naming, how about pix_foo_yuv for the yuv versions of the objects.. As for YUV in general I think it would only be used by more advanced users, mostely because the colorspace is imply that much more difficult to get your head around. As such I would say objects should be rgb by default and the yuv choice only comes in when you know you want it. I think the waysoftVNS deals with colorspace is more as Johannes describes, with very fast conversion between colorspaces (altivec) I think you can specify the color space of a video source by send the source object a message. Perhaps something similar in Gem where the pix_ objects check what kinda of data they are getting and act accordingly, ie printing a message saying that pix_blah only supports YUV, and you must use pix_yuv to convert the rgba stream in order to use this object. with all the efforts with coloured patchcords, how about changing the color of an object when it gets a datastream it does not support. Some of the other packages (eyesweb) only lets you connect compatible data types, otherwise it simply refuses to connect the objects. Some ideas from my perspective anyhow. Ben ----- Original Message ----- From: chris clepper <cclepper(a)artic.edu> Date: Friday, December 20, 2002 7:39 pm Subject: Re: [PD-dev] [GEM] new postrender crashes OS X > >what i want to have: > >one "class" of objects, that do image-processing (ok, we have > said > >this several > >times by now...) > >All objects should be derived from "one" real class (in C++), the > >GemPixObj (or > >GemPixDualObj) > >as with naming: if you really think, you won't get what you want > if > >objects are > >called "pix_*" instead of "yuv_*", go on, and make "pix_*" > objects and !alias! > >them to "yuv_*" (with class_addcreator()). > >this should be easy, and everybody would be happy. > > the only thing i can't figure out is how to make it clear which > objects work with which color space. the current method of > dumping > endless error messages to the console is simply awful. > > i can easily see building processing chains that don't work at > all. > without some sort of feedback from GEM it will not be apparent why > these chains do nothing or don't work as expected. maybe someone > can > come up with an elegant solution for this... > > >now, why do i want this ? of course there are differences between > >operations in > >color-space, but maybe, somebody wants this ? > >multiplying channels with scalars might have completely different > results in > >YUV-space and in RGBA-space. > >But that's OK! I'd like it this way (it extends the possibilities > of image- > >processing) > >sometimes we might not be able to do things in a specific color- > space.>Gosh, that's ok! i do think, plenty of operations (pE. > alpha-keying) > >don't work > >in Grey-space. > > there's no alpha in yuv either, but also no luma in rgba. those > are > pretty big differences to me, which require not only different > coding > but also differentiation in the user interface (messaging and > arguments,etc). one of the ideas about adding yuv was to not have > to > use rgb anymore > > >If i have a fast processor (and in near future we all will have), > conversion>between yuv and rgba (as far as it is possible) might > not be the problem any > >longer. > > i never assume that fast processors and high end graphics cards > are > being used with GEM. the whole point of writing the yuv_* in the > first place is to have fast video on slower hardware!! > > live, i use a lowly g3/400 laptop with a pathetic 8MB Rage128 > chip, > and the stuff i write in GEM runs fine. in fact if it doesn't run > ok > i rewrite it until it does. of course my faster boxes are nicer > to > use GEM on ;) > > >i don't think, that YUV is something "OS-specific". > >just some OS's support it better than others. maybe this will change. > >i'd rather prefer it like it is and introduce a "conversion on > demand" object > >before the actual texturing (that will convert YUV to RGB on PC- > platforms but > >not on Mac's) > > conversion is fine as long as it's not relied upon heavily. the > one > pix_ does all will require a bit of knowledge about yuv and rgba > from > end users to get the hang of it, and the clearer these differences > are set down the shallower the learning curve. GEM needs more and > better docs anyway, so some color-space info could be rolled in to > that. > > i'm also in favor of creating a stable and experimental version of > GEM in the CVS. that way the stable version will at least be > functional, but without yuv, while we sort out everything. > > cgc > > > > > -- > > _______________________________________________ > PD-dev mailing list > PD-dev(a)iem.kug.ac.at > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev >

7 15

PD clustering, multicast netsend/netreceive
by bbogart 08 Jan '03

08 Jan '03

Hello all, Is anyone working on a way of using PD in a clustered environment? High-load objects could operate over a cluster. Ideally it would be nice if one could tell any object to run on the cluster, to speed up pix_processing or render more complex gem scenes. I'm really thinking here of PD as a possible graphical interface to show the datapaths in a certain work process which may run on multiple machines and pass data back and forth. Rather than each object representing a machine, each object could represent a job on a machine. Well its an idea anyhow. (I'm thinking of prototyping something using SPREAD) Anyone written, or interested in, a multicast netsend/netreceive for pd? For those not familiar with multicast this would allow the same data to be sent to almost any number of machines simultaneously. using only one multicast IP. (If they have a multicast enabled network) Anyhow I think thats enough ranting for today. Thanks Ben

2 1

pd installer 4 windows
by André Schmidt 08 Jan '03

08 Jan '03

hi miller, all, i'm doing an "easy" (+un)installer of PD 4 windows with http://www.jrsoftware.org/isinfo.php (got inspired by the osX installer:) (and i'm also thinking on doing installer(s) for externs) yes, i know. but even for experienced user a "few clicks" installer is much convenient than unpacking & moving (especially 4 externs!!!) comments ?! oh, allmost forgot i'm giving the installer options for main, help, sources. so would be nice if some1 could say what are - main ; the minimum files that are needed to run PD - help ; i assume all in "pd/doc" - sources ; i assume all in "pd/src" + respective folders in extra (what about the folders-> portaudio & tcl and *.h files in "lib/asio") cheers -andre ps is some1 planning on doing a GUI for the commandline options of PD (or maybe a somekindof "autodetect") ?

3 4

PD-Sourceforge project descriptions
by Frank Barknecht 07 Jan '03

07 Jan '03

Hi, I think it would be good a good new year's start to have a section describing the projects hosted on pure-data.sf.net's CVS-repository. It would be great, if those who have stuff inside the repository could mail me a (short) description of what's inside their directories, who wrote it and so on. I could write it myself (and I warn you, I would do it!), but it's less work for me, if you write it. ^_^ So please mail me your descriptions, I'll add them when they come in AsSoonAsPossible(tm). Thank you and ciao -- Frank Barknecht _ ______footils.org__

3 4

CVS GUI changes
by Adam Lindsay 07 Jan '03

07 Jan '03

Hi all, I just committed a bag of experimental graphical interface changes to CVS. The main change is in the structure of the menus, which are now invoked in a more "native" way, using modern Tk guidelines (near as I can make out). People who like their Linux applications to look/act the same way on every other platform will probably not like this. I have tested on MacOSX. I tried the modified pd.tk file on Windows with success, but haven't had the resources to compile in the other changes. I would *really* appreciate it if other people tested this. thanks, adam More details, if you're curious... You can see the pd.tk changes involved here: <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pure-data/pd/src/ u_main.tk.diff?r1=1.1.1.2.2.1&r2=1.1. 1.2.2.2&only_with_tag=devel_0_36&sortby=date> Changing the windows also had some side-effects: o The tearoff menus are now in the code as an adjustable global parameter. Macs don't use it, PC and Linux do. o Tk reports a mis-feature with -postcommand on both Mac and Win (see <http://www.tcl.tk/man/tcl8.4/TkCmd/menu.htm#M8>). As a result, I change the way the Edit (undo/redo) and Windows menu refresh. Basically, rather than updating when polled, I update the windows when the underlying state changes. There's an unsatisfying hack in g_canvas.c::pdtk_undomenu to catch a potential bug when a window is destroyed. While I was in there mucking about, I modified a few other things, following some of Apple's basic human interface guidelines: o On the Mac, the last three menus are "Audio Window Help" instead of "Windows Audio Help". o The "right-click" is now truly a right click on a 3-button mouse, and control-click is also usable for contextual menus. o You can open html documentation files on the Mac. I also revisited JSarlo's gui patches, restoring the useful dark-yellow color on signal connections (but overlaying that on top of Miller's method for distinguishing them). I tweaked jsarlo's shadows on the Mac to make them look more like: <http://mambo.peabody.jhu.edu/~jsarlo/gripd/linux1.jpg> (The shadows on the Mac were separated from the box by one pixel, which is kind of odd. Movement still will cause the box and shadow to be separated, for some reason.) I tried to set these changes off with tags, but it looks like it didn't work (still have a lot to learn with CVS). All of these are in the devel_0_36 branch that Guenter described yesterday. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay atl(a)comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

5 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev January 2003