[plt-scheme] Re: video editing and Scheme ..

From: Kumar (srikumarks at gmail.com)
Date: Thu Apr 23 00:17:41 EDT 2009

> Can't run this as it only works on Windows. However I quickly browsed

Sorry, I forgot to mention that. Business realities.

> - The effect-stack would be better named the effect-pipeline as I understand it.

I think you're right - pipeline would indeed be a more familiar name,
though you'll have
to read the list from bottom to top if you look at it that way - i.e.
as a series of
scene processing steps. The "stack" name suits the "nested effects"
kind of thinking -
along the lines of call stack or matrix stack in OpenGL.

> - If effects were values you could avoid a whole class of errors. E.g.
> instead of writing
>...
> - I'd use keywords for params, not strings (again, I think you get
> better error checking)

We're not using mzscheme and the usual compile vs runtime distinction
doesn't quite apply. Also, muSE doesn't have keyword support.

The rough analog in our case would be what we call construction time
(when the playback timeline is constructed) vs. render time (when the
timeline is played).
The Scheme code loads and runs only during construction time. Its the
first
step that happens when you hit play. Effect and parameter naming
errors *will*
be caught at construction time.

> - The model isn't clear to me. Are effects first class, for instance?

Effects are first class. You're free to do the following -

  (define (translate x y z)
     (effect "Translate" (A)
         (param "x" x)
         (param "y" y)
         (param "z" z)))

and use the function instead. One advantage of such a function is that
if you misspell it as tranzlate, muSE will not only tell you that
tranzlate
is undefined, it will also suggest that you probably meant
"translate".
That kind of suggestion usually puts a smile on my face when it
happens :)

We model effects as
   fn (start-time stop-time input-shows) -> show
where a "show" is a
   fn time -> video-frame
   (implemented at the native C++ code level)

You can therefore use function composition on effects.

> If the LGPL licence is an issue I imagine you can get an exemption if
> you contact the PLT developers.

(These hurdles were mostly about 2+1/2 years go, fyi.)

We bundle with OEMs who are very picky about open source third party
stuff in
our app. Besides we had technical trouble - we couldn't pass the
windows
"application verifier" tests due to the conservative garbage collector
accessing
what it believes to be pointers but aren't. I'd say there is more hope
with 3m
now, but I haven't tried. muSE (the scheme dialect used in Reveal)
uses a
traditional mark and sweep collector which is accurate and quite fast
(mostly under 2ms) for our purposes. The GC pauses in mzscheme were a
bit
too long and unpredictable.

... and due to app architecture, we needed multiple isolated instances
of the
interpreter that can load and shutdown quickly. mzscheme caused a
significant
load pause back then and it was hard to work with a single instance.
Then there
were some random crashes and hangs when embedded, which raised time-
bound support
issues. We were a small company too (we still are now, but bigger than
back then :).

PLT Scheme has come a *long* way since then, of course.

Regards,
-Kumar

On Apr 22, 8:37 pm, Noel Welsh <noelwe... at gmail.com> wrote:
> Can't run this as it only works on Windows. However I quickly browsed
> the docs. Regarding effects:
>
> - The effect-stack would be better named the effect-pipeline as I understand it.
> - If effects were values you could avoid a whole class of errors. E.g.
> instead of writing
>
>    (effect "Tranzlate"  ;; Typo won't be caught till run-time
>
> I wrote
>
>   (tranzlate
>
> the module system would catch the typo.
>
> - I'd use keywords for params, not strings (again, I think you get
> better error checking)
>
> - The model isn't clear to me. Are effects first class, for instance?
>
> On Wed, Apr 22, 2009 at 10:33 AM, Kumar <srikuma... at gmail.com> wrote:
> > Though we don't embed the mzscheme runtime (for various historical,
> > legal and technical reasons)
>
> If the LGPL licence is an issue I imagine you can get an exemption if
> you contact the PLT developers.
>
> HTH,
> N.
> _________________________________________________
>   For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme


Posted on the users mailing list.