<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [GEM-dev] how close are
we...</title></head><body>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>ok, so we have done double work...<br>
my [pix_*NEW] objects (video/movie) do (hopefully, not quite sure
about movie<br>
right now) support something like "color rgba" and
"color yuv" messages.<br>
they also have a "color grey" message (which i found very
handy sometimes)</blockquote>
<div><br></div>
<div>i forgot to say that my changes were to the old pix_filmDarwin
way of loading films. the old method is in good enough shape to
transfer to pix_filmNEW i suppose. is it your intention to have
the pix_filmNEW included with the next release?</div>
<div><br></div>
<blockquote type="cite" cite>would it be possible to add grey-image
support too ? (guess i hear a sigh from<br>
you)</blockquote>
<div><br></div>
<div>i can check and see what the QT support for 8bit greyscale is.
i guess there's no reason not to include it... the YUV to grey
using pix_grey should be really efficient way to do this too. it
may even be faster than the QT internal conversion.</div>
<div><br></div>
<blockquote type="cite" cite>don't know, but i guess the symbolic
reference "rgba"/"yuv"/"grey" might
be</blockquote>
<blockquote type="cite" cite>more intuitive then 0/1/?</blockquote>
<div><br></div>
<div>i fully agree with this. how about 'colorspace
rgb/yuv/grey'?</div>
<div><br></div>
<blockquote type="cite" cite>></blockquote>
<blockquote type="cite" cite>> Some things are still on the
list:</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>most of these could wait for the next
release then (if we manage to release<br>
soon ;-))</blockquote>
<div><br></div>
<div>sure. at this point, i would rather have the release come
sooner without those features than later with them.</div>
<div><br></div>
<blockquote type="cite" cite>><br>
> What does everyone else's TODO list look like right now?<br>
<br>
stability of [pix_] objects ([pix_rtx] seems to be unstable sometimes,
same for<br>
[pix_sig2pix~] and [pix_pix2sig~])<br>
need beta-testers for [pix_video] ieee1394-support under
linux.</blockquote>
<div><br></div>
<div>i played around with the pix_rtx example last night and it did
crash when resizing the video input every once and a while. the
log always pointed to line 195, which is the pixels[chRed] = rp[chRed]
in the RGBA inner loop. obviously a pointer going off into
no-man's land.</div>
<div><br></div>
<blockquote type="cite" cite>> Stability seems pretty good recently
on the OSX side, how are the<br>
> other platforms running?<br>
</blockquote>
<blockquote type="cite" cite>Gem is sometimes quite peculiar when
developing patches under linux.</blockquote>
<blockquote type="cite" cite>however, it runs rockstable in, say,
installations.</blockquote>
<div><br></div>
<div>are those usually pd crashes? i had a whole string of those
for a while a month or two ago, but they seem to have stopped.</div>
<div><br></div>
<div>quite a few of these:</div>
<div><br></div>
<div><font color="#000000">Thread 0 Crashed:<br>
#0 0x8fe01280 in halt<br>
#1 0x8fe106b4 in link_in_need_modules<br>
#2 0x8fe12230 in _dyld_link_module<br>
#3 0x90016ae8 in NSLinkModule<br>
#4 0x0003bfe4 in sys_load_lib<br>
#5 0x00038b28 in glob_initfromgui<br>
#6 0x0003281c in pd_typedmess<br>
#7 0x000357bc in binbuf_eval<br>
#8 0x0003a138 in socketreceiver_read<br>
#9 0x00039c84 in sys_domicrosleep<br>
#10 0x0003ac00 in sys_pollgui<br>
#11 0x000387f4 in m_scheduler<br>
#12 0x00038d70 in sys_main<br>
#13 0x000026b4 in _start</font></div>
<div><font color="#000000"> #14 0x000024e4 in
start</font><br>
<tt><font size="+1" color="#000000"></font></tt></div>
<div>i never traced it back to anything specific.</div>
<div><br></div>
</body>
</html>