Pd-dev May 2003

pd-dev@lists.iem.at

24 participants
34 discussions

[GEM] update
by chris clepper 14 May '03

14 May '03

Hi i thought i would post an update concerning some of the things i have been working on. - new object [pix_motionblur] which is a revised version of pix_blur with a slightly revised algo for improved performance and image quality. this also frees up pix_blur so it can be changed to an abstraction based on pix_convolve. i already committed this object. - i have changed, but not committed, pix_texture so that the user can switch between power of 2 and rectangle textures on the fly via a 'mode' message. one question i have is whether or not rectangle textures actually work on linux or windows at the moment. the tests in pix_texture use GemMan::texture_rectangle_supported which works fine on OSX but i'm not sure how that would affect the other platforms. let me know if this looks ok for linux/windows, i don't want to break a critical object on another platform. - i have pix_filmNEW playing in auto mode right now, but i have to agree with jamie's assessment that the new system really does nothing at all for OSX. it may solve some problems on linux, but it seems to actually have many of the same cross-platform issues; i've had to ifdef some stuff in order to get it to even compile. also, i don't think the structure is very clean or transparent since the various libs and APIs need to be taken care by platform. so doesn't it make more sense to have each platform manage the libs/APIs internally rather than do it in pix_filmNEW?? to maybe open up the communication a little bit, here are a few items i'm working on, or plan to work, on in the near future: - an object for loading pixel shaders from a file. i only have an ati 9000 right now so i can only do support for the ati extensions. - some sort of object that will use glCopyTexImage2D to grab part of the framebuffer and apply it directly to a texture. this would be a faster version of pix_snap and also enable some nifty feedback type effects. - adding some sort of alpha info to the particle system for blending. - figure out a way to easily exchange info between pix, particles and geos. part_info is a good start for applying data generated by the particle system to other elements in GEM, but what about using pix_ data as a basis for the particle system? or having the particle system manipulate vertices and texcoords? or how about rendering each frame of video as an array of triangle or spheres or even texture mapped cubes? i don't think that this means a type of system that requires the user to explicitly manage the data and do all the housekeeping like creating buffers, type and bounds checking, etc (a la jitter). instead a series of bridge objects can be constructed either in code or by abstraction to translate and guide the data around. admittedly i don't have much concrete code to offer at this point, but just wanted to bounce the idea off the others devs to get some input. check out this for an example of particles and pixel interaction: http://www.shiffman.net/portfolio/reactive.html cgc

6 8

Re: #ifdef GL_TEXTURE_RECTANGLE_EXT
by chris clepper 13 May '03

13 May '03

>pix_texture.cpp: > >Mon Apr 28 17:44:55 2003 UTC (13 days, 16 hours ago) by zmoelnig: > >#ifdef GL_TEXTURE_RECTANGLE_EXT > >Mon May 12 08:59:48 2003 UTC (94 minutes, 15 seconds ago) by cclepper: > >//#ifdef GL_TEXTURE_RECTANGLE_EXT > >Mon May 12 10:27:45 2003 UTC (6 minutes, 18 seconds ago) by dheck: > >#ifdef GL_TEXTURE_RECTANGLE_EXT > >... > >??? > >I think that before going on like this there should be a real solution to >the problem. >Chris, what is wrong with the #ifdef, and can you think of a better >solution to solve the problem ? >(Like >#if defined(GL_TEXTURE_RECTANGLE_EXT) || defined(DARWIN) .. dunno ... >.... YMMV ... something more sensible than commenting out code >that was put there for some reason, obviously) my mistake, i did that to test the code, and forgot to uncomment it before committing. daniel's other ifdef addition is a little curious though, why add an ifdef for GL_CLAMP_TO_EDGE ? can this be user defined option via the 'repeat' message? cgc >Thanks, > >Guenter

2 2

[GEM] video and audio signals in one object
by Olaf Matthes 13 May '03

13 May '03

Hi GEMers, I was wondering if it is possible to have a GEM object that is a Pd signal (tilde) object at the same time. I had a look at some sources and found that GEM objects are non-signal objects when created the normal way. Is there a way around that? I would like to add GEM support to my realcast~ audio/video streaming external. Or maybe there is another way to get access to the video data that gets displayed by GEM? Olaf

2 1

gem - particle system
by rat＠telecoma.net 10 May '03

10 May '03

hi, one suggestion for the particle system: there is always one "steady" particle in the point of the source of the system. which makes the viewer always focus on the point of source. its even there when part_source = 0 . is it possibile to change this ? lg e ---------------------------------- http://randomseed.org

2 1

Add a gemhead-style render priority to separator?
by bbogart＠ryerson.ca 10 May '03

10 May '03

Hey GEM Devs, I'm working on a little patch here for Matt and My PD workshop coming up. I'm using a group of GEM objects by using a single gemhead sent to multiple (abstraction) subchains via send & separator. In this case there are multiple Geos, but only one gemhead, I had the anoyance to discover that the render order ended up being the reverse of the order the abstractions were loaded. Ie the first abstraction being loaded ends up being the top of the render stack, the last loaded being the bottom. (I really don't now why this is) Anyhow I thought it would be great if separator had a gemhead style numeric render priority argument to give each separator subchain a render order. doable? Thanks! Ben

2 1

MacOSX porting documentation
by Adam Lindsay 10 May '03

10 May '03

Hi folks. Sorry for the Slashdot duplicate, but I thought this technical note was a nice summation of major compiler and build-system issues on Mac OS X, and would be of some interest to those porting externals to the Mac. No real new information, but it's a lot more pithy than Apple's different man pages and html manuals: <http://developer.apple.com/technotes/tn2002/tn2071.html> -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

[GEM] cvs
by IOhannes zmoelnig 10 May '03

10 May '03

hi gem-devs. because chris doesn't like getting no information (and probably others too) i will checkin something into Gem. 1. particles: upgrade to libparticle-120 (was 111). this does not effect most part-objects, but gives some more control (like there is an age-output at [part_info], there is an alpha-channel with [part_color]...) 2. GemBase: the stoprender() and stoprenderCallback() had been commented out by me. when i tried to compile gem2pdp (0.3) they were needed, so they are in again. probably the [gem2pdp] should stem from [gemhead] rather ? 3. GemPixUtils: here we go (i did it again): i have put colour-conversion routines in here. (routines for acquiring data from a specific format like YUV420P) this (the place) might be horrible, and i am very willing to put this into GemPixConvert (but i needed it quickly, and dirty is often faster on the short hand) as always, for now they are only non-optimized. but this will hopefully change. 4. [pix_rgba] on mac this used to produce the wrong colours. i think the rgba-format for mac is GL_ABGR_EXT, so i changed it to this (but i have not tested it) 5. [pix_add], [pix_sub]: Grey2Grey-support 6. [pix_videoNEW]: had forgotten the "device"-Message to switch between various devices (like my Webcam and my capture-card) hope that's it mfg.asd.r IOhannes

4 6

knob and 0.37test4
by Olaf Matthes 08 May '03

08 May '03

Edward George schrieb: > Secondly_ I've recently upgraded pd from 0.36 to 0.37-test4 (on XP) and > I'm getting the following error when trying to use the knob 0.02 dll > from your site: > > 'The procedure entry point iemgui_list could not be located in the > dynamic link library pd.dll' > > Will recompiling solve this or is the code not compatible with > 0.37-test4? Hi Edward, I haven't tried 0.37test4 myselfe yet, but it seems the function iemgui_list has been removed or renamed. knob borrows a lot from Pd's internal functions (which are not intended for public use). I'm posting this to the list, Frank should know that the new Pd version has introduced an incompatibility with knob. I guess the knob code needs to be fixed for all platforms. Olaf

2 1

[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

how about declaring sys_load_lib() in the API?
by Krzysztof Czaja 06 May '03

06 May '03

hi Miller, would you be willing to declare sys_load_lib call as EXTERN in m_pd.h? It is perfectly valid for one external to load another one? At least, I need this for cyclone loading hammer and sickle, also in widget/tow combo, and xeq + friends. Currently, I am using a copy-pasted replacement of this call, but somehow expect, that the original implementation is going to undergo some changes... The call's signature itself is looking stable enough, except one thing, perhaps -- reporting error condition in the return code: 1. no file, 2. bad file (not a dll), 3. no entry (i.e. '..._setup' not defined). Krzysztof btw 1, in s_midi_oss.c line 229 should be deleted (this line is not only redundant -- it stops compilation, because <sys/time.h> is not included) btw 2, in u_main.tk ``global pd_nt'' is needed after line 274.

1 0

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