[PD] Pix_record issue

[Olivier Heinry]

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.



signature.asc
Description: Ceci est une partie de message	numériquement signée
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Pix_record issue

[Jaime Oliver]

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 <[EMAIL PROTECTED]> 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
>
>
>


-- 
Jaime E Oliver LR

[EMAIL PROTECTED]
www.realidadvisual.org/jaimeoliver
www-crca.ucsd.edu/
www.realidadvisual.org

9168 Regents Rd. Apt. G
La Jolla, CA 92037
USA
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Pix_record issue

[IOhannes m zmoelnig]

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

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Pix_record issue

[Oli44]

2007/12/30, IOhannes m zmoelnig <[EMAIL PROTECTED]>:
>
> 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
before
beahves the same as described before
pix_record from puredyne-2.3.66-DVD-RC2 is
broken(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.
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Pix_record issue

[IOhannes m zmoelnig]

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

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Pix_record issue

[IOhannes m zmoelnig]

Oli44 wrote:
> 
> 
> 2007/12/30, IOhannes m zmoelnig <[EMAIL PROTECTED]  PROTECTED]>>:
> 
> 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

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Pix_record issue

[Olivier Heinry]

Le Wed, 02 Jan 2008 16:54:59 +0100,
IOhannes m zmoelnig <[EMAIL PROTECTED]> a écrit :

> Oli44 wrote:
> > 
> > 
> > 2007/12/30, IOhannes m zmoelnig <[EMAIL PROTECTED]  > PROTECTED]>>:
> > 
> > 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)?

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.

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Pix_record issue

[IOhannes m zmoelnig]

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

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list