[gst-devel] Re: Bonobo

[Erik Walthinsen]

On Wed, 22 Mar 2000, Nicholas Francis wrote:

> No, that is the other Trinity project :(
> the main site is at http://members.xoom.com/NicholasF/
OK.  I would suggest that you add a Freshmeat listing though, since it's
not listed there (and that's most people's way of searching for programs
these days, RIP sunsite [kinda])

> No, his name is Joakim Ziegler. He is currently heading the development of
> the new GNOME site. He is a Norwegian that works for a mexican company,
> called Simplemente (http://www.simplemente.net).
OK, I've heard of him.

> In GTK+ version 1.4, GtkObject will be renamed to GObject and moved to glib,
> so you might want to reconsider that :)
Right, that's what I mean.  I need to go back in my mail archives and find
Tim Janik's post about the basic architecture of it, then go poking around
in source.  I'll wait for 1.4 to come out before moving over, just because
I don't want to put a moving target on top of a moving target... <g>

> This would be a nice way to do it - however, does it scale ? Just because
> something is running over a Bonobo component, doesn't mean it doesn't want
> to access things at a lower level...
True.  I guess it wouldn't be that hard to have a few Bonobo wrappers for
the core data types (corresponding to all the files in gst/, the idea is
that the plugins use standard interfaces provided by these core types, for
maximum plugability) and expose those via IDL.  I need to read up on
Bonobo some more, and figure out where on earth my CORBA book went...

> One example is a distributed rendering environment - here, many machines
> could be involved, with different elements being executed on different
> machines...
Right.  This meshes with the stuff we're doing at work, though we're doing
a client/server video streaming demo.

> I've just done some brainstorming, and have quite a few notes on the
> subject, unfortunately, I can't type them in as I attempted a real-life
> pipeline:    Glass -> Coke -> Keyboard -> Panic -> Laptop disassembly ->
> cleaning -> drying.... So my linux machine is down for the night :(
Ouch.  That sucks.

> Anyways, I think we should try to see what actual uses a system like this
> could be exposed to. At the Trinity website, I have a section called
> 'Architecture documentation', that you could read through. Anyways, a
> docbook will find its way on the web tomorrow :)
OK, I'll go over it in more detail.  I did see lots of references to
GStreamer, and even a verbatim copy of the docs ;-)  Cool!

BTW, just so you know what I'm up to on the sidelines, I'm interested in
an audio editting program, a la Cakewalk or VST Cubase, as well as a form
of that with a twist: live.  I've found that every audio package claims
real-time, but not live.  There are no packages that turn a multi-channel
sound card into a live mixer.  I'd like to come up with a library and
application (that sits on top of GStreamer, of course) that provides the
necessary functionality to do this.  The library idealy would be designed
generally enough to do any kind of media editting functionality.  This
means that a lot of code you have in Trinity could be very similar to
what's needed for audio processing, at least in the offline NLE-style
editting app.  Something to keep in mind...

         Erik Walthinsen <omega at cse.ogi.edu> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user