<br><br><div><span class="gmail_quote">2007/12/30, IOhannes m zmoelnig <<a href="mailto:zmoelnig@iem.at">zmoelnig@iem.at</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Olivier Heinry wrote:<br>> Hi,<br>><br>> there's a problem with the pix_record object which is atm makes it<br>> totally unusable on debian testing. Unofortunately for me , I did a<br>> patch which relies on it, and that used to work until May , and when I
<br>> reopened it in December dont work any more. Neither the official Debian<br>> package of Gem nor Pd-extended or CVS compiled version work. I asked<br><br>that is very weird, as afair at least the debian package doesn't even
<br>feature the [pix_record] object.<br>if it does, then this gets even weirder, as the debian package has not<br>been updated for a long time (it is still the last official 0.90 release)<br>the only thing that has changed on the debian side is quicktime
<br>(upgraded from libquicktime0 to libquicktime1), so it might be related<br>to that.</blockquote><div><br><br>Well, I just reinstalled a debian stable instead of lenny (too much maintainance) , installed Pd-extended 0.39-3
from the Sourceforge link and pix_record works again. (CVS version compiled 2007 Oct. 21st).<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> So I guess it is related to the source code (i read the archive of<br>> gem-dev about hard coded 20fps and the many pd crashes that occur ) and<br><br>the hardcoding of 20fps should do nothing to the stability of the object.
<br>the only drawback of this is, that the recorded movie will be played<br>back (by other media-players than Gem; which respect the framerate) at<br>the wrong speed (too slow, too fast)</blockquote><div><br><br>OK.<br><br>
The really annoying bug is the following: if you use pix_record as a top-level object such as in the help file.<br>Once you nest it into an abstraction and/or subpatch, it works the first time you record, crashes the second time.
<br><br>It behaves this way on my x86 Debian Etch box, <br> libquicktime is libquicktime0 (0.9.7-1)<br>Benjamin Cadon told me the same happened to him <br>(Benjamin, could you post your details?) .<br><br>I gave a try to Pure:Dyne's Gem version
<br>pix_record from <a href="http://royalrabbit.goto10.org/rl/NL_waag.org/testing/iso/puredyne-2.3.66-DVD-RC2.iso">puredyne-2.3.66-DVD-RC1 and before</a><br>beahves the same as described before<br>pix_record from <a href="http://royalrabbit.goto10.org/rl/NL_waag.org/testing/iso/puredyne-2.3.66-DVD-RC2.iso">
puredyne-2.3.66-DVD-RC2 is broken</a> (object doesnt create at all)<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> I was wondering if there was a way have its bugs corrected (be it by the
<br>> magical powers of a bounty) or will it stay postponed to the Greek<br>> calendas?<br><br><br>- file a bug-report (please file it at pd-gem's tracker not at the<br>pure-data tracker)</blockquote><div><br>OK
<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>><br>> Is it more reasonable to patch a woraround with pix_write?
<br><br>not very reasonable (though working)<br><br>i would prefer having [pix_record] fixed.</blockquote><div><br>me too! One workaround that benjamin did is to reinstatiaate the abstraction after each recording<br><br>++
<br>O. <br></div><br></div><br>