From: David B. <da...@id...> - 2000-03-24 03:26:00
|
Hello, I am coauthor of GDAM, a sound editing program. When writing gdam, we cycled through many frameworks, one using threads (pthreads) and two client/server architectures. The way it is now, that we are quite pleased with, is a client/server all in C, written with just the facilities gtk/glib provide. (er except libglade and libxml now...) We looked at/tried briefly gstreamer, but I was unable to make a satifactory mixer in it. [basically the sources weren't able to block for input, which i needed]. Perhaps gmf suffices, perhaps not, I found it rather confusing, at the time it was pretty minimal and I certainly didn't want to be the guinea pig there... In any event, I wrote my own, and that was fun. And I believe no library of this depth could completely satisfy everyone ... what are really needed, are a clear CORBA interface that everyone can comply to / use. The rest is a bunch of details no one will agree on. I think I'll get back out of this now :) Thanks for listening, Dave On Thu, 23 Mar 2000, Erik Walthinsen wrote: > On Fri, 24 Mar 2000, Nicholas Francis wrote: > > > I very much like GStreamer. My only concern is that it appears to have been > > designed to be a system that is cool, which is not neccessarily the same as > > that it is cool to use it... > No, it was designed to solve the problems I saw with an existing project, > the OGI pipeline. It happens to be a cool design (IMO), and from the > application-writer's perspective I believe it's quite a sane API. Also > consider that it's a low-level API, having to do with the filter graphs > themselves, not the higher-level concepts I would expect GML to have. |