Hi John,
In short, I'd like to stick to the current Scratch camera plugin, even
if it overlaps with the Squeak camera plugin and even if it is only a
"stub" on some platforms.
Ok.
Thanks for working the Camera issues for Linux and XO. As you may
know, I'm working on a new XO release of Scratch (the first Scratch
1.4 XO release, with new Journal support from Bert), so the timing is
excellent.
With the post tonight from Amos we could fall back to the previous
version of the Camera plugin but hopefully I can find out tomorrow why
the latest version is failing. On the XO I suspected a driver problem
when I looked at it a month or two back so possibly a separate issue
altogether. Will know more by the end of the week.
re v4l plugin for Scratch...
Would this change require changing the primitive calls to the Scratch
camera plugin?
If the existing Scratch camera dialog/facilities are to remain the same
then I suppose adding the v4l plugin to Scratch is only important if you
are still aiming to avoid a custom Linux VM for Scratch (I'm possibly
mistaken in thinking this was part of the effort of getting a package
accepted into the repositories, specifying the squeak VM as a
dependency). I also realise that even if Scratch adopts the v4l plugin
then the Windows Camera plugin (hence primitives) is still required. So
my first thought was a small amount of intermediate code in Scratch to
check the OS platform to decide to use either the Camera or v4l plugin.
To minimise impact on Scratch code I was also thinking of faking the
existing Camera protocol in the v4l plugin classes. That said, if using
the Squeak VM is not a priority then simplest option is to keep using
the existing Camera plugin.
You mean, you'd do image recognition to extract numbers from a video
image of the LCD display. What a cool idea!
Yep. The electricity companies over here are giving away wireless power
consumption monitors. Then I picked up a wireless heart rate monitor for
£8 at my local supermarket and a wireless weather station can be had for
~£15 (I'm a sucker for cheap tech :-) ). I first looked into the
wireless spec's hoping they were bluetooth in all but name, supposedly a
common thing to avoid licence fees. Next I inspected the rx'er hw to see
if there was some form of diagnostic port that could be hooked up to a
computer. Then it dawned on me it would be relatively simple to throw
together an Etoys project to recognise the segmented displays that all
these devices tend to use. Same applies to cheap digital multimeters. No
electrical connection = very safe technique for kids to use. My plan now
is a script-able morph to overlay each digit in the video image so Etoy
users can quickly/simply/safely/cheaply create an interface to
real-world data.
-D
On 20/04/10 14:04, John Maloney wrote:
Hi, Derek.
Thanks for working the Camera issues for Linux and XO. As you may
know, I'm working on a new XO release of Scratch (the first Scratch
1.4 XO release, with new Journal support from Bert), so the timing is
excellent.
Re:
> Did you mean to say you tested on another earlier version and found
that it worked?
yep, works fine in scratch_1.4.0.debian.12_i386. I also looked at an
svn checkout I have from around 21st Feb but the Camera plugin was
missing at that point (I vaguely remember querying it's absence).
to OS changes. I will pull another svn version this week and do some
digging.
This is a mysterious problem. Maybe a wrong compiler setting was used?
Thanks for digging.
Re:
It's true, Scratch 2.0 will likely be all Flash based. But it's also
likely
to take a long time before we're ready to release - at least a year I'd
guess.
That's right.
Re:
So it might be helpful to use V4L (we already do as a library, right?
Or do you mean a closer connection?) I expect people will continue
using the
squeak based software for some time after 2.0 is released, depending
on the
success of our efforts to make an offline flash based version.
If we did a Scratch 1.4.1 release in the next year, that would be a
chance to switch to using the Squeak V4L plugin for Scratch on *all*
platforms. For now, I'd prefer to stick with the Scratch camera plugin
so I don't need to change the Squeak code. I try to minimize
differences in the Squeak code across platforms. Ideally, the same
exact Scratch.image file would run on all platforms, which that was
the case until quite recently. Unfortunately, the latest Linux release
has some patches, and the XO version will have its own patches for
Journal support. But every patch is a chance for things to go wrong,
so I strive to minimize them.
In short, I'd like to stick to the current Scratch camera plugin, even
if it overlaps with the Squeak camera plugin and even if it is only a
"stub" on some platforms.
Re:
1) the Camera plugin, which on Linux is just an interface to v4l
anyway, could be dropped = less need for a custom VM for Scratch,
especially if Ian adopts the "Scratch" plugin (ugh, the naming is
confusing, I have to read things myself two/three time to make sure
what I write makes sense :-) ). Scratch protocol would remain the
same, since Windows plugin still required.
Would this change require changing the primitive calls to the Scratch
camera plugin?
Re:
2) direct use of v4l in-image makes it easier to provide more
controls to the user, vis-à-vis directshow properties dialog on
Windows, gaining x-platform parity.
I don't think the Scratch would ever want to show the DirectShow
properties dialog, although that might be useful for Squeak and EToys.
Re:
Despite the above, I know that Camera use is not a key feature or of
prime importance to most Scratch users. Maybe it would be if costumes
could be dynamically updated from the camera via Scratch blocks
(cough, done-it, cough).
Yes, live video is great! Sorry that feature did not make it into
Scratch 1.4.
Re:
I have a few ideas on the back-burner for Etoys projects based around
non-contact interfacing of various cheap sensors (power monitors,
weather stations, etc) that provide LCD displays but no easy way to
directly connect to a computer. The camera will be used to read the
LCD. Would be nice to do the equivalent in Scratch for others to use
:-) Anyways, that's my reason for being nosey about the direction of
future scratch releases.
You mean, you'd do image recognition to extract numbers from a video
image of the LCD display. What a cool idea!
Re:
One final note, on last nights Etoys mtg Bert expressed a preference
for a simpler Camera interface for Etoys based on the Scratch plugin,
which I read to mean Ian also adopting Scratch's "Camera" plugin
(Bert, correct me if I'm wrong). I do see the attraction but it still
leaves the Scratch user at a disadvantage on Linux since they cannot
(easily) choose the video source and, as stated above, have no access
to video controls.
Scratch strives for simplicity, sometimes at the expense of
flexibility. Scratch's camera interface it optimized for the case of a
single camera (by far the most common case). I doubt that we'd want to
give users a way to choose between multiple cameras, even if the
underlying plugin supported that. Likewise, Scratch is unlikely to
provide a camera settings dialog. Of course, it can be useful for
someone who knows what they are doing to be able to tweak the camera
settings, but for Scratch we like to keep things really, really simple.
One argument in favor of a minimalist camera plugin is that it is
easier to port to new platforms. But you can ask Bert why he prefers
the Scratch camera plugin.
-- John
_______________________________________________
Mailing list: https://launchpad.net/~scratch
Post to : [email protected]
Unsubscribe : https://launchpad.net/~scratch
More help : https://help.launchpad.net/ListHelp
