Re: [Lmuse-developer] Use case for the cliplist and removal of SndFileR

[Tim E. R. <ter...@ro...>]

On June 24, 2013 10:05:12 PM Florian Jung wrote:
> Hi
> 
> can you please explain me what the cliplist is for? Does it only provide
> a list of wave files and some information, 

Correct.

> or is there also some
> functionality?

Nope. 
Curious as to what it did, I rescued the ClipList several years ago from 
 'disabled' obscurity. I thought it would be good to have it around just to 
 have a list of currently used files and some info (samplerate, length etc).
Not sure where the author was going with it, it did not appear to have 
 any other use beyond that.
If you look further into the code you'll see that 'Clips' were once a part
 of MusE, or were possibly trying to make an appearance.
I think Clips were replaced by our SndFile(R) classes though.
I've had ideas about how to embellish the ClipList to do more, but it 
 turns out it wasn't very useful because (I think) it only lists the sound 
 files directly from the sound file list, and not from the instances themselves.
For example I had hoped that we could do something like highlight 
 a listed file and click on a hypothetical 'resample' or 'shift' 
 (live processing not file ops) or something. But it could not do that
 per instance use. Still, we could use it a handy one-stop place for 
 complete file ops if necessary.

> Furthermore, i'd like to remove SndFileR in the audiostreams branch. I
> think SndFileR shall better be replaced by sane manual management, or by
> a templated implementation of a smart (refcounting) pointer.
> 
> It's only used for recFiles and tmpFiles anyway; the rest is handled by
> AudioStream now.
> 
> Does SndFileR do anything more than refcounting? Please give me some
> insights :)

Oh, I thought you were already in the process of removing it, as discussed.
I thought it was not compatible with your branch and that your classes
 would handle ref counting, if needed.

After the last discussion (libsndfile handles, mem usage etc) I tried to see 
 exactly why we had SndFileR and if it was really necessary but I couldn't 
 really come up with a reason.
But I still fear I may have missed something. Something nagging me there...

Tim.

> 
> Greetings,
> flo
>