On June 24, 2013 04:48:56 PM Tim E. Real wrote: > 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...
Ah yes, I think the conclusion was that SndFileR was perfect for current MusE because we can get away with sharing the same sndfile handle and re-seeking it 'live' in real-time for each instance use. Obviously this cannot work anymore for generalized stretchable shared wave parts, as you know, and would become a special use case for non-stretched wave parts but then would just be useless the moment any stretching is applied. So I think the conclusion was go ahead and remove it. Because any ref counting if needed, would have to be done by your new classes. Just be sane of course, obviously we want to avoid situations where much memory might be taken up by redundant usages. Although our discussions about sndfile memory usage seem to indicate we're OK to move ahead. Tim. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
