On Friday, July 29, 2016 4:39:46 AM EDT Florian Jung wrote: > On 29.07.2016 02:52, Tim E. Real wrote: > > Old PC: AMD Athlon ~2GHz single core, 1.3 GB RAM, SATA-1 MB > > > > Full MusE compile time: About 40 Minutes. > > > > New PC: Intel i5, ~3.5GHz, 8GB RAM, 120GB SSD drive, SATA-3 (I think) > > > > Full MusE compile time: Exactly 4 Minutes. > > > > Which is /exactly/ what I told my dealer I had hoped for - 4 minutes ! > > > > Wheeee ! > > > > Cheers. > > Tim. > > > > -------------------------------------------------------------------------- > > ---- _______________________________________________ > > Lmuse-developer mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > Hi Tim!
Hey Florian how's it going? Nice to hear from you. Must be out of school by now working for a nice company? > you know what kind of machine I used to develop MusE on :D? > A Thinkpad X31, featuring a 1.4GHz Pentium M, with P-ATA HDD (but more > RAM than yours :D) > It took hours, literally, hours :D > > And then you change that tiny header file and BAAAM, you need to > basically recompile EVERYTHING :D > > Cheers from Germany! > flo Yeah, that's exactly why I went to my dealer. I joked I was literally growing cobwebs (a spider once tried to 'thread' me) and my hair turning grey waiting for things to happen - not just with compiling, but the whole system. Want to patch something up: The choice between shared and non-shared event lists was gut-wrenching for me. Day after day I tried to decide which was the way, running scenarios in my mind trying to look forward. Each had merits. I was stuck. So when I took a break and came back and saw that non-shared was added, I guess I kinda lost it in a rant at you, not having worked it out yet in my mind which way forward. Still, it was an amazing amount of work. I actually struggled afterwards for a week thinking if I should revert it all and try shared lists, or move forward with non-shared. Well, I moved forward with it. I moved in what I think was the direction you were headed in, and completed/embellished/reworked the code. The result is that now compressed wave file parts can overlap without MusE choking, each wave event has its own sndfile handle now. The master ' sndfile' list is actually useless now, and will be removed or re-purposed as I wrote in the ChangeLog. *** But I say these words because of something brand new, and it is ironic that you piped up here today because I was forced to commit this new branch for the first time today, so that I may pull it into the new PC. You may find this interesting: Here is what /my/ vision for MusE audio looked like, so many months ago when I wrote that sloppy experimental AudioConverter class code. And then I got waaay side-tracked because, lo and behold I realized oh-no we were using shared event lists... And now we are not. Thanks to /you/ Florian. I finished my work. And more. See the new branch "audio_convert": Features: * Sample rate conversion: Automatic project-wide 'live' sample rate conversion of both audio and graphical data, including both wave and data automation. MusE does not 'care' what sample rate the audio system is running vs. project sample rate vs. wave file sample rate. It tries to faithfully present and play the project the same way every time. This 'live' conversion is non-destructive: You can save the project at one sample rate, then open it at another and save it. (Although, it warns you that slight rounding errors may creep in.) * Stretch, pitch, and sample rate controls: All Wave Events can be stretched, re-sampled, and pitch-shifted. The stretching and re-sampling is done with movable 'markers'. The pitch is adjusted with a normal controller-style graph. All three also allow direct value entry. * Choice of re-samplers and stretchers/shifters: Choose technology (SRC, Zita Resampler, Rubberband, SoundTouch etc) - on all Wave Events with global default customizeable settings. Local settings can override the default settings, including converter type, for /each/ Wave Event. Full unique settings and options for each type. Separately adjustable settings for three different 'modes': Offline, Realtime, and GUI (choose which converter draws the wave). * Render mode: Once you are satisfied with 'Realtime' conversion settings, a wave can be permanently rendered, using the 'Offline' mode settings. Or, when the the project is finally 'bounced' to a track, it will also use the 'Offline' mode settings. * Modular audio conversion API: Each supported converter type is a self-contained shared library (dl), just like plugins. Although, currently they depend on some MusE code. They are 'discovered' at startup. Each library contains the converter code, the unique settings code, and graphical dialog to adjust its unique settings. An API master dialog selects the type, and opens each found available converter's unique settings dialog, for Wave Events and the global defaults, and for all three 'modes' (Offline, Realtime, and GUI). At this moment I'm reworking the StretchList class. Please bear with me, try it in a few days. Yes, it works. Just borked ATM. And a HUGE commented mess. It was only yesterday that (I hope) I worked out an 'end-game' regarding movable stretch/samplerate markers. So with that, I am somewhat confident that I can move it forward and thus make this announcement. I hope it all works out. Lots TBD, including tempo... Thanks. Tim. ------------------------------------------------------------------------------ _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
