traverso-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: Re: [Traverso-devel] AudioClip/Source manager


From: Remon Sijrier
Subject: Re: Fwd: Re: [Traverso-devel] AudioClip/Source manager
Date: Tue, 19 Sep 2006 00:45:57 +0200
User-agent: KMail/1.9.4

Hi,

> Since the economy of memory consumption is only minor when using the above

About 100 bytes hehe :)

> discussed concept, it would probably be much easier to allow to define
> groups of regular clips. If one clip of the group is modified, the other
> group members should adopt the relative changes accordingly.

When we talk about Clip linking, then from an implementation point of view, it 
appears to me like implicit sharing of certain parameters, right?

The big question is, what parameters one should share.

Putting all shared parameters into a class, and making an instance of that 
class makes it possible to share data between clips.
All clips will have the same reference to certain data, the data created in 
the "root" clip so to speak.

Like this:

class SharedData
{
        float gain;
        Curve* fadeIn
};

In the AudioClip constructor, we make an instance of this class:

AudioClip::AudioClip()
{
        shared = new SharedData();
}

And now we can access it by 
        shared->gain;

When a clip is 'linked', on creation we do something like this:

AudioClip::AudioClip(AudioClip* clip)
{
        shared = clip->get_shared_data();
}


Anyway, these are implementation details :)

The question is, when should a Clip "disconnect" the shared data part, and 
become it's own entity.


The thing I need to be sure of is the defenition of the concept, if it is 
valuable to implement and so on.
What about 'selected' Clips, selected clips live in a 'selection group'.
Should 'linked' clip have common selection?
This will be the case if the isSelected property is shared.

It's not particularly difficult to implement ( I think), it's harder to get 
the 'what should' and 'what should not' right :-)


> I suppose this will be much easier to implement and more transparent to
> understand. When I came up with the source/link concept, I thought it would
> be a bit more memory efficient, but if the gain in efficiency is not
> significant, I don't think it is worth the effort. Or are there other
> benefits I've been missing so far?

No idea :-)

>
> Regards,
> Nic

Thanks for the input.

I've lost track of what I was doing actually, was there something we were 
workign on actually?

Greetings,

Remon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]