On Friday, July 29, 2016 3:17:08 PM EDT Florian Jung wrote: > On 29.07.2016 07:33, termtech wrote: > > Hey Florian how's it going? Nice to hear from you. > > Must be out of school by now working for a nice company? > > Hi :D > > yea, great to see that there's still some progress on MusE :] > Nope, i'm still at university, working on my master's degree. > I haven't found any *nice* company yet, so i thought i'd rather stay at > university :D > > But I've got a job there, and it's quite fun :D > > >> 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. > > Great to hear that :) > Yea, problem with shared eventlists is: You DO want to share the > information, but you definitely do not want to share any temporary state > information that's used during playback. By having also the state > shared, you force MusE to only process one clone at a time. > > > The master ' sndfile' list is actually useless now, and will be > > > > removed or re-purposed as I wrote in the ChangeLog. > > nice! :) > > > *** > > 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: > (fun fact: you could have added your old machine as a remote, and pull > from there. that's the nice thing about git, you do not have to use that > "central repo" at all) > > > 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. > > *blush* :) > > > 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. > > whoa, hell yea! gotta try this out! > You know, i was working on this for weeks or even months, but didn't get > it working really nicely (after having resolved the event list issue, i > still wasn't able to stretch things precisely, they always got off-beat > by some fractions of a 8th :/) > > > * 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). > > niiiiiiiiiiice! especially that "offline" mode is important (or, > actually, was), because my sloooow laptop only managed to stretch one or > two waves at a time, cpu-wise :D > > > At this moment I'm reworking the StretchList class. > > Please bear with me, try it in a few days. > > yea, be sure to drop me a mail when things are suitable for alpha-testing :D > gotta get QT5 running beforehand anyway :D > > > btw, do you see a possibility to add this "offline" mode to > ladspa/lv2/vst effects, too? that was on my "dreams"-list, but i never > managed to get it working.
Ah yes, I do remember you wanted to include the effects in any offline wave rendering mode. I had not considered that for my offline rendering mode. I will look to see if I can do it. I guess I was deferring to the overall 'bounce' feature to take care of that. But making it available for /each/ wave render command would be helpful, yes. T. > > Cheers! > flo > > > 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 ------------------------------------------------------------------------------ _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
