[Top][All Lists]
[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