[GEM-dev] unicap?

[IOhannes m zmoelnig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,

would it be a problem for you if we moved this thread onto a mailing list?
i really prefer this way of communication, as it allows more than a
single person to profit (and help!)

On 2011-01-23 13:55, kubro bubro wrote:
> sorry, right now i cant offer you money, but ill try to do something
> with that.. i need to wait for payed project
> 
> picture is still white.
> unicap is loaded, but transfer doesnt start, because failed to query format:
> 
[...]
> verbose( 1):[pix_video]: starting transfer
> verbose( 1):failed to query format

oha, it's a bit weird that you cannot even _query_ the format.
i'm a bit at a loss, as to how to react on this (but fail).

right now, only system buffer support is implemented in Gem, assuming
the unicap will always provide a "fake" system buffer, if the underlying
device cannot do so. (i'm not sure about this though).
but even if i implemented user buffer support, i still would need to
know which transport is actually used and thus the "query" has to succeed.

> 
> maybe this is normal, but im not able to set properties:
> directly setting menu-value to 'Composite 1' (please report if this works!)
> verbose( 1):could not set property 'source'


unfortunately i cannot test menu-values, as i don't have any device that
offers a menu-value :-.(

just to make sure: how exactly do you try to set your source?
i  think it should be something like:
|...\    (symbolbox)
|
[set source $1(
|
[pix_video]

and then type "Composite 1" into the symbolbox (this is an easy way to
create a symbol with spaces)


another way that _should_ work, is

[set source 0(
|
[pix_video]


if you can confirm that this (source <int>) works and that (source
<symbol>) does not, i have an idea how to fix the underlying code)


apart from all that, i found that unicap does not reliably start the
transfer.

e.g. using my PS3 i have to first set the size with "dimen 640 480" to
the only support dimension of the device (i'm using the normal kernel
drivers), since unicap always believes that the only supported size is
768x576, but then fails to capture images.
it is also crucial in which order things are called (e.g. i have to do
[dimen 640 480( and only then start rendering/capturing/transfer, else i
don't get an image for the rest of the Pd-session.
on my eeePC, it is slightly different, but i have to explicitely set the
device before i can acquire images.

all in all, unicap support is still quite experimental.

i'm using stock debian's unicap though, which is a bit outdated (0.9.5)


fgmasdr#
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk09NjkACgkQkX2Xpv6ydvS7MgCg9TBzoXaOVP/gnu5Cvvq5PMBe
FDEAoMnBpmDGDF79D5VE/l9z/vodc+cV
=kopB
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20110124/ef79193d/attachment.bin>