[fluxus] Screen Recording?

[Artem Baguinski]

On 15 Feb 2006, at 14:37, Dave Griffiths wrote:

>
> I think I'd like to state that the last thing I ever want to do is  
> try to
> write a replacement for emacs ;) The fluxus editor is for livecoding,
> learning and playing around - remote control via osc gives you a  
> way to
> use a proper editor.
>

yeah, the bit i stripped from the previous mail was an alternative  
for what follows: just expose a REPL to stdin/out then i could call  
"M-x scheme" in emacs with "scheme-program" set to fluxus and edit  
files in emacs and eval them in fluxus they way i do stuff with lisps  
usually.

but after i wrote the following bit i thought, hey, but that's not  
that hard to implement and you don't need transparent emacs for  
manifesto conformance ;-)

although i do have transparent emacs.

>>   F6, while in the editor mode: evaluate current sexp, switch over to
>> repl if there was error (and display the error, obviously). this way
>> you could alter bits of the program while it is running, e.g. you
>> could alter variables, change the global state, modify functions.
>>
>> Also, if what you did was modify the function that gets called during
>> rendering, and you have a syntactic error or something, the old
>> function won't disappear and the program will continue running, while
>> you'll endup in the repl with an error message, hopefully explaining
>> what's up.
>
> I'm interested in this though, although I'm not sure I understand  
> fully
> (I'm still very much a beginner in lispy ways myself).


a simple emacs-less way to learn this sort of workflow is with  
drScheme, which is just an editor+repl (well, ok, it also has  
debugger and other stuff, but you don't see them right away).

> It's all a matter
> of guile, and what it allows, and practicalities, where/how to  
> display it.

the tricky bit here is determining what's "current sexp". the  
simplest one is counting parentheses backwards and it should be  
enough for livecoding, i guess. With extra visual feedback (instead  
of hiliting parens display "current sexp" with different colour) it  
will be ok.

things like that could be made easier if more of the interaction bits  
were written in scheme. but considering your plans about switching  
the scripting languages that doesn't sound smart atm.

> Talking of guile, I'm still interested in looking at using better
> interpreters. Rewriting the binding would be a pain, but I'll do it  
> in a
> way that we can slot different interpreters in far more easily in the
> future.

BTW, plt scheme (in which drScheme is written) is more actively  
maintained then guile and has way larger number of libraries and  
stuff. it's just as easily embeddable in C programs.

But if it doesn't have to be scheme, may i suggest lush? (although  
"rewriting bindings will be a pain")

http://lush.sourceforge.net/

it's actually three languages in one - interpreted dynamic lisp,  
compiled (via C) strictly typed lisp and embedded C.

I'm not sure about it's embeddability, but I had the same feeling  
("damn, that's what I wanted to write!") about it as when i first  
tried fluxus.

QUOTE

#  A very clean , simple , and easy to learn Lisp-like syntax.
# A very efficient native compiler (through C).
# An easy way to interface C functions and libraries , and a powerful  
dynamic loader for object files of libraries ( .o , .a and .so files)  
written in other compiled languages.
# The ability to freely mix Lisp and C in a single function.
# A powerful set of vector/matrix/tensor operations.
# A huge library of numerical routines , including GSL , LAPACK , and  
BLAS.
# An extensive set of graphic routines (including an object-oriented  
GUI toolkit , an interface to OpenGL , and an interface to SDL).
# Sound and video grabbing (using ALSA and Video4Linux).
# A library of image and signal processing routines.
# Several libraries for machine learning , neural net and statistical  
estimation.

UNQUOTE