[Gridflow-dev] ping (fwd)

[Mathieu Bouchard]

On Sat, 4 Sep 2004, Tom Schouten wrote:

> what i am trying to do, is to stay true to the concept and take it
> very far. the fact that i'm dragging forth in the picture is because i
> like it, and because there are a lot of parallels between forth and
> unix style 'patching'.

Then I think you can make that parallel between any two sufficiently
powerful languages, unless I'm mistaken as to the nature of Forth.

> now, what's the problem with unix and media processing? meta data. it
> is hard for programs to talk with each other, because there is not
> really a general protocol for doing this. 'ordinary' unix works with
> text, but doing this for practical media processing quite unrealistic.
> there's just too much data moving about.

In (all) dataflow systems, such as Pd and UNIX, one major problem is that
there is no primitive for return values or callbacks. This is pretty
normal, as it's the point of the dataflow paradigm. Maybe a variant of
dataflow could include the possibility for backward messages, that go from
"outlets" to "inlets". I once thought about a concept of "sidelets" for
that. Else the only way to achieve it seems to be to reserve inlets and
outlets specially for messages going the other way. The best example of it
in GridFlow is [#remap_image].

Another problem is the transmission of information that is not sequential.
In the case of a tree, there are several easy serializations, notably the
"depth-first" way as used in HTML/XML/YAML/LISP/etc. In the case of
graphs, it's harder, but still, YAML and LISP both provide a way to
describe such structures (LISP has #1# as a pointer to the list called
#1()). Even with sequential data, there is some kind of "typology" at work
when you need to distinguish floats from strings and allow element
separators as characters within a string and so on... So there has to be a
grammar and syntax that is agreed upon. However, standard UNIX tools never
got to any of those points.

> actually, there are several protocols. most 'clear' needs use a
> special purpose protocol. mpeg being one of them, and now the open
> source ogg/vorbis/theora/.. projects and many others.. (livido,
> yuv4mpeg, ...)

If you're talking specifically about video, then streaming using
concatenated PPMs or other uncompressed format relieves one from having to
deal with a complex format. This is how the "netpbm" suite of tools does
media processing with pretty much a clearly UNIX style in mind, although
it does so only for stills. For movies there isn't such a striking example
but I'm sure there are programs that communicate with each other using
concatenated PPMs. We have a show for which the video sequences are in
that *.ppm.cat format simply because we did it with GridFlow 0.2 which
didn't link with any codecs at all.

> the problem with this is that all of the things that exist are really not
> flexible enough. and maybe it's an academic problem for most people,

Except for academics, who probably don't care about it. ;-)

> now, this diversity is important. it is one of the key things of the
> GPL world.

Not sure; afaik, the GPL doesn't talk about diversity, FSF/GNU don't talk
about diversity, they only talk about freedom. Capitalists/Libertarians
see diversity as resulting from initiative. I don't exactly see more
initiative in the free software world at large, GPL or not, than outside
of it. I'm not even sure I see more diversity, except in areas where the
main competitor is Microsoft (because Microsoft tends to turn any
sub-market they touch into a monopoly of their own).

> but, this diversity causes a lot of problems. the most important one
> being interoperability.

Diversity might be encouraged more in any area in which there are standard
interchange formats, but that doesn't depend on the GPL at all.

> pf is meant to patch this. it is supposed to be the glue to connect
> other applications. pf is a protocol. but it is a protocol which is a
> language (in the style of postscript) connected to other things.

There are many, many so-called "glue languages".

> pf's aim is to connect things that can't be connected otherwize, but
> that have to operate in a real-time fashon: i.e. places where you
> can't rely on contemporary scripting languages because of the garbage
> collector.

One of the first (maybe the first) languages to be marketed as a "glue
language" has been TCL (1987). TCL has been tremendously popular, Pd
depends on it already, and it doesn't use a mark-sweep style of garbage
collection. Why choose Forth instead of Tcl ?

> i think the easyest thing to do is to have the grid as a basic type.
> currently i have only matrices, that come directly from libgsl.
> but i'm starting to feel the need for a more general solution.

What would be more general than a grid *and* appropriate for the problem
domains you target?

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju