[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: More MSOP stuff: dynamic casting and aliasing
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-05-16 17:29:23
[Download RAW message or body]

   Hi!

On Tue, May 16, 2000 at 02:35:38PM +0100, Nicolas Brodu wrote:
> Stefan Westerfeld wrote:
> > > Object o;
> > > alias(o,"a_port",another_object,"another_port");
> > >
> > > In that case, since o doesn't exist, you cannot call _alias^H^H^H^H^H^H
> > > _virtualize on it. So I created a foo AliasedObject to serve as a support.
> > > How did you solve this one?
> > 
> > Not at all ;-)
> > 
> > But basically, a "dynamic skeleton object" should even be able to create
> > a port for itself, and use it to transfer real data (without virtualization),
> > as it should be able to implement methods, and attributes.
> > 
> > A good example for this is LADSPA support (another simple plugin interface
> > for linux), which we could have some day have in aRts/MCOP. It should work
> > like this:
> > 
> > You say
> > 
> > SynthModule m("Foo");
> > 
> > If Foo is a LADSPA plugin (which provides some entry points for processing
> > float data), it should be dlopened, and a LADSPAGate object should be created
> > that adds to itself (and to the flowsystem) the required ports. It then
> > reimplements calculateBlock, where it calls the "real" LADSPA calculation
> > function.
> > 
> > So basically, dynamically implemented modules should be capable of
> > implementing interfaces with any kinds of ports, methods and attributes
> > without the author knowing the exact types and count before.
> 
> OK, so what's really missing there is the dynamic skeleton system.
> I think I'll make a virtualize() and devirtualize() functions like the connect
> one (that is, a global function that takes Objects and port names as arguments
> and does the necessary job). That should solve the 'ugly syntax' problem, and
> after another look at the source code, the virtualize system is great.
> However, since we don't have dynamic skeletons now, I propose the following. If
> virtualize() is called on a null object, create locally an empty object
> (inherited from SynthModule) and then use it for the virtualizing operation.
> Would it work, then?

No, because an empty object doesn't have ports, so you can't virtualize any
(the virtualize call can only act on already existing ports). What is missing
is indeed the dynamic skeleton interface, which needs to be done before these
things will fully work.

Also, catching (and redirecting) accesses to a null object don't really make
sense. It is a null object after all. What may be better is having

interface Group { [...] };

and then saying

Group g;
g.loadPlanFromFile("foo");

  or

g.addVirtualInputPort("in",implementingObject,"inleft");

Of course, with some dynamic magic, it would be even possible to do something
like

StereoEffect sfx = DynamicCast(g.masqueradeAs("StereoEffect"));

or similar. I'll work more on these issues when working on artsbuilder in the
next time. And yes: Group should be an IDL object, so it is accessible from
scripting languages, remotely and similar. We should avoid plain C++ as much
as possible.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]