← Back to team overview

scratch team mailing list archive

  1. scratch team
  2. Mailing list archive
  3. Message #00140

Re: Scratch for Ubuntu now available on our main download page

  Thread Previous • Date Previous • • Thread Next 
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

References

  Thread Previous • Date Previous • • Thread Next