Personal tools
You are here: Home community IRC Chat Logs dev@irc 05/5
Document Actions

dev@irc 05/5

by IOhannes m zmoelnig last modified 2005-08-21 08:07 PM

logfile of the 5th dev-meeting @ IRC on 19.08.2005 as found on http://artengine.ca/matju/pd-dev/pd-dev-20050819.irc

050819@12:01 * matju has changed the topic to: The PureData Chatline | The Diagram Is The Program (tm) | http://puredata.info/ | http://gridflow.ca/ | http://artengine.ca/matju/impd | PureData Developers Meeting Aug 19 16:00 UTC (*now*)
050819@12:01 matju well, almost now... waiting for Miller
050819@12:01 matju chun: are you there?
050819@12:02 matju and i cross my fingers tim can come
050819@12:02 * Ping reply from bbogart: 0.26 second(s)
050819@12:02 matju bbogart: hi
050819@12:02 mamalala dto: its uploaded, mamalala.de/dto_oggjam.dto and it will stay there until its eaten by bit-rot ....
050819@12:03 * msp (n=msp@ca-encin-ar06-millerpuckette-229.adnc.com) has joined #dataflow
050819@12:03 msp hi all... Mathuei, thanks for the pd list e-mail, I had forgotten.
050819@12:04 dto hehehe
050819@12:04 dto mamalala: please put up some text with my email address, or in the ogg comment, or something, so that i can get hired for shows and stuff. i'm completely broke :-)
050819@12:05 dto er, wait, maybe the copyright police would just come after me.
050819@12:05 dto damn, i'll have to put out something that only uses original material
050819@12:05 dto :_)
050819@12:05 * pland salutes Mr.Puckette
050819@12:06 dto hi msp.
050819@12:06 msp Hi dto.
050819@12:07 dto 12:02 <mamalala> dto: its uploaded, mamalala.de/dto_oggjam.dto and it
050819@12:07 dto will stay there until its eaten by bit-rot ....
050819@12:07 dto msp: you missed that right before you came in
050819@12:07 dto brb
050819@12:08 msp oh well, you always miss whatever was happening right before you step into a room...
050819@12:08 matju msp: you're welcome, Mirell. (you misspelt my name.)
050819@12:09 msp matju: yeah, I dkn't know how to get IRC clients to autotype names yet...:)
050819@12:09 >msp< CTCP VERSION
050819@12:09 -msp- VERSION xchat 2.0.7 Linux 2.6.5-1.358smp [i686/2.80GHz/SMP]
050819@12:09 matju msp: the Tab key.
050819@12:10 msp m: very good. :)
050819@12:10 matju msp: but my real first name is Mathieu
050819@12:11 pland are you guys just waiting for Tim now?
050819@12:11 matju pland: yes and no, he said he prolly wouldn't come
050819@12:11 pland matju: ah
050819@12:11 msp Mathieu: yep, nice sometimes to have a real name.
050819@12:12 pland london rain is really getting to me, and I haven't started the journey home from work yet :-(
050819@12:13 mamalala hello msp
050819@12:13 msp Hi mamalala
050819@12:14 matju msp: well, if people make too often mistakes in it then i'd rather have an unreal one.
050819@12:14 msp Christian: I've been having that problem for a year. Seems the C spec changed to allow on-the-spot declarations but the change isn't implementd
050819@12:15 msp in most CCs yet. I just discovered I can add -Wdeclaration-after-statement to catch them here.
050819@12:15 matju msp: ISO C 1999 allows local var decls as statements.
050819@12:15 matju msp: GCC used to default to ANSI C 1989
050819@12:15 msp matju, yep, but it looks like I have to wait until every compilo in the world agrees to that.:)
050819@12:16 matju <tim> matju: i'm not sure, if i can make it to the dev meeting ... i will meet my old landlord later ... things are a bit crazy at the moment ... not sure, if i'll stay in my new room for long :-/
050819@12:17 matju msp: well, i think GCC 2.95 has a switch for C 99
050819@12:17 matju msp: i said it's only a default
050819@12:17 msp matju, Yep, I just pored through the 1000-page 'man gcc' and found it.
050819@12:17 mamalala msp: yes, newer gcc allow for variable declarations after an instruction, the older one needs them before any instruction ....
050819@12:18 mamalala msp: and i think that gcc 2.95 is still the most installed currently ....
050819@12:18 matju mamalala: 2.95 ? really ?
050819@12:18 msp ... except on the Windows machine I use...
050819@12:18 mamalala ;)
050819@12:19 matju mamalala: the only place i still have GCC 2.95 is on a NetWinder (running a armv4l CPU at 167 MHz)
050819@12:19 msp I've been relying on Windows MSVC to catch late initializations but the ones Christian found are conditionally compiled for linux.
050819@12:19 mamalala matju: well, last time i checked, about 3 or 4 months ago, 2.95 was still in most distros as default. but of course they also offer the new gcc, but just not as default ...
050819@12:19 mamalala maybe it has changed by now, dont know.
050819@12:20 msp man do I hate developing for 3 platforms...
050819@12:20 matju mamalala: and then I'm not sure whether the comp is fried, because its power supply got submerged by the flood while the comp was running
050819@12:20 mamalala msp: i feel for you ....
050819@12:21 msp matju, theoretically the disk should be waterproof -- so at least you've got a good chance of saving the files
050819@12:21 matju msp: why do you have to take care of the Windowsers ? =)
050819@12:22 msp matju, Because nobody yet has managed to write a virus that can make it extinct.
050819@12:22 matju msp: there were no important files on it... just a custom RedHat 5.2 ...
050819@12:22 msp wow, a museum piece!
050819@12:22 matju msp: hmm, we should get a grant for writing a better windows virus.
050819@12:23 mamalala msp: maybe there are other places that would make gcc 2.95 hickup, i used configure with --enable-setuid and --enable-alsa, and with that, it was only these two
050819@12:23 msp Right, cloak it as a 'net art' project and go to Langlois
050819@12:24 matju msp: yeah. Which subway station is closest to Langlois?
050819@12:24 msp Dunno, haven't managed to get to Montreal yet :)
050819@12:25 mamalala msp: after all i got it managed to install an actual version of pd, so now i can start to port the stuff i had done for jmax to pd ....
050819@12:25 matju msp: don't worry, we'll arrange something for you one day, Monsieur Pâquette.
050819@12:26 msp mamalala, cool, see fiddle~.c for an example of something that (at least used to) compile for Max, jMax, or Pd...
050819@12:26 mamalala msp: alright, thanks for the hint
050819@12:27 pland ok see y'all. good to see you on irc Miller. Au revoir Mathieu.
050819@12:28 * pland heads into the northern line to collier's wood
050819@12:28 * pland has quit ()
050819@12:30 msp So... hmm... I remember 2 of these meetings ago, Mathieu mentioned having something to discuss that would have to await a future one...
050819@12:31 msp ... failing that, who's got major feature requests for 0.40? :)
050819@12:32 msp (only major think I'm thinking about is making it possible to use tilde objects directly on video.)
050819@12:34 matju msp: major feature requests? how many metric truckloads of them you want?
050819@12:34 matju msp: describe "video".
050819@12:35 msp more the merrier... just won't necessarily all ever get done.
050819@12:35 msp "video".. by that I mean, making "switch" able to do one-shot block computations, then making I/O objects
050819@12:36 msp to access frames from PDP.
050819@12:36 msp Pretty straightforward I think,.
050819@12:36 matju msp: what's a "one-shot block computation" ?
050819@12:37 * gige (n=geiger@mtg68.upf.es) has joined #dataflow
050819@12:37 gige hi there
050819@12:37 msp matju, I think it just means "computer this canvas's tilde objects when I send a bang to switch~".
050819@12:37 msp Hi gige!
050819@12:38 msp "compute" I mean, not "computer"
050819@12:38 msp So when a frame comes in via pdp, divide it into convenient-size chunks (maybe scan lines)
050819@12:39 msp ... and (after removing the power-of-2 restriction on block size) just hand them out as audio signals.
050819@12:39 msp Only trick is, we'd need a better object for fram buffers than "array".
050819@12:39 msp This gets back to something Tim has talked about, the need for storing smaller data types than
050819@12:40 msp floats for making large, efficient aggregates.
050819@12:40 msp )
050819@12:41 matju msp: i have also talked about it. It would help people who want to load a lot of .wav's without taking twice too much RAM, among other things.
050819@12:41 msp I think (and I think Matju thinks) that 'float' or 'double' is always going to be the fastest thing to
050819@12:41 matju msp: to... what?
050819@12:41 msp compute with, but not always the best way to store stuff.
050819@12:42 * alx1 (n=alx@HSE-Ottawa-ppp236023.sympatico.ca) has joined #dataflow
050819@12:42 msp (hmm. need a way to join uncomfortably long lines. Maybe a trailing hyphen.)
050819@12:42 matju msp: well, float is nowadays about as fast as integers, but in the 90's it wasn't the case at all
050819@12:42 matju msp: a trailing backslash ;-)
050819@12:43 msp yes, and that's the main shortcoming of Max, that I fell for the fact that integer computation on 68010 -
050819@12:43 msp was literally 300 times faster than float.
050819@12:43 msp yep ...\
050819@12:43 msp backslash is better.
050819@12:44 matju msp: 300 times? how many cycles was an ADD on 68010 ?
050819@12:45 mamalala the 68010 didnt had an fpu, from what i know ....
050819@12:46 msp correct. FP adds and multiplies were each about 300 usec. Fixed-point add was about 1.
050819@12:46 * siraj (n=siraj@HSE-Ottawa-ppp236023.sympatico.ca) has joined #dataflow
050819@12:46 matju mamalala: yeah, but it had 32-bit ints, which the x86's didn't have until the 90's (386 chip released in 1985, but in mid-1992 i paid 800$ for a 386-33 motherboard)
050819@12:46 msp At the time. I had a nice 4X to do the audio number crunching anyway.
050819@12:47 msp ... at US $200,000
050819@12:47 matju mamalala: usually 32-bit procs are twice faster than 16-bit procs for addition, and 5 or 6 times faster for multiplication.
050819@12:47 mamalala msp: for that money you could get a _really_ decent stock of high-end computers nowday ...
050819@12:48 msp IN fact I can't figure out _how_ to spend more than $1000 on a machine today.
050819@12:48 matju msp: what's a 4X ?
050819@12:48 mamalala msp: ha, no problem for that one ....
050819@12:48 msp The IRCAM digital synthesizer, 1982-1992, designed by di Giugno.
050819@12:49 msp My system was a Mac Plus and a 4X.
050819@12:49 matju msp: so, back on topic, what would be the format(s) of video supported natively by Pd ?
050819@12:49 msp .. connected in one direction by MIDI.
050819@12:49 mamalala msp: get one of those multi-core xeons together with a board to put two or 4 cpus on it. and you should already be above 1000 ... add some rambus-memory to it, and the next 1000 is gone ;)
050819@12:49 msp So, I think, native word-length float for the actual computation, and, hmmm, maybe 2 or 3 storage
050819@12:50 gige I can buy a computer for almost 1000 without FPU :)
050819@12:50 msp options. (oops forgot the \) \
050819@12:50 msp I think 16-bit yuv and 32-bit RGBA might be anough.
050819@12:50 matju msp: what do you mean by "storage options" ?
050819@12:51 msp I mean, some kind of specialized (you'll hate this) frame buffer with "read~" and "write~" objects
050819@12:51 msp \
050819@12:51 msp assocuated with it, like "table" has.
050819@12:51 matju msp: by 16-bit YUV you mean YU,YV,YU,YV,... (4:2:2) at 8 bits per value ?
050819@12:52 matju msp: why not use [tabwrite~] for that purpose ?
050819@12:52 msp Hmmm, maybe would just offer Y8 U8 Y8 V8.
050819@12:52 msp Neat idea, could just overload tabwrite~ appropriately.
050819@12:52 matju siraj: hi
050819@12:52 gige one related topic is the 64 bit problem with arrays, or is this already fixed '
050819@12:53 matju gige: it's related and afaik not fixed
050819@12:53 msp fixed...? I don't know what to do about it at all.
050819@12:53 siraj matju: hello
050819@12:53 msp ... Oh you mean the bugs. I thought you meant the deeper problem...
050819@12:53 gige i think its not really bugs, its deeper
050819@12:54 matju msp: the bugs ARE the deeper problem too
050819@12:54 matju msp: unless we're talking about other bugs ?
050819@12:54 msp I don't know how to fix the bugs until I get a 64 bit machine (RSN). \
050819@12:54 msp Deeper problem is, do we really want "array" and "table" to be 64 bit?
050819@12:54 matju msp: you need to distinguish between float arrays and word arrays.
050819@12:55 matju msp: ... which is part of the same problem as for pd video.
050819@12:55 msp Correct. At the moment, they are word arrays. Perhaps float should be an option on the same level as \
050819@12:55 msp RGBA 8-bit, etc.
050819@12:55 matju aym3ric_: are you there? what's the current video format in PDP ?
050819@12:56 msp There will be complaints for years, of course, if I don't somehow figure out how to make it coherent and extensible.
050819@12:57 matju msp: i think i have a Itanium emulator on a CD somewhere... not that anyone would use that processor, but it would do the job ;-)
050819@12:57 msp ... and of course, the "correct" way is to make Pd itself polymorphic WRT data type.
050819@12:58 matju msp: just add a type tag just like GridFlow does with its grids
050819@12:58 msp matju: hmm, sounds like more work getting an Itanium version of Pd running than to go build an athlon64 machine.
050819@12:58 matju msp: GridFlow's got types: uint8 int16 int32 int64 float32 float64
050819@12:59 matju msp: (future options being big integers, big rationals, and big floats)
050819@12:59 matju msp: what's the difference ?
050819@12:59 msp Yep. The threshold I'm afraid to cross is letting the data types work outside the "table/array" object.
050819@13:00 matju msp: what do you mean "outside"?
050819@13:00 msp For instance, having to rewrite "+" to handle n data types.
050819@13:00 msp That might preferably wait for whatever succeeds Pd.
050819@13:01 msp (Of course you can make that argument for _any_ proposed extension :)
050819@13:01 matju msp: your problem with Athlon64 is that sizeof(t_word) != sizeof(t_float) because sizeof(void*)==8. well you have exactly the same problem on Itanium, Alpha, MIPS64, UltraSparc, and almost all other 64-bit archs
050819@13:02 matju msp: rewrite "+" to handle n data types? use macros
050819@13:02 mamalala just an idea: would it make sense to port pd to c++? that way you can have add(int *a, int *b), add(float *a, float *b), etc ... and just call add(a.b) and the right version is called
050819@13:02 matju msp: or template <class T> void add_stuff (T *x, int y, int count) { ... }
050819@13:02 msp Yep. Evverything in Pd becomes a macro. It's like surgery to replace all your blood vessels.
050819@13:03 IOhannes matju: sizeof(void*)==8 ???
050819@13:03 msp IOhannes, I believe so.
050819@13:03 matju msp: your own blood vessels get replaced periodically and you don't even notice.
050819@13:04 msp Yep, just not all at once.
050819@13:04 IOhannes msp, matju: oops thought wrong; of course it is
050819@13:04 matju IOhannes: sizeof(void*)==8 on any 64-bit processor because of the size of the address-space
050819@13:05 IOhannes nah, i just didn't think for one second and there you go...
050819@13:06 matju msp: why would it be all at once ?
050819@13:08 * tigital (n=tigital@pool42.dial5-clec.noc.win.net) has joined #dataflow
050819@13:08 msp ... (trying to think how to do it incrementally)
050819@13:08 tigital sorry soo late
050819@13:09 msp Hi James
050819@13:09 tigital hello everybody
050819@13:09 matju msp: why would you _not_ allow an object to not support one of your allowed types?
050819@13:09 IOhannes hi jamie
050819@13:10 tigital yo, IO :-)
050819@13:10 msp Well ( :) since there's only one data type everything already does.
050819@13:10 gige everytime I hear more datatypes I think about how to explain that to my students... \
050819@13:10 mamalala hi tigital
050819@13:10 tigital ok, enuff with the greetings!
050819@13:10 gige one strength of pd is its simplicity ...
050819@13:10 gige if you are for complexity you canuse a real programming language
050819@13:11 msp ... or simplitity, perhaps.
050819@13:12 msp Anyhow, it seems that there would be only limited harm introducing some king of
050819@13:12 matju msp: i mean say you now allow RGBA in signals, ... do you now require all ~-objects to implement RGBA, or do they have a way out?
050819@13:12 msp special buffer object for holding smaller-than-word-size data.
050819@13:12 msp It's for a purely pragmatic reason anyway, and why build 'pragma's into the language?
050819@13:12 tigital matju: and why stop at RGBA and leave out YUV or YV12?
050819@13:13 matju tigital: you missed that part of the discussion
050819@13:13 tigital sorry
050819@13:13 msp Right. It seems to me we should have either one type or all possible types.
050819@13:13 matju tigital: msp said his choices would be RGBA and YUYV.
050819@13:13 IOhannes so the smaller-than-word-size "tables" would rid iem16
050819@13:14 msp (matju: but now I see that it should include "float32 too).
050819@13:14 matju msp: how do you implement abs~ on RGBA ?
050819@13:14 IOhannes would be nice to don't have to care any moer (not that i doo)
050819@13:14 msp nop.
050819@13:14 msp (it's unsigned.)
050819@13:14 IOhannes hmm, but the great advantage would be, that all ~-objects could be used for video-processing
050819@13:14 matju msp: in a RGBA context, what would phasor~ do ?
050819@13:15 msp but anyway, in my current thinking, abs~ would only have to deal with word-size float.
050819@13:15 IOhannes gradient
050819@13:16 msp matju, Well, filters in general pose this problem. "stateful" tilde objects probably only \
050819@13:16 msp make sense for things that go in time steps. So for example, phasor~, hmmm, should have a phase \
050819@13:16 msp for _every pixel_!
050819@13:17 matju msp: i use abs in a lot of situations in video. i use it for motion detection.
050819@13:17 msp I'm just trying to imagine the wonderful outputs you'd get. phasor~ would convert pixel luminances to frequencies!
050819@13:17 matju msp: ... because each pixel is considered to happen at a different time ?
050819@13:18 msp No, because for each pixel the previous value is the same pixel in the previous frame.
050819@13:18 msp ... anyway, if signals themselves are only floating-point, (and if the wierd data types are all \
050819@13:18 matju msp: how would one tell pd to produce a video signal in the first place? would it be an option to [block~] ?
050819@13:19 msp encapsulated in some now kind of "table"), then abs~ only sees floating-point and there's no confusion.
050819@13:19 IOhannes right, i would strongly prefer not to _really_ go for 8bit
050819@13:19 IOhannes it makes life so complicated (apart from the small gain of memory)
050819@13:20 IOhannes e.g.: a difference image is as simple as abs(img1-img2)
050819@13:20 mamalala IOhannes: and a big gain in processing speed for video ...
050819@13:20 msp matju, well, probably "signals" should distinguish between "array of successive time samples (as in \
050819@13:20 IOhannes and that is simpler to do if you don't have unsigned,...
050819@13:20 matju IOhannes: it's as simple as [# abs-]
050819@13:20 msp audio) and "array because it's really an array" (as in 2D arrays for frames.)
050819@13:21 IOhannes matju: well, it is as simple as [pix_diff], but that is not the point
050819@13:21 tigital matju: in some ways, we can already make a video signal via [vertex_tabread], which IOhannes made fairly recently: it converts tables to vertex arrays, and wouldn't be too hard to convert tables to frames
050819@13:21 IOhannes mamalala: we'll have to go for sse2/3/4 and AltiVec anyhow (if miller likes it)
050819@13:21 matju IOhannes: the same [# abs-] does it on uint8, int16, int32, int64, float32 and float64.
050819@13:22 matju IOhannes: miller likes SSE ? since when ?
050819@13:22 IOhannes matju: does he
050819@13:22 IOhannes ?
050819@13:22 msp je _hates_ SSE :)
050819@13:22 matju msp: what's your rationale? it looks too much like Cray ?
050819@13:23 msp Just can't stand having 1000s of lines of conditionally compiled cruft.
050819@13:24 msp But on the other hand, if this were compartmentalized in a specialized object for storing and
050819@13:24 matju msp: cruft ? watch your language =)
050819@13:24 mamalala just using mmx/sse instructions without thinking about ordering them doesnt give a big gain .....
050819@13:24 msp retrieving compressed data, then that doesn't peeve me all that much.
050819@13:24 matju msp: compressed data? where does that come from?
050819@13:24 IOhannes matju: [# abs-] (and moreso [pix_diff]): i prefer core-pd objects (that are low level like [-] and [abs]) to higher level objects ([abs-])
050819@13:25 matju msp: Tim's work is not about compressing stuff, it's about processing stuff.
050819@13:25 msp In fact, YUV is just a hack anyway, why not go it the whole 9 yards.
050819@13:27 msp RIght, that's the distinction between using, say, SSE to compress stuff, and using SSE to implement "+~" on \
050819@13:27 matju IOhannes: GF has [@! abs] as a unary operator, but i figured out things: 1. unary operators are too few in GF to be worth the trouble; 2. abs is almost always after -; 3. abs- without a righthand value has the same effect as abs; and 4. abs- is useful with the uint8 type while both abs and - are useless.
050819@13:27 msp regular floats. If it's used for bashing floats into YUYV format, that's not the "real" computation.
050819@13:27 msp ... (since it's just to store it in some black bag somewhere.)
050819@13:28 IOhannes matju: i favour 4
050819@13:28 * Anton- has quit (Read error: 104 (Connection reset by peer))
050819@13:28 mamalala msp: but sse can help for that task as well
050819@13:28 dto hi mamalala
050819@13:29 mamalala dto: ? been here all the time ... ;)
050819@13:29 msp Right, and I don't have any fundamnetal argument against using SSE for YUV conversion (whereas I think \
050819@13:30 msp it's a bad idea to use it for otherwise canonically defined operations such as "+~").
050819@13:30 IOhannes i admit, i don't understand this rationale
050819@13:30 mamalala msp: no, it isnt. sse allows also to add floats, etc. and for that purpose, you have 4 floats in one sse register that will be added to another 4 floats in another sse register at once
050819@13:31 tigital msp: so are you thinking of creating an intermediate representation of the signal graph that can then be optimized on the fly via vector ops, without color conversions (ie. a jit)?
050819@13:31 tigital msp: y'know, identify seperable/non-seperable filters n'all...?
050819@13:31 msp tigital, No, the opposite. I'd rather hide YUV inside a specialized storage object so nobody ever \
050819@13:32 matju IOhannes: and 5. by graduating in math, i have come to think of abs- as a low-level operation.
050819@13:32 msp sees it (except as degradation).
050819@13:32 mamalala msp: its just a bad idea to replace native c instructions with single sse instructions, because of the pipelining of these instructions. taking care of that fact and
050819@13:32 mamalala using as much registers as possible at once, it will give a huge gain.
050819@13:32 matju IOhannes: my favourite reasons are 1,2,3,4,5, though not in that order.
050819@13:33 msp matju, My favorite of the first 5 whoe numbers are 1,2,3,4,5 althgouh... :)
050819@13:33 msp (oops, positive integers I mean)
050819@13:33 matju IOhannes: ... and these reasons do not make as much sense separately than as a whole... it's... Gestalt argumentation =)
050819@13:34 msp mamalala, well, the difference I see is not an efficiency issue but one of maintaining portable and
050819@13:34 msp coherent code that can work in the longer term.
050819@13:34 IOhannes did i bring this discussion (on SIMD) up ??
050819@13:35 matju msp: what makes you believe that YUV is a hack ? does that cover all YUV's or just some ? (there _is_ uncompressed YUV, and I use it.)
050819@13:35 * ClaudiusMaximus (n=claude@81-179-66-191.dsl.pipex.com) has joined #dataflow
050819@13:35 msp I'm convinced that SSE or Altivec can speed up floating point operations if used wisely. But...
050819@13:35 msp ... in 10 years, if the conde won't compile at all (because SSE instructions have morphed) it's not a real long-term gain.
050819@13:36 IOhannes matju: i think the mere fact that YUV has always been a hack (in the history of tv)
050819@13:36 mamalala msp: what about using function pointers in objects like +~, *~ etc. that get initialized with the functions, which could be loaded from a library?
050819@13:36 matju msp: what do you mean by "canonically defined operations" ???
050819@13:36 msp matju, The same way as polar coordinates are a hack.
050819@13:36 mamalala msp: that way there can be a default-lib in native c, and extra libs for mmx, see, altivec, etc. which will re-initialize those pointers to the accelerated versions ....
050819@13:38 mamalala that way the core code of these objects stays the same always, and the libs can be maintained seperately .....
050819@13:38 msp mamalala, Well, that's what the jMax crew did. It ended up pretty ugly.
050819@13:39 matju msp: SSE instructions morph ? you mean like the evil aliens that come to steal your blood vessels during your sleep in order to manufacture high-end violin strings on their planet?
050819@13:39 msp matju, It's like storing your data on a 5-inch floppy. Theoretically it's still there after all these \
050819@13:40 msp years but it gets harder and harder to read.
050819@13:40 matju IOhannes: is YUV a hack or just the fact that YUV is compressed?
050819@13:40 msp IOhannes, No, I think it came up as part of the idea of data-compressed frame buffer storage.
050819@13:41 matju msp: do you still believe in C's + operator?
050819@13:41 mamalala msp: sure? from what i remember, they didnt use any accelerated stuff at all. and the routine for adding was still out[x] = in1[x] + in2[x], instead of a (function*)(out, in1, in2)
050819@13:41 IOhannes hmm ? i always thought the main idea of (uncompressed) YUV is to stay compatible with b/w-TV
050819@13:41 mamalala (inside the +~ object, for example)
050819@13:41 IOhannes on YUV: and that was hack (imho)
050819@13:42 matju msp: why are polar coords a hack ?
050819@13:42 msp mamalala, Oh, they must have cleaned it out after I stopped following it. \
050819@13:43 IOhannes i'm wondering too (i agree that cylindrical coords are a bit hacky)
050819@13:43 msp Originally (and this was my own fault) there was a separate, machine-dependent layer for \
050819@13:43 msp doing that actual computation.
050819@13:43 matju IOhannes: dunno about the intent, but i certainly have used YUV to make easy hue-shifts... i just rotate the color space along the Y axis
050819@13:43 msp matju, Right. And polar coordinates are a hack for making rotations fast.
050819@13:43 IOhannes matju: hacks tend to have their goodies
050819@13:44 IOhannes msp: now i get your "hack"
050819@13:44 matju msp: hmm? aren't rotations faster with cartesian coords ???
050819@13:45 IOhannes if your pivot point is the origin ??
050819@13:45 msp Polar: theta = theta + dtheta; rectangular: (a,b) *= (c -s ; s c)
050819@13:45 msp IOhannes, yes, of course I wasn't thinking about all thos _other_ rotations :)
050819@13:45 matju IOhannes: YUV could also be considered "psycho-oculars" just like MP3/OGG have psycho-acoustic features. now go tell psychoacousticians that they're hacks =)
050819@13:46 matju msp: ok, but don't you have to convert to cartesian at each time you use them with a display ?
050819@13:47 msp matju, yes, psychoacousticians are hacks.
050819@13:47 IOhannes matju: YUV is not "psycho-oculars"; it just makes a special "psycho-ocular" compression rather simple (another benefit of this hack); but that is compressed YUV
050819@13:48 mamalala msp: yes, there is such a thing in jmax, but that is not what i mean ....
050819@13:49 mamalala anyway, im away for a while ...
050819@13:49 * mamalala is now known as mamalala_away
050819@13:49 matju msp: converting to polar and/or back is slower than a matrix-multiply, at least in 2-D, maybe even in 3-D and 4-D.
050819@13:49 msp matju, and (perhaps this is a punch line) my frame buffer storage object idea is a hack too.
050819@13:49 IOhannes on YUV: otoh, the whole history of TV is of course depending on psycho-ocular phonemenons
050819@13:50 IOhannes apart from the reduced data-width; what would be the benefits of the frame-buffer-storage-object (tell me if i have to read the logs)
050819@13:50 matju IOhannes: whatever. you can plug-and-play YUV with various subsampling techniques and boom! you've got psycho-oculars.
050819@13:50 msp matju, so the real issue in designing a frame buffer is to balance memory bandwidth with cost of conversion to the data-reduced format in question.
050819@13:51 matju IOhannes: ... and i mean various *obvious* subsampling techniques that were already used elsewhere
050819@13:51 msp matju, Like digitization.
050819@13:53 matju anyway, i didn't mean to defend the YU,YV,YU,YV,... (YUV422) layout, as i don't use it, and don't plan to use it. I only use the YUV,YUV,YUV,... system.
050819@13:53 msp matju. so, (convert to YUV->hueshift->convert to RGB) is cheaper than (hushift in RGB)?
050819@13:54 matju msp: ok, from now on, i don't care what you call a hack or not.
050819@13:54 tigital msp: how are you imagining displaying the "frame buffer"? is pd going to have a graphic window via tk, or gl, or ...?
050819@13:54 matju msp: depends. how do *you* do hueshift in RGB ?
050819@13:54 msp Right. we all use computers after all, and that's just a hack.
050819@13:54 msp 3-d rotation matrix multiplication.
050819@13:56 msp OH, but now I realize you might want to prevent numbers for going negative. To do that, yes, essentially you have to go to YUV.
050819@13:58 matju msp: ah ok, well i'm using the same shortcut. because the relationship between RGB and signed YUV is linear, i only transform the canonical base of RGB through the YUV hueshift, and then i apply the resulting matrix to a picture using the [#inner] product.
050819@13:58 matju msp: (that's what [#hueshift] does)
050819@13:58 msp Anyway, the most interesting question I think I have is, how is data best stored and recalled from a frame buffer?
050819@13:59 msp "normal" operations might be, "give me a sub-rectangle" (specifying 4 numbers for each frame) or \
050819@13:59 tigital msp: I think it depends on whether you want to maintain it "display ready"
050819@13:59 matju msp: even in full YUV you can't avoid getting negative numbers. you have to clip the values.
050819@14:00 msp (much more general) here are two planes to specify (X,Y) locations to look up pixels.
050819@14:00 matju msp: the "much more general" way is what GridFlow provides thru the [#store] object
050819@14:01 matju msp: (except that [#store] is even more general than that)
050819@14:03 * alx1 is now known as alx_away
050819@14:06 msp I'll have to sign out in a few minutes (someone coming at 11AM nominally)...
050819@14:07 msp (== 19GMT I think)
050819@14:07 IOhannes so 7minutes ago..
050819@14:07 matju msp: e.g. using a (240,320,2) grid to index into a (480,640,4) grid will result in a (240,320,4) grids with pixels taken from the second grid at positions given in the first grid
050819@14:07 matju IOhannes: the UCSD timezone is a bit later than PDT it seems ;-)
050819@14:07 * Anton___ (n=Anton__@huizesteijnstraa.demon.nl) has joined #dataflow
050819@14:08 msp yeah. The visitor is French :)
050819@14:08 Anton___ good evening
050819@14:08 Anton___ is it a dev meeting?
050819@14:08 Anton___ is *this
050819@14:08 matju msp: oh. are you hiring Francois Déchelle ? ;-)
050819@14:09 IOhannes it almost _was_ a dev meeting
050819@14:09 matju Anton___: yea...
050819@14:09 Anton___ ah :)
050819@14:09 Anton___ ok ill but out for a sec then :)
050819@14:09 IOhannes Anton___, no, you can stay
050819@14:09 Anton___ no worries ill be lurking ;-)
050819@14:09 matju Anton___: my sentence no verb too
050819@14:09 Anton___ i just drove onto a bridge that was opening
050819@14:09 Anton___ ....
050819@14:10 IOhannes gcc-4.0 gives me 4 warnings when compiling pd-0.39test5
050819@14:10 Anton___ missed the closing gates and the stoplights
050819@14:10 matju Anton___: ouch
050819@14:10 Anton___ yup
050819@14:10 Anton___ in my mums car too :-/
050819@14:10 gige ok, chic@s I am leaving too, got distracted anyhow, see you soon
050819@14:10 Anton___ so anyways, i guess im not as awake as i should bw :)
050819@14:10 msp IOhannes, is gcc 4.0 widely distributed yet?
050819@14:10 IOhannes msp: not yet, but it is definitely coming
050819@14:11 IOhannes msp: the new os-X ships with it (i think)
050819@14:11 matju chicas? :-}
050819@14:11 gige :)
050819@14:11 IOhannes msp: debian/etch comes with it
050819@14:11 msp hmm... maybe just send me the warnings and I'll try to patch for now.
050819@14:11 msp cheers
050819@14:11 IOhannes ok, bye!
050819@14:11 msp (i.e. about to leave at last..)
050819@14:11 tigital msp: I'm using gcc 4.0
050819@14:11 * gige has quit ("Leaving")
050819@14:11 * Anton___ (n=Anton__@huizesteijnstraa.demon.nl) has left #dataflow
050819@14:11 * Anton___ (n=Anton__@huizesteijnstraa.demon.nl) has joined #dataflow
050819@14:12 tigital but on osx, gcc 4.0 only supports 10.3.9+
050819@14:12 IOhannes msp, i'll send a patch (but they are really minor warnings)
050819@14:13 msp tigital, I'll go get a new OSX soon and can see.
050819@14:13 tigital msp: I've had no probs with it and tcl/tk 8.4.10, unlike others...
050819@14:13 tigital also been having no probs with devel_0_39...
050819@14:14 msp Probably my problems are that I'm not actually installing TCL/TK (because I want to verify that Pd runs out of the box).
050819@14:14 IOhannes tigital, i don't have problems either; it is just cosmetic
050819@14:14 msp So I think my trouble is all coming from the changes in installation configuration .
050819@14:14 tigital could be, but I would imagine that problem would show up earlier than the reported "can't front process" or whatever
050819@14:14 msp Anyway, I think I have to start with 8.4.5 for now as it's the lastes I can see that's
050819@14:15 tigital 8.4.7 is shipped with 10.4
050819@14:15 msp OK to run out of the box on older OSX versions.
050819@14:15 msp (I'm trying to keep Pd available back to OSX 10.2.)
050819@14:16 tigital I've really been putting in some effort to fix up hans' package scripts
050819@14:16 tigital msp: sure, but it's also nice to take advantage of newer things too
050819@14:17 msp tigital, I notice my students frequently have 2-year-old systems. It would be ideal if I released versions \
050819@14:18 msp that ran on 10.2 (not using nice new stuff) and 10.4 (up to date)...
050819@14:18 msp Anyway, really signing off now!!! thanks to everyone.
050819@14:18 msp M
050819@14:18 tigital bye
050819@14:18 * msp has quit ("Leaving")
050819@14:18 IOhannes bye
050819@14:19 tigital IOhannes: just occurred to me that we should use function-overloading more in the opengl wrapper stuff
050819@14:20 tigital instead of all the i, d, v, etc variations
050819@14:21 tigital also, I've been thinking abit more about multiple_windows...
050819@14:21 tigital one of my main interests there is to enable robust offscreen rendering...
050819@14:22 tigital and the hang up seemed to be "how do we deal with different framerates"?
050819@14:22 tigital but I was mistakenly lumping offscreen rendering into the generalized multiple_windows idea
050819@14:23 tigital pbuffers and such could actually be dealt with in a manner very similar to [pix_snap]
050819@14:24 tigital so, the question is, do we make one object for the various flavors (render to texture, pbuffer, pixel_buffer_objects, frame_buffer_objects)...
050819@14:24 IOhannes yes, i am not really sure
050819@14:24 tigital or make individual objects: [pix_snap], [pix_pbuffer], [pix_pbo], [pix_fbo]
050819@14:24 IOhannes lately i thought it might be best to use one offscreen-rendering object
050819@14:25 IOhannes that outputs GemPix and which you can feed to...
050819@14:27 * shift8 (n=shift8@netblock-66-159-222-94.dslextreme.com) has joined #dataflow
050819@14:28 tigital well, that brings me to another thing we REALLY need right now :-)
050819@14:28 tigital multitexture support
050819@14:29 IOhannes what i think we really need is a new release with the vertex-stuff finally done
050819@14:30 tigital it'd be easy to add an outlet to pix_texture (or other gempix output objects) that would either just output number of the created/assigned texture unit...
050819@14:30 tigital or a message that says "textureUnit x"
050819@14:30 IOhannes ah yes, that is exactly how i imagined it
050819@14:30 IOhannes i would prefer a separate outlet, so the connected (downstream) objects have no notion about it
050819@14:31 tigital then we can just accept that somewhere else for binding, and voila, we get access to up to 8 different vram buffers
050819@14:31 tigital my thoughts exactly
050819@14:31 IOhannes so we just do it ;-)
050819@14:32 * punchiku (n=asds@212.106.249.195.adsl.jazztel.es) has left #dataflow
050819@14:32 * punchiku (n=asds@212.106.249.195.adsl.jazztel.es) has joined #dataflow
050819@14:32 punchiku : /
050819@14:32 tigital then we'd need a [pix_multitexture] that would allow for message of doing src alpha dst kindof stuff
050819@14:33 tigital perhaps it'd have three inlets, one for gemchain, then one for srcA and another for srcB
050819@14:34 IOhannes seems good to me
050819@14:34 tigital this opens up alot of possibilities, especially with the vertex and fragment programs
050819@14:35 tigital cuz ya really need offscreen rendering and the ability to address multiple texture units to get the most outta gpu programming
050819@14:36 tigital ok, so I won't be able to do this tonight, but that and the paper will be for the weekend...
050819@14:36 tigital btw, thanks for bringing the vertex_array branch up to date: I was dreading that ;-)
050819@14:36 IOhannes but what should we do with it now ?
050819@14:37 IOhannes i mean, everything in there is now (spoilt ;-)) by my unified arrays.
050819@14:37 IOhannes it'll be a lot of work to make this undone
050819@14:37 tigital well, yeh, that's a problem :-)
050819@14:38 tigital I love unified arrays in the abstract, but implementation-wise, I don't think we can ignore the buffer_object api implementations...
050819@14:39 IOhannes another thing for the multi-texture thing: i think we would need an outlet for the texure-id too (while er are at it)
050819@14:39 tigital uh, I thought that's what I was talking about?
050819@14:40 wip dmorelli, hi, nice. maybe i can help with the makefile for linux!
050819@14:40 IOhannes yes i thought so too, but then the openGL-specs somewhat differ about what is a "texture unit" and a "texture-id"
050819@14:40 IOhannes but good to know we are talking about the same thing ;-)
050819@14:40 tigital oh, good point
050819@14:40 wip dmorelli, what is the command line to checkout your stuff?
050819@14:40 IOhannes anyhow, back to the vertex stuff
050819@14:41 IOhannes tigital, the only fear i have is, that once someone really does a benchmark, that the general stuff will not perform that bad...
050819@14:41 tigital yr right, but texture-id is assigned at binding, so it'd be an outlet, and texture unit is more an inlet, something we assign to
050819@14:41 tigital one sec
050819@14:42 IOhannes two secs
050819@14:42 IOhannes three secs
050819@14:42 tigital yr worse than a ticking time-bomb under the table!
050819@14:43 tigital I was trying to look up the vbo specification to make sure that we need specific buffer sizes when using mapped buffers
050819@14:44 tigital http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt
050819@14:46 tigital maybe we're ok if we just stick to indexed buffers?
050819@14:48 tigital hmm:
050819@14:48 tigital How is unaligned data handled?
050819@14:49 tigital RESOLVED: All client restrictions on data alignment must be met,
050819@14:49 tigital and in addition to that, all offsets must be multiples of the
050819@14:49 tigital size of the underlying data type. So, for example, float data in
050819@14:49 tigital a buffer object must have an offset that is (typically) a
050819@14:49 tigital multiple of 4. This should make the server implementation
050819@14:49 tigital easier, since this additional rule will guarantee that no
050819@14:49 tigital alignment checking is required on most platforms.
050819@14:50 tigital ...there's alot here to digest, and until that happens, I'll remain skeptical about the unified buffers, at best :-\
050819@14:51 IOhannes yes, i started reading and i just noticed that i have just finished 25%
050819@14:51 IOhannes i guess,i'll not do that right now (it is evening here...)
050819@14:53 * mamalala_away is now known as mamalala
050819@14:53 mamalala re ....
050819@14:53 tigital IOhannes: yeh, could be a good sleeping aid :-)
050819@14:53 tigital mamalala: re...? (howdy)
050819@14:57 IOhannes tigital, another question about the pix_record
050819@14:59 IOhannes (or probably i'll just wait until chris or someone else with knowledge of quicktime answers it on the list)
050819@14:59 tigital yeh, I haven't even tried it out yet :-)
050819@15:00 IOhannes it compiles fine on my machine (but then: everything is within a big __APPLE__ ;-))
050819@15:01 mamalala tigital: re as in back again .... ;-)
050819@15:01 tigital mamalala: aha, "the return of..."!
050819@15:02 tigital IOhannes: sounds like you have a new pix_nop ;-)
050819@15:04 * alejo has quit (Read error: 104 (Connection reset by peer))
050819@15:04 IOhannes yes i love these
050819@15:14 IOhannes ok, i think i'll go to bed now
050819@15:15 IOhannes should we do a gem-dev meeting here soon ?
050819@15:15 tigital ok, pleasant dreams
050819@15:15 IOhannes or have we (jamie and me) discussed everything for now ?
050819@15:15 mamalala c ya IOhannes, good night!
050819@15:15 tigital fine with me:
050819@15:15 IOhannes ok
050819@15:15 IOhannes bye, then
050819@15:15 * IOhannes (n=IOhannes@a-129.dsl.tu-graz.ac.at) has left #dataflow ("Leaving")


Powered by IEM Powered by Plone Section 508 WCAG Valid XHTML Valid CSS Usable in any browser