Pd-dev April 2003

pd-dev@lists.iem.at

29 participants
39 discussions

Pdplay?
by Nicola Bernardini 21 Oct '04

21 Oct '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, at the SOb project (http://www.soundobject.org) we're writing some really cool physical model objects which we are soon going to package and propose to the pure-data externals repository (they are GNU/GPL). However, we now have a problem that we want to solve soon: we need standalone versions of some demo applications (possibly running griPD etc.) we did. It would be nice to have a sort of MaxPlay type of thing (how about PdPlay?). I have some ideas on how to do it and it could be trivial, and therefore it is very probable that someone has already done it somewhere. If no one has done it, I'll hack up one solution and report back to the list as soon as it is done (it is going to be GNU/GPL anyway :). Thank you in advance for all the help you will want to give. nicb +--------------------------------------------------------------------+ |Nicola Bernardini | |E-mail: nicb(a)centrotemporeale.it | |GPG Fingerprint = 6AE6 AF21 E160 D9B3 396E EBAC 906C CFAE 4D65 D910| |Neither MS-Word nor MS-PowerPoint attachments please: | |http://www.fsf.org/philosophy/no-word-attachments.html | +--------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE9mf2qkGzPrk1l2RARAqi/AJ92NXY9HoDWlMbRcu59RkUQNH8E7gCeLU07 +ocbGJWYRzzrrdQO/cG0BcM= =TT6i -----END PGP SIGNATURE-----

5 7

[GEM] names
by chris clepper 07 May '03

07 May '03

Hi I mentioned in the last post about a new GEM release that some of the names of various objects don't really match what they do very well. i think i've said on a few occasions that the name of the object needs to tell the user what they do rather than be some excessively cute, clever name from a book no one has read, Hindu deities or someone's cat (btw, all of these are used as names in other video systems). so here's a list of objects and suggested changes: - pix_blur - this should be renamed pix_motionblur and pix_blur will be an abstraction for a convolution based blur. - pix_buf - would it be better to rename this pix_separator to mirror the separator object? pix_buf can remain for compatibility. - pix_depot - why not call it pix_buffer? or pix_table or pix_array? something that is a common term for a chunk of memory filled with data (frames of video in this case). yes, a depot is a place to store things but it's mainly used as a military term or in the name of a large chain of hardware and office supply stores in the US (Home Depot and Office Depot respectively). - pix_put/get - could be pix_buffer_write and pix_buffer_read. these seem a little more specific to me and the name-space extension allows for direct association of functions with the pix_buffer object. also i was thinking of making objects that performed various actions on the buffer or used it in some way for processing. also, this could facilitate non-realtime renders. examples: pix_buffer_average - averages the frames in the buffer and stores the result as a single frame. useful for motion detection and compositing and pix_background type effects pix_buffer_record - dumps the contents of the buffer into a Quicktime .mov and compresses them. could be useful in situations where the frames can be stored in the buffer but compression takes too much time to be done in real-time (like MPEG-2 or 4). pix_buffer_motionblur - really high quality motion blurring requires lots of frames to be used and is generally not a real-time operation. if you've ever seen the shake motion blur you know about this. there are some other ones that are new to CVS that might need better names: - pix_background - this removes the background from based on a static image snapshot. is there a more meaningful name that better describes this? pix_background_remove is a bit excessive i think. - pix_scanline - this does image decimation based on either repeating or removing rows of pixels, so it does do scanline processing but is that really clear? i don't think any of the objects are really in wide-spread use except for pix_buf which can remain for compatibility purposes. maybe this is just a personal pet-peeve, and no one really cares what the objects are called as long as they work, but i thought i would make some suggestions and see what people think. cgc

5 4

[GEM] cvs checkins
by IOhannes m zmoelnig 01 May '03

01 May '03

hi gemers! i just checked 3 new objects into the CVS [pix_depot], [pix_put], [pix_get] [pix_depot] is much like [table] but for image-data. it need sa symbolic name and a number of images that can be stored. (like [pix_depot storageroom 100]) it is *not* used in the gemlist (like [table]) [pix_put] will put an image to the specified position in the [pix_depot] [pix_get] will get an image from the specified position of the [pix_depot] hope it works (the other changes are very minor - mostly to get rid of warnings when compiling under windos) mfg.a.srd IOhannes

4 4

[arraysize] in PD
by David Sabine 30 Apr '03

30 Apr '03

Hello all, I'd like to make a motion that [arraysize] (by Pix) be included in the main PD distribution and be considered for inclusion as a "native PD object". My reasons: 1. PD lacks this tool and although it is available as an external, I feel that this functionality is essential and should be "internal". 2. PD object names like [getsize] and [setsize] are misleading...particularly when those reference files refer to "the size of an array". Obviously this matter would be clarified if users were presented with [arraysize] also - I'm guessing that PD users would clearly understand the different applications for these 'related' objects. 2. I have just finished writing an abstraction entitled "all_about_arrays" for PDDP which will be included as a supplement to the PDDP reference files regarding [tabread], [tabwrite], [tabsend~], [tabwhatever] etc. To demonstrate some of the "usefulness" of arrays (i.e. wave editing, concatenating two arrays, slicing and splicing arrays, joining arrays, reversing an array, etc.) I have found it necessary to use [arraysize] and I would prefer that users not have to download and install an external object just to understand these tutorials. Particularly when determining the length of an array is such a standard procedure in high level programming environments. If anybody has any objections, I'd like to discuss this matter. Otherwise, should Miller make a decision on this? I don't know how Pix feels about this, as I have never discussed it with him. If all developers vote "no", then what is the best method for PDDP to include [arraysize] in the reference files? Should I link to the CVS? Should I keep an updated arraysize.dll in the downloadable zip? Should I assume that most users would have the foresight to have already downloaded arraysize.dll? Regards, Dave Sabine

5 9

regression tests
by Hans-Christoph Steiner 30 Apr '03

30 Apr '03

So one of the things that Miller said that is necessary before putting the pd sources into CVS is a suite of regression test. Since there is already development going on, I think that we should start developing regression tests. I think this could be done by creating patches that do a lot of things, then output a text result. Then a Makefile could run them using pd -nogui to test them. I am motivated by the fact that pd devel_0_36 from CVS has some key bugs in it on my Linux box. There are two clear demonstrations of the problems: the first is that the bold border around a message doesn't go away after I click on the message. All of the message I click get stuck with this bold border around them. Also bangs stop displaying after displaying once. And the second problem is demonstrated by maxlib's [velocity]. When I use it with the CVS pd, the only thing it outputs is "nan". When I reverted to the "pd" package using apt-get, all of the above problems disappeared. When I get more time, I can do a thorough bug report if anyone is interested. .hc zen \ \ \[D[D[D[D

3 6

compiling individual debs
by Hans-Christoph Steiner 30 Apr '03

30 Apr '03

Can anyone tell me how to compile the debs from CVS individually? I am using dpkg-buildpackage and it dies on the footils package, leaving me with no .debs for the rest. .hc zen \ \ \[D[D[D[D

3 8

PD 0.37 - first error report
by David Sabine 30 Apr '03

30 Apr '03

Hi all, I've just downloaded the 0.37 TEST 4 for Win32 and cannot open PD using asio. This .BAT file has worked reliably for a few months: @ECHO OFF color F0 cd C:\pd\bin C:\pd\bin\pd.exe -asio -verbose -listdev -inchannels 8 -outchannels 8 -noresync -nomidi However, any command line WITHOUT -asio seems to work alright. I can load Gem and Zexy...but not asio. ? Is this a bug? Or my error? Regards, Dave S

1 0

[GEM] cvs ci *.cpp *.h
by IOhannes m zmoelnig 30 Apr '03

30 Apr '03

hi. a few commits i made to the gem-cvs (and probably a lot i have commited but haven't kept in mind) i tried to comment all of them (and it was very tiresome...) Pixes: 1. merged [pix_texture] and [pix_texture2] again. still the old pix_texture2.cpp is not deleted (but [pix_texture] already adds an alias to [pix_texture2]) i have added the rectangle-texturing for nvidia-cards. however, it might work or not on other machines than mine. please ! do test it. also i think i have fixed a bug, that crashed [pix_texture] when no image was present. 2. pix_video (under linux): now has a message for setting the colour-space (like [color grey( or [color RGBA() apropos: chris said something about openGL not liking to swap colour-spaces on the fly. i think this was a bug in [pix_texture] (i think). the base-texture has to be the same colour-space as the sub-texture. after i had changed this, i could switch between colour-spaces. (but unfortunately the yuv422 provided by the video4linux-drivers seem to be something different to what an nvidia-card expects as yuv422-texture) Particles: 1. the long awaited [part_render] (couldn't think of a better name) ! everything that is below the [part_render] will be used as a basic particle (like textured models (ok, this might be a little bit exhaustive)) 2. [part_info] is similar to [part_render] but doesn't actually transform a render-list but rather provides all particle-properties as lists. 1+2. there are 2 demo-patches in particle i hope, this will make the particle-system finally "useful" (personally i didn't like the dot/line particles) the rest i cannot remember... mfg.as.d IOhannes

4 5

Re: [PD-dev] [GEM] names
by bbogart＠ryerson.ca 30 Apr '03

30 Apr '03

All the new names sound good to me, but I wanted to clarify pix_background a bit: Does it just subtract a reference frame (background) from the current frame and then apply that as an alpha channel to the outgoing frame? (or does it fill the background with a color?) perhaps something like pix_key makes the most sense, may be used for a background, but maybe not, but as some other keying type. pix_key could do the above mentioned operation on a the current frame coming into the left inlet using the "key" (background etc.) coming into the right inlet? Some ideas anyhow, Will get cracking on some tutorials once my move is over! Oh and one other suggestion, on my last project it was quite anoying to have the video render stop when a new set of still jpegs were loaded into pix_images. Would it be possible to thread the image-loader so that it does not interupt video rendering? (same goes for video files, but I think those loaders are already threaded?) Ben ----- Original Message ----- From: chris clepper <cclepper(a)artic.edu> Date: Monday, April 28, 2003 7:00 pm Subject: [PD-dev] [GEM] names > Hi > > I mentioned in the last post about a new GEM release that some of > the > names of various objects don't really match what they do very > well. > i think i've said on a few occasions that the name of the object > needs to tell the user what they do rather than be some > excessively > cute, clever name from a book no one has read, Hindu deities or > someone's cat (btw, all of these are used as names in other video > systems). so here's a list of objects and suggested changes: > > - pix_blur - this should be renamed pix_motionblur and pix_blur > will > be an abstraction for a convolution based blur. > > - pix_buf - would it be better to rename this pix_separator to > mirror > the separator object? pix_buf can remain for compatibility. > > - pix_depot - why not call it pix_buffer? or pix_table or > pix_array? > something that is a common term for a chunk of memory filled with > data (frames of video in this case). yes, a depot is a place to > store things but it's mainly used as a military term or in the > name > of a large chain of hardware and office supply stores in the US > (Home > Depot and Office Depot respectively). > > - pix_put/get - could be pix_buffer_write and pix_buffer_read. > these > seem a little more specific to me and the name-space extension > allows > for direct association of functions with the pix_buffer object. > > also i was thinking of making objects that performed various > actions > on the buffer or used it in some way for processing. also, this > could facilitate non-realtime renders. examples: > > pix_buffer_average - averages the frames in the buffer and stores > the > result as a single frame. useful for motion detection and > compositing and pix_background type effects > > pix_buffer_record - dumps the contents of the buffer into a > Quicktime > .mov and compresses them. could be useful in situations where the > frames can be stored in the buffer but compression takes too much > time to be done in real-time (like MPEG-2 or 4). > > pix_buffer_motionblur - really high quality motion blurring > requires > lots of frames to be used and is generally not a real-time > operation. > if you've ever seen the shake motion blur you know about this. > > there are some other ones that are new to CVS that might need > better names: > > - pix_background - this removes the background from based on a > static > image snapshot. is there a more meaningful name that better > describes this? pix_background_remove is a bit excessive i think. > > - pix_scanline - this does image decimation based on either > repeating > or removing rows of pixels, so it does do scanline processing but > is > that really clear? > > i don't think any of the objects are really in wide-spread use > except > for pix_buf which can remain for compatibility purposes. maybe > this > is just a personal pet-peeve, and no one really cares what the > objects are called as long as they work, but i thought i would > make > some suggestions and see what people think. > > cgc > > _______________________________________________ > PD-dev mailing list > PD-dev(a)iem.kug.ac.at > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev >

2 1

SourceForge CVS
by Hans-Christoph Steiner 29 Apr '03

29 Apr '03

After hearing complaints about accessing the SourceForge CVS, I thought about it and I can't think of a time when I couldn't access the SourceForge CVS. Even when their site said 'down for maintainance', I have still been able to access the CVS. IIRC, the people having problems with the CVS were both in Europe, so maybe there is a routing issue somewhere in between? (I am in Brooklyn, NY) Just my two bits... .hc zen \ \ \[D[D[D[D

2 2

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 April 2003