Hi,
there's a problem with the pix_record object which is atm makes it totally unusable on debian testing. Unofortunately for me , I did a patch which relies on it, and that used to work until May , and when I reopened it in December dont work any more. Neither the official Debian package of Gem nor Pd-extended or CVS compiled version work. I asked around me a couple of other Pders and actually it doesnt look platform specific, since that, most people avoid using it and turn to pix_write, recordmydesktop and miscellaneous exotic workarounds.
So I guess it is related to the source code (i read the archive of gem-dev about hard coded 20fps and the many pd crashes that occur ) and I was wondering if there was a way have its bugs corrected (be it by the magical powers of a bounty) or will it stay postponed to the Greek calendas?
Is it more reasonable to patch a woraround with pix_write?
Thanks for any advice or opinion.
O.
pix_record crashes also in OSX 10.4 Powerbook PPC Pd version 0.41 i don´t have the gem version with me right now but i could send it soon.
best,
J
On 12/26/07, Olivier Heinry olivier.heinry@manga-burgah.net wrote:
Hi,
there's a problem with the pix_record object which is atm makes it totally unusable on debian testing. Unofortunately for me , I did a patch which relies on it, and that used to work until May , and when I reopened it in December dont work any more. Neither the official Debian package of Gem nor Pd-extended or CVS compiled version work. I asked around me a couple of other Pders and actually it doesnt look platform specific, since that, most people avoid using it and turn to pix_write, recordmydesktop and miscellaneous exotic workarounds.
So I guess it is related to the source code (i read the archive of gem-dev about hard coded 20fps and the many pd crashes that occur ) and I was wondering if there was a way have its bugs corrected (be it by the magical powers of a bounty) or will it stay postponed to the Greek calendas?
Is it more reasonable to patch a woraround with pix_write?
Thanks for any advice or opinion.
O.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Olivier Heinry wrote:
Hi,
there's a problem with the pix_record object which is atm makes it totally unusable on debian testing. Unofortunately for me , I did a patch which relies on it, and that used to work until May , and when I reopened it in December dont work any more. Neither the official Debian package of Gem nor Pd-extended or CVS compiled version work. I asked
that is very weird, as afair at least the debian package doesn't even feature the [pix_record] object. if it does, then this gets even weirder, as the debian package has not been updated for a long time (it is still the last official 0.90 release) the only thing that has changed on the debian side is quicktime (upgraded from libquicktime0 to libquicktime1), so it might be related to that.
So I guess it is related to the source code (i read the archive of gem-dev about hard coded 20fps and the many pd crashes that occur ) and
the hardcoding of 20fps should do nothing to the stability of the object. the only drawback of this is, that the recorded movie will be played back (by other media-players than Gem; which respect the framerate) at the wrong speed (too slow, too fast)
I was wondering if there was a way have its bugs corrected (be it by the magical powers of a bounty) or will it stay postponed to the Greek calendas?
- file a bug-report (please file it at pd-gem's tracker not at the
pure-data tracker)
- what goes wrong (i know that you "have problems with [pix_record]
making it totally unusable on debian testing". but which problems?
- which codec are you using?
- post tracebacks.
Is it more reasonable to patch a woraround with pix_write?
not very reasonable (though working)
i would prefer having [pix_record] fixed.
gfmasdr. IOhannes
2007/12/30, IOhannes m zmoelnig zmoelnig@iem.at:
Olivier Heinry wrote:
Hi,
there's a problem with the pix_record object which is atm makes it totally unusable on debian testing. Unofortunately for me , I did a patch which relies on it, and that used to work until May , and when I reopened it in December dont work any more. Neither the official Debian package of Gem nor Pd-extended or CVS compiled version work. I asked
that is very weird, as afair at least the debian package doesn't even feature the [pix_record] object. if it does, then this gets even weirder, as the debian package has not been updated for a long time (it is still the last official 0.90 release) the only thing that has changed on the debian side is quicktime (upgraded from libquicktime0 to libquicktime1), so it might be related to that.
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).
So I guess it is related to the source code (i read the archive of
gem-dev about hard coded 20fps and the many pd crashes that occur ) and
the hardcoding of 20fps should do nothing to the stability of the object. the only drawback of this is, that the recorded movie will be played back (by other media-players than Gem; which respect the framerate) at the wrong speed (too slow, too fast)
OK.
The really annoying bug is the following: if you use pix_record as a top-level object such as in the help file. Once you nest it into an abstraction and/or subpatch, it works the first time you record, crashes the second time.
It behaves this way on my x86 Debian Etch box, libquicktime is libquicktime0 (0.9.7-1) Benjamin Cadon told me the same happened to him (Benjamin, could you post your details?) .
I gave a try to Pure:Dyne's Gem version pix_record from puredyne-2.3.66-DVD-RC1 and beforehttp://royalrabbit.goto10.org/rl/NL_waag.org/testing/iso/puredyne-2.3.66-DVD-RC2.iso beahves the same as described before pix_record from puredyne-2.3.66-DVD-RC2 is brokenhttp://royalrabbit.goto10.org/rl/NL_waag.org/testing/iso/puredyne-2.3.66-DVD-RC2.iso(object doesnt create at all)
I was wondering if there was a way have its bugs corrected (be it by the
magical powers of a bounty) or will it stay postponed to the Greek calendas?
- file a bug-report (please file it at pd-gem's tracker not at the
pure-data tracker)
OK
Is it more reasonable to patch a woraround with pix_write?
not very reasonable (though working)
i would prefer having [pix_record] fixed.
me too! One workaround that benjamin did is to reinstatiaate the abstraction after each recording
++ O.
Oli44 wrote:
OK.
The really annoying bug is the following: if you use pix_record as a top-level object such as in the help file. Once you nest it into an abstraction and/or subpatch, it works the first time you record, crashes the second time.
i hope that i have fixed it now in the CVS version of Gem. grab it as long as it is hot and tell me, whether your problem still persists.
fgmas.dr IOhannes
Oli44 wrote:
2007/12/30, IOhannes m zmoelnig <zmoelnig@iem.at mailto:zmoelnig@iem.at>:
Olivier Heinry wrote: > Hi, > > there's a problem with the pix_record object which is atm makes it
btw, does this relate to your problem of being only able to record 4 frames?
if not, could you post more information on this bug (e.g. in the bug-tracker)?
mfga.sdr IOhannes
Le Wed, 02 Jan 2008 16:54:59 +0100, IOhannes m zmoelnig zmoelnig@iem.at a écrit :
Oli44 wrote:
2007/12/30, IOhannes m zmoelnig <zmoelnig@iem.at mailto:zmoelnig@iem.at>:
Olivier Heinry wrote: > Hi, > > there's a problem with the pix_record object which is atm makes itbtw, does this relate to your problem of being only able to record 4 frames?
if not, could you post more information on this bug (e.g. in the bug-tracker)?
Hi IOhannes, I've installed Gem from the latest Pd-extended autobuild and recording works fine, with 5000+ frames.
Nevertheless, the second recording still crashes Pd except in the help file.
I'll file another debug file to the bug-tracker
++ O.
Olivier Heinry wrote:
Le Wed, 02 Jan 2008 16:54:59 +0100,
Hi IOhannes, I've installed Gem from the latest Pd-extended autobuild and recording works fine, with 5000+ frames.
Nevertheless, the second recording still crashes Pd except in the help file.
that is very weird.
I'll file another debug file to the bug-tracker
super. please put it into pd-gem's bug-tracker (and not into pure-data's). and please add a simple example that reliably triggers the crash.
fgmasdr IOhannes
Since pix_record crashes on every second recording since dynamically creating pix_record in a subpatch or abstraction turns into a non-recording at all object
the only way i've found is to duplicate the pix_record object in as many recordings as needed and add a [demux( before so that each pix_record instance only has to record once.
bye,
O.
Le Wed, 02 Jan 2008 16:54:59 +0100, IOhannes m zmoelnig zmoelnig@iem.at a écrit :
Oli44 wrote:
2007/12/30, IOhannes m zmoelnig <zmoelnig@iem.at mailto:zmoelnig@iem.at>:
Olivier Heinry wrote: > Hi, > > there's a problem with the pix_record object which is atm makes itbtw, does this relate to your problem of being only able to record 4 frames?
if not, could you post more information on this bug (e.g. in the bug-tracker)?
mfga.sdr IOhannes
-
IOhannes m zmoelnig -
Jaime Oliver -
Oli44 -
Olivier Heinry -
Olivier Heinry -
olivier.heinry＠manga-burgah.net