>> I have a suggestion. >> I think it would be simple to replace the off-line resampler code with >> RubberBand's off-line functions or something else instead of just SRC. >> What was that nice one Flo mentioned? > > Ah, indeed. stretching would improve it a great deal. I took a look at > an example I found in the rubberband sources but it looked awfully > convoluted. Is there an offline version of the api? > Need a clearer head before trying to adapt that code.. though maybe > there are other examples that are easier to adapt.
i *might* be able to help you with these stretchers, i touched all of them some months ago. i'm not fully sure, but i think rubberband offers an offline mode. setKeyFrameMap is the point to poke. >> By carefully setting their pitch and length controls I think these shifters >> can also replace SRC to do the resampling job on non-MusE sample rate files. > > Yes, as long as the resampling is 'good enough' it should not matter > if we are stretching or changing sample rate. i think, we should consider doing resampling and time-stretching in the same step anyway. I'd like to have pitch-shifting as well in MusE, and pitch-shifting is nothing else than time-stretching and then resample. > >> For now I would look at maybe using a dialog or something instead of knobs. >> It can take a a while for a large sample to be processed off-line. > > That may be, though I think rubberband is quite fast. > >> Wow, we're treading right into territory Florian and I were covering. >> We could even do the shifting realtime not off-line if we get our >> infrastructure right. All this stuff all kinda blends together. no dialogs please. I'd like to have all this audio stretching stuff hidden from the user; in my imagination, MusE shows a small, unobtrusive progress bar at the bottom of the window, which indicates stretching progress and an ETA. maybe this bar is also joined with the time scale, so the user can see up to which measure offline-stretching has been completed already. I definitely want that MusE does not need to restretch everything before being able to play. It shall be fine, if MusE's stretchers are one measure ahead of the play cursor or so. > Yeah, the thought struck me but that would require more extensive > rewrites but that would be best! yea. How would you do all this sampling rate/stretching stuff, in regard to the problem with multiple wave clone parts at different tempo settings we discussed some months ago? Any ideas already? This might be related to your mail with Subject "Fixed audio stuttering loud repeated segments upon seek". There you point out that the OGG/FLAC decoders break if two parts using the same soundfile are overlapping. Is that already fixed? This could be fixed similarly, by just having one decoder/stretcher/samplingrate-converter per part, and not one per sound file. >> Anyway thanks. Don'cha just love when ideas materialize into product? >> One can stare at a problem for months before a grand solution appears and the >> energy and path to actually see it through suddenly magically happens, as if >> it could never happen before and might not happen after this moment... >> Coding Karma... > > Indeed :) > yay :) greetings flo
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
