Re: [Traverso-devel] AudioClip/Source manager

[Remon Sijrier]

Hi Nicola,

I've searched through the mail archive, please have a read here:

http://lists.gnu.org/archive/html/traverso-devel/2006-08/msg00043.html
http://lists.gnu.org/archive/html/traverso-devel/2006-08/msg00047.html
http://lists.gnu.org/archive/html/traverso-devel/2006-09/msg00002.html

Jonatan also had some ideas on marking songs for CD creation, but it seems I 
forgot to post it on the list, will forward that in another mail.

As it is now, AudioSources 'live' and are managed at Project level.
The idea is to create a View with all the AudioSources available in the 
Project like a tree view where all the AudioClips using an AudioSources are 
listed as childs of the AudioSource.
For this, it made sense to have only one entitiy for a ReadSource wether it 
consisted of 1 or 2 physical files.

To make the View possible, and to be able to use AudioClips just like 
AudioSources, the Clips should 'live' at Project level as well.

Current CVS has those changes. (or almost, still working on it)

The whole reference thing works for AudioSources in the same way as for 
AudioClips.
Since for both instances are made when the Project loads, there needs to be a 
way to tell if an AudioClip or AudioSource is in use or not.

The only difference with AudioClips is like you say it's "non sharing' 
behaviour.
When an AudioClip is referenced twice (like dragging it 2 times from the view 
into a Track), it will create a new instance at Project level.
There is no "AudioClip copy and only making a real new one when internal data 
has been modified" because making a copy _allready_ modifies the internal 
data (Track start position for example is almost _always_ different)
So as for memory saving, this won't work for AudioClips and doesn't matter 
actually. (AudioClips are ~ 120 bytes)

I hope I made clear how the situation is now.

If there is need for 'shared' AudioClips, please let me know what parameters 
should be shared, the use cases and so on and so on :-)
Oh, and how it should be implemented, patches are welcome heh

The nice thing with managing AudioClips at project  level is the ability to 
easily use a Clip in another Song! (Same for AudioSources)

Looking forward to your comments!

Remon



Op donderdag 14 september 2006 08:58, schreef Nicola Döbelin:
> Hi,
>
> Since I missed the previous discussion about the clip manager, I have
> difficulties to understand some of the features listed below. If the
> answers to my questions can be found in the mailing list archive, feel free
> to tell me rather than explaining it all over again (even an 'RTFA' will do
> ;-).
>
> > I think this is a good model: (from another mail)
> >
> > * dragging a clip from the clipmgr into a track creates a reference to
> > it there (not a copy).
>
> As I understand it, a clip is already a reference to an audio source,
> right? So it doesn't actually contain audio data, just information about
> start, end, fades, plugins etc. Having a reference rather than a copy of
> such a clip will save only minor amounts of memory.
>
> > * modifying a clip with multiple references creates a copy before the
> > modification, so that a new clip is created. (the new clip will have
> > references=1)
>
> This is what I don't understand: Why would you transform a reference into a
> copy when it is modified? The behaviour I would expect intuitively is the
> following:
>
> When duplicating a clip, I can choose between copying or linking (just like
> in konqueror when moving/copying/linking files). If I choose 'copy', the
> new clip will be independent, if I choose 'link' the new clip will be a
> reference to the source clip. *But* if I modify a reference or a clip
> having references > 1, all linked clips should be modified accordingly.
> Unless the users explicitly detaches a reference from the source clip to
> transform it into an independent copy, each reference (and the source clip)
> should adopt all changes applied to any member of the 'clip family'.
>
> I reckon that the point in having references is that people working with
> loops/samples have numerous copies of the same clip, right?
>
> Cheers,
> Nic