Pd-list December 2007

pd-list@lists.iem.at

129 participants
239 discussions

Compiling Gridflow on Ubuntu
by Branislav Nakic 22 Dec '07

22 Dec '07

I get these errors when runing *ruby1.9 configure *as recommended on the Gridflow website: *... [gcc64] GNU C++ in 64-bit mode: ----------------------------------------------> missing (runtime error) [libruby] Ruby as a dynamic library: -----------------------------------------> missing (gcc: error: 'rb_rescue' was not declared in this scope) [librubystatic] Ruby as a static library: ------------------------------------> missing (gcc: error: 'rb_rescue' was not declared in this scope) ... [objcpp] GNU/Apple ObjectiveC++ Compiler: ------------------------------------> missing (where is objc/Object.h ?) [quartz] Apple Quartz/Cocoa Display: -----------------------------------------> disabled (would need objcpp) ... [mpeg3] HeroineWarrior LibMPEG3 <libmpeg3/libmpeg3.h>: -----------------------> missing (where is libmpeg3/libmpeg3.h ?) [mpeg3] HeroineWarrior LibMPEG3 <libmpeg3.h>: --------------------------------> found [quicktimeapple] Apple's QuickTime: ------------------------------------------> missing (gcc compilation error) ... [puredata] PureData (or DesireData): -----------------------------------------> disabled (would need libruby or librubystatic) [desiredata] DesireData: -----------------------------------------------------> missing (gcc: error: 'gobj_subscribe' was not declared in this scope) [gem09] PureData GEM (source code) with m_holdname: --------------------------> disabled (would need puredata) [gem08] PureData GEM (source code) without m_holdname: -----------------------> disabled (would need puredata) ...* I have installed both libruby1.8 and libruby1.9 and thieir dev packages. What do I need to do to make it compile? -- _______________________________________ < Ninety percent of everything is crap. > --------------------------------------- \ ^__^ \ (@@)\_______ (____)\ )\/\ ||---------w | || ||

2 1

gridflow for expert people ?
by Jack 22 Dec '07

22 Dec '07

Why gridflow is for expert coder people (< 0,00000000000000005 % of people on the earth ? and maybe < 0,000005 % of the users of PD) is it for fun ? You are in your right to continue thus (for 30 people (good luck for you !) and long life for gridflow !!!!) thx for you answer. Jack

6 14

My project at IEM
by Javier Garcia 21 Dec '07

21 Dec '07

Hi, in order to finish my Telecomunications Engineering, during the summer semester I will go to IEM (Graz, Austria) to develop my "Trabajo fin de carrera" (we can translate it as "Final work of career"), that is a little project that will take me 6 months working 8 hours per day, 6 days per week (including the wrote part, you know, a wad of papers :) ) My intention was to create an object for GEM that would insert a 3D animation. But i have seen this email: http://lists.puredata.info/pipermail/pd-list/2007-12/057913.html So now, I would like to show to IEM people a new project. So do you have any proposal around GEM? If the ideas about GEM doesnt convince me, i will ask you about other things: pdp, pidip, other video tools, muslc, etc... I have to tell my knowledge about OpenGL is low-medium. br. GARFF _________________________________________________________________ MSN Noticias http://noticias.msn.es/comunidad.aspx

7 12

Re: [PD] Seasons Greetings
by Marko Timlin 21 Dec '07

21 Dec '07

Thanks a lot, very nice. I had a great laugh. MArko The time is almost upon us to to erase those brain cells collected over the last 12 months. But who will dare post first in the obligatory ASCII xmas tree thread? Mine's in Pd this year, Wishing you all much fun and happiness in the New Year, Andy -- Use the source _______________________________________________ PD-list(a)iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

1 0

Colour in Digital Video
by Andrew Brouse 21 Dec '07

21 Dec '07

Hello Claude, Matju et al, Colour perception is probably as complicated as auditory perception and the accurate representation of colour on digital video systems is probably more difficult that the accurate representation of audio. We can perceive a much wider range of colour and brightness (chrominance and luminance) than the majority of digital video systems can represent, so this wide-gamut information has to be mapped to the narrow-gamut of the systems which we have. To further complicate things, our response to brightness and colour is not linear and so those perceptual curves have to be taken into account during that mapping into video signals (chroma and luma). There are also many other non-linearities in how video displays work so that all has to be taken into account. Add the complexities of PAL, NTSC and SECAM to that and you're set for a party! Most video digitisation systems also use 'chroma sub-sampling' which is a way of reducing the amount of information which needs to be stored (this is a first level of compression or coding which occurs before anything else like MPEG compression is applied). This uses that fact that we are more sensitive to differences in brightness than variations in colour. The YCbCr (corresponds the YUV colour space of our perception) video representation uses this technique which makes it more compact while giving approximately equal quality to an larger RGB representation. Anyone working with colour video systems should know and read Charles Poynton's writing on this subject - he is the acknowledged expert. If you only have one book on your shelf it should be his "Digital Video and HDTV". He does have much useful information also on his web site: http://poynton.com/ For example, he has a guided tour of colour space here: http://poynton.com/papers/Guided_tour/abstract.html [you can also be amazed, amused or angered by the way he vacillates between 'color' and 'colour' in his writing...] hope that helps, Andrew p.s. other notable datum: Poynton taught the very first ever microprocessor course given at an art school. (In the 1970s at the Ontario College of Art in Toronto) On Wed, 12 Dec 2007, pd-list-request(a)iem.at wrote: Hi, Redirecting from GEM-dev as it's not about GEM development... Mathieu Bouchard wrote: > if you do a polar transform on YUV, you have something easier, faster > and more correct all at once. I usually just skip the polar transform: > if you apply rotations directly on YUV values, you can make very > believable hue shifts. Interesting, I'm in the process of experimenting a bit with different colour spaces, got in a real headache with XYZ and CIE L*a*b and so on, but YUV's simplicity may win. > HSV is dubious in part because the apparent brightness at maximum > so-called value is very variable and seems to peak high or low at > secondaries or primaries: compare yellow (brightness 89%) and blue > (brightness 11%). this really makes HSV suck sometimes. YUV does not > have this problem. I tried a hybrid approach: "$1 1 1" | [hsv2rgb] | [rgb2yuv] | "0.5 $2 $3" | [yuv2rgb] and that seems to eliminate the bad brightness mismatches, at the cost of some colours seeming a bit washed out (blue) or muddy (yellow). Attached image demonstrates the difference. Wondering if there's some set of "perceptual brightness curves" similar to the "isophonic curves" [1] there are for perceived loudness of different frequencies and levels led me to [2], which seems very complicated again.

4 9

fft beginner question
by cristiano figueirÿfffff3 21 Dec '07

21 Dec '07

Hi list, i'm trying to study fft in Pd and still don't understand the numbers produced by the analysis. I'm on Pd "vanilla" 0-40.2 in debian. I just patch this: [float] | \ | \ [osc~] \ | \ | [bang] | / [rfft~] / | \ \ | \ / \ | \ / [print~ imaginary] [print~ real] and then type "0" and "1" in float box and this analysis came to terminal: real: -39.604 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 imaginary: 0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 real: -39.378 -0.003371 -0.0035941 -0.0035693 -0.0035941 -0.0035851 -0.0035941 -0.0035895 -0.003594 -0.0035913 -0.0035941 -0.0035921 -0.0035932 -0.0035928 -0.003594 -0.0035931 -0.0035944 -0.0035932 -0.0035941 -0.0035934 -0.0035943 -0.0035935 -0.0035942 -0.0035938 -0.0035943 -0.0035935 -0.003594 -0.0035933 -0.0035941 -0.0035936 -0.0035942 -0.0035935 -0.0035934 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 imaginary: 0 0.07316 0.036492 0.02423 0.018069 0.014348 0.011848 0.010045 0.0086772 0.007599 0.0067242 0.0059963 0.0053794 0.0048461 0.0043795 0.0039655 0.0035944 0.0032576 0.0029496 0.0026656 0.0024016 0.0021543 0.0019211 0.0016999 0.0014889 0.0012859 0.00109 0.00090034 0.00071485 0.00053315 0.00035397 0.00017647 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 What this numbers represents ? Where i can study more? thanks cristiano Abra sua conta no Yahoo! Mail, o Ãºnico sem limite de espaÃ§o para armazenamento! http://br.mail.yahoo.com/

10 34

colour and brightness (Was: Re: [GEM-dev] Why is [hsv2rgb] implemented as an abstraction?)
by Claude Heiland-Allen 21 Dec '07

21 Dec '07

Hi, Redirecting from GEM-dev as it's not about GEM development... Mathieu Bouchard wrote: > if you do a polar transform on YUV, you have something easier, faster > and more correct all at once. I usually just skip the polar transform: > if you apply rotations directly on YUV values, you can make very > believable hue shifts. Interesting, I'm in the process of experimenting a bit with different colour spaces, got in a real headache with XYZ and CIE L*a*b and so on, but YUV's simplicity may win. > HSV is dubious in part because the apparent brightness at maximum > so-called value is very variable and seems to peak high or low at > secondaries or primaries: compare yellow (brightness 89%) and blue > (brightness 11%). this really makes HSV suck sometimes. YUV does not > have this problem. I tried a hybrid approach: "$1 1 1" | [hsv2rgb] | [rgb2yuv] | "0.5 $2 $3" | [yuv2rgb] and that seems to eliminate the bad brightness mismatches, at the cost of some colours seeming a bit washed out (blue) or muddy (yellow). Attached image demonstrates the difference. Wondering if there's some set of "perceptual brightness curves" similar to the "isophonic curves" [1] there are for perceived loudness of different frequencies and levels led me to [2], which seems very complicated again. [1] http://lists.puredata.info/pipermail/pd-list/2007-01/046213.html [2] http://www.fourmilab.ch/documents/specrend/ Claude -- http://claudiusmaximus.goto10.org

2 1

help with nqpoly4
by Ed Kelly 21 Dec '07

21 Dec '07

Hi list, &frank So I split the GUI and patching system from a drumsynth, and that works well. But, I'm trying to re-create some of my drum synths to work with nqpoly4, and I'm not entirely sure of the topology of an nqpoly4 patch. It doesn't work yet...what am I doing wrong I wonder? patches enclosed ;) Ed Lone Shark "Aviation" out now on http://www.pyramidtransmissions.com http://www.myspace.com/sharktracks __________________________________________________________ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

2 1

GISS and [pdp_theonice~] Excellent combination for stream !
by jack＠rybn.org 21 Dec '07

21 Dec '07

Hello Yves and people developing GISS. It seems that [theonice~] works very fine with the GISS system based on Icecast to create video and sound stream. I am on MacOSX.4.11 with G4 and Pd-extended 39.3. ++ Jack

1 0

kml files
by marius schebella 21 Dec '07

21 Dec '07

hi, google earth uses a special format to save geo information data (kml files). I am trying to build a (simple) gem earth projector and read these files (and also some other file types...) The conversion should be easy, but precision might become a problem. this is a shape in kml file format (longitude, latitude, height) <coordinates> -112.3348783983763,36.1514008468736,100 -112.3372535345629,36.14888517553886,100 -112.3356068927954,36.14781612679284,100 -112.3350034807972,36.14846469024177,100 -112.3358353861232,36.1489624162954,100 -112.3345888301373,36.15026229372507,100 -112.3337937856278,36.14978096026463,100 -112.3331798208424,36.1504472788618,100 -112.3348783983763,36.1514008468736,100 </coordinates> the precision is 16 digits, so I guess double float. does anyonw know, if opengl can handle that? or any quick ideas for how to approach that? marius.

13 40

← Newer
1
...
7
8
9
10
11
12
13
...
24
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 December 2007