I think I'm getting my dates and devs confused. Werner Schweer was the original dev right? I'm sure I remember reading the first MusE release was in the late 90's but wikipedia says it dates back to 2006. I thought it was almost a decade older than that?
It was Tim's comment about thinking you should have left university by now, which made me think you're probably in your mid 20's now and if you had been responsible for the early MusE code in the late 90's (am I making that up? Maybe I'm confusing it with Rosegarden?) that would've made you some child coding prodigy! :) On Fri, Jul 29, 2016 at 4:51 PM, Florian Jung <[email protected]> wrote: > > > On 07/29/2016 03:27 PM, Dan MacDonald wrote: > > How old were you when you started writing MusE Flo, if you don't mind me > asking? > > > Hey Dan! > > uhmmm, 17 iirc. > > Why :D? > > Cheers, > flo > > > > On Fri, Jul 29, 2016 at 2:17 PM, Florian Jung <[email protected]> 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. >> >> 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 >> >> > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Lmuse-developer mailing > [email protected]https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > 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
