Pd-dev February 2003

pd-dev@lists.iem.at

29 participants
51 discussions

Re: [PD-dev] [GEM] CVS-changes
by chris clepper 24 Feb '03

24 Feb '03

>and another two changes: > >1. [alpha] >now you can set the blending-function >0..GL_ONE_MINUS_SRC_ALPHA that's the (old) default >1..GL_ONE (as would be enabled by the "blend" message to various objects. > >2. [polygon_smooth] >enables polygon smoothing > >i think this is better than having to add the "blend" method to all Geos. >So users can decide what they need. (and they need to know about it anyhow) > >i think [polygon_smooth] is a bad name. but which one would be better ? i'll try this out later today. the main reason i added the blending stuff to the geos was to get anti-aliasing. those jagged objects were pretty ugly to look at!! the side benefit is of course having alpha blending 'for free' on the gpu. i have no suggestions for [polygon-smooth] right now, but then again i'm always having trouble naming these objects. at least it describes what the object does. cgc

1 0

[GEM] CVS-changes
by IOhannes zmoelnig 24 Feb '03

24 Feb '03

hi. jsut some comments (although i have commented it in the cvs-logs)... 1. TV is gone (now in pix) 2. a wee change in the imageStruct-class: reallocate() only allocates memory if the old buffer is too small. 3. [pix_tIIR]: another time-domain filter for images. is alike [pix_biquad] (but faster) and [pix_blur] (but more flexible). You can give 2 arguments: the number of feedback-taps and the number of feedforward-taps (in this order). No yuv-optimization is made (because of genericity). A test: [pix_blur] takes (on my machine) between 16% and 26% (mean: ~20%) [pix_tIIR 1 0] takes approx. 24% to 28%. an ignorant question: how can i make use of loop-unrolling of the compiler ? (how do i have to built the loops? my experiments showed rather worse results when i did large loops (which could have been unrolled by the compiler)) 4. what else ? cannot remember. mfg.asd.r IOhannes

3 3

[GEM] pix_blur ???? which Gem-objects do we need (have) ?
by IOhannes zmoelnig 24 Feb '03

24 Feb '03

Hi list, hi chris. Maybe a stupid question: What is this [pix_blur] for ? Hey, i don't want to be rude (mr. bad guy again....), but there already is a thing like [tv_biquad] that does very similar things (and more) I think, Gem should follow pd's (vs. other libraries) object-policy: make a minimum orthogonal object-set, that let's you do "everything" you want. This implies, that there shouldn't be 2 objects, that do basically the same thing. basically [pix_blur] is a one-stage feedback-filter. [tv_biquad] is a two-stage feedback-filter. btw. [tv_*] was meant to "work (only) on series of images", while [pix_*] should work on single images as well. thus [pix_blur] should rather be [tv_blur] (but never mind) I do see the point, that a 1-stage filter needs less CPU-power than a 2-stage filter. But imo, this should rather lead to a general object (like [tv_filter]; i can't think clearly right now, but [tv] indicating that it works in time-domain and "filter", should make clear what is meant; maybe [tv_iir] would be better), that can do all lengths of recursive filterings (and is loop-unrolled for low orders) and can have clipping turned on/off (or not) And I would like to have more control over the filter-paramters: i prefer "y(t)=a*x(t)+b*y(t-1)" to "y(t)=a*x(t)+(1-a)*y(t-1)", especially, when clipping is involved. Ah, that leads to what i wanted to ask/state anyhow: Is it possible to make objects that perform "scientific tasks" (like convolution) rather than "folkloristic FX" (like smoothing) [pix_convolution] is far more powerful than [pix_smooth] could be. And of course, you can build a [pix_smooth]-abstraction with [pix_convolution] Maybe a bit of a thought before doing a "quick hack" could save programming-time in the long term. (ooh, this sounds really like mr. bad-guy. i don't want to insult anybody) i do think, that pd is a programming language (with a lot of flaws (in terms of a prog-lang), sure) i do think, that Gem should be a language-extension, rather than a set of cool effects. That's why i thought it a good idea, to make this openGL-wrapping stuff (which is surely harder to use than all those ready-made Geos) any comments ? mfg.as.dr IOhannes

6 10

[wavinfo] on Darwin broken?
by Hans-Christoph Steiner 24 Feb '03

24 Feb '03

So it seems that [wavinfo] from ext13 is broken on Darwin/MacOS X, which sucks for me since its a key part of a project I am working on and I just bought a new PowerBook. When I run the help patch, and open a file with 116736 samples 1 channel 16-bit 44100 rate [wavinfo] says: 72.0059 samples 256 channels 4096-bit 1.15212e+09 rate Does it work for anyone else? I am going to take a look at it when I get a chance, but I just thought I'd run it by the list to see if anyone has any ideas. .hc

2 1

pidip/live~
by martin pi 24 Feb '03

24 Feb '03

hi, just realized that pidip-0.8.5's pdp_live~ is also a very capable file player (even for my beloved mpeg4 files) - just want this great feature to be known by everyone, since i did not read it out of yves mails. if the image seems to be _very_ distorted try to give pdp_xv the correct |size <w> <h>( martin martin pi http://attacksyour.net/pi www.machfeld.net

2 4

[Fwd: Re: [PD-dev] pidip/live~]
by Yves Degoyon 23 Feb '03

23 Feb '03

Christian Klippel wrote: >hi, > >Am Sonntag, 23. Februar 2003 19:36 schrieb Yves Degoyon: > >>btw, haven't you noticed that the sound >>is played at a weird speed ( faster that regular >>but not resampled ?? ), i still wonder where >>this might come from.... mm .... work ahead. >> > >mostly this is because the soundcard has _not_ exactly the samplerate you >request it to have. for example, if you want 44.100 hz, you can get 44.116 hz >instead. this is because most soundcards have an independant oscillator. >it is even possible for two soundcards of the same brand & type to have >different samplerates. > >that is, btw, the reason why you cant simply get multichannel sound by using >multiple soundcards ..... > mm, i was not thinking of a soundcard problem, since other way of playing sound files are ok, palying at the right speed. it's only the pdp_live~ object which produces this effect. > > >another reason might be due to the framerate of the video. samples per second >divided by frames per second must give a non-fractional result. otherwise you >would have a different number of samples each frame. most of the time this >doesnt bother, but some weird ntsc timing (with that 29.xxx fps) can cause >that too. > > > >best (and most used) solution is to split one _video_frame_ of audio into >several chunks (for example. pd's dsp size) and play them either seamlessy, >overlapping or by repeating the last & first sample to fit the needed time >(some kind of very cheap granular synthesis) for one frame in corrospondance >with the soundcards samplerate. > >with no corrections to audio playback you will _always_ get out of sync to the >picture soon. > yes, i do agree on these remarks, but as the decoded audio frames are decoded into a buffer before being played, and not played at once, this means the audio data __within__ the buffer is already at the wong speed ?? how could i debug that is the real question right now.... thanks for your hints anyway, cheers, sevy/yves

1 0

RE: [PD-dev] Re: [GEM] pix_blur ???? which Gem-objects do we need (have) ?
by Matthew Allen 21 Feb '03

21 Feb '03

Actually I don't find it arrogant at all. I currently just use PD from the audio side of things, but at my day job I'm a lead artist at a video game company, and you have actually hit on one of my biggest gripes about Photoshop, and the whole dumbing down of a product for the sake of readability/usability. Photoshop (since version 3) introduced the idea of blend modes for its layers. Yet for some insane reason they decided to go against the most common naming schemes for these modes. So instead of 'Adding' one layer (CS + CD) I need to figure out if I should use 'screen' or 'overlay' or some other oddly named thing from their list (its screen by the way :). This has led to all types of confusion for artists, who started out as your 'dumb user' but over the years have moved into the power user category. So now They look at the various blend operations available to them on modern cards and have to run through them all testing each to see what its 'Photoshop' equivalent is. In many cases Photoshop's approach is easier (multiply is easier, I guess, to understand than CS*CD) in the short term, aimed at people who are just looking to add text to their digital images. But in the long term 'dumbing' things down can hurt the long term user who wishes to expand their knowledge. m. > maybe some users have earned a deeper (or a first) understanding of > signal- > processing because of the way pd works. They learned how effects are made > (vs. > applied). I want the same for Gem-users. > I fear users asking for features like "sharpening" when it is already > there. > And they will go and ask for "sharpening more" (is called like this in > photoshop ?). And i am not willing to spend my time for these. (but of > course, > that is quite arrogant)

2 1

Proposed CVS addition: -helppath
by Adam Lindsay 21 Feb '03

21 Feb '03

Hello folks, I have a proposed addition to CVS that I'm a little nervous about adding without consulting others first. I did a little cut-modify-and-paste of some existing functions, and I have a first pass on code that allows one to modify the help search path. It's not pretty or well-tested, but I hope some will agree that's what CVS is for... The usage is pretty straightforward: -helppath <path> -- add to help file search path It works in the same order that you might expect from the -path command- line option (since it is basically a simplified version of the same search function). Some thoughts: 1) It's on Miller's to-do list in notes.txt. Might be a good thing to get to it now; might be a bad thing to do it the "wrong" way. 2) The code is definitely a hack. It's not even a good one. 3) I would *really* like this functionality to be in at least one version of Pd... IMHO, it would *really* help the usability, especially on MacOSX, so that there's a unified place for newbies to install externals from the Finder. (e.g., /Library/Pd/externals and /Library/Pd/help, which could be over-ridden by stuff in ~/Library/Pd ) I haven't checked anything in, yet, but the code is ready to go. Cheers, adam -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Adam Lindsay +44(0)1524 594 537 atl(a)comp.lancs.ac.uk http://www.comp.lancs.ac.uk/computing/users/atl/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

3 7

standard file locations
by Tom Schouten 20 Feb '03

20 Feb '03

hi all, i've probably missed some discussions on this topic but i am wondering if there has been any efford to standardize the location of pd and other externals/abstractions, in the light of the sf extern collection. i've got the impression that everybody likes his pd stuff in a different place (including me) but having some kind of standard would make things a lot easier to organize. last night i finally got autoconf working for pdp with an eye on making the osx port a little easier to do. but there are basicly two things i want to see solved: finding the pd location and putting the pdp headers in a standard place for libs that depend on pdp. any thoughts on this? tom

3 3

resizing
by Krzysztof Czaja 19 Feb '03

19 Feb '03

hi all, as I am going to enable resizing-by-dragging of cyclone's ui objects, I wonder if there are any examples of how it could be done, or if anybody has any suggestions. It seems like there is no way, by means of the current Pd API alone, for an external to be notified about its part, a resize-handle. being clicked at in edit mode. Miller, perhaps you have plans to include this feature in a future version? If not, I would try directly binding this info out from the tk layer (it is going to be nasty). I would rather not create a proxy 'handle' object (a separate gobj inserted into a glist), in the fear of corrupting the ordering of objects during save/load and copy/paste. Currently the only two ui classes are Scope~ and comment. I fancy having them as complete as possible in the early stage, though. Krzysztof btw, being notified about the mouse-up would be handy too...

4 6

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