[Gridflow-dev] ping (fwd)

[Tom Schouten]

> > maybe i shouldn't quote esr on this (or at all) but i did read his
> > latest unix book and like the way he presents the 'policy' vs
> > 'mechanism' thing. that's what it's all about, in the end.
> 
> I think you are being quite unclear here.
>

yes.

my point is: unix is a very nice concept, because of the policy/mechanism
separation, you see this everywhere. and it's just me realizing this and
integrating it explicitly into my idea world, which is currently centered around
the abstract question 'how to properly handle real-time media in unix'.

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'.
it is a combination of pragmatics, estetics, flexibility and constraints opposed
by real-time operation.


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.

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, ...)

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,
but i encountered it as a real problem in the process of trying to do what
i want with media.

the problem is: there are so many different interfaces that do almost the
same thing, but are forked because some people make different accents.

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

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

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.

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.

until there is a free implementation of a real-time scheme interpreter,
the only thing that combines gc and pf is supercollider. and i don't
know if the gc can be kut out just like that. maybe that would be a better
approach, but now i go for forth because it has just enough flexibility
to do reach the same goals without a gc.


so, if there is a media interface that does what you want: use it.
if there isn't any, use pf as a workaround hack for this.

by providing a type system, memory management and serialization mechanism,
and doing this in a way that is trivially extensible, the problem of
meta data can be solved.

there is no way something like this will ever be designed by committee.
that only works for clearly delimited applications.

note that actually pd already solves a lot of these problems. yves showed
me some things he is working on where pd actually is the system, and it seems 
he's getting quite far with this.

i'm moving my solution (former pdp) to the level of unix, instead
of limiting it to pd. of course, in a way that would present all the
functionality in pf to pd/pdp/pidip. (trading pf policy for pd/pdp/pdip
policy, but keeping the mechanism).

i hope this sort of explains what i'm trying to do.


> > * first map the data types in one go
> 
> ok, so let's write [#import_pdp] and [#export_pdp]. What packet-types
> ought to be supported by those two object-classes? I mean a GridFlow Grid
> should map to how many PDP packet-types, and which ones?
> 

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.

i really do need to start reading gridflow code before i can say something
intelligent about it, but if you got some more remarks, please shoot.


cheers
tom