Am 12.04.2013 23:07, schrieb Tim E. Real: > On April 12, 2013 06:04:20 PM Florian Jung wrote: >> Hey folks, Hi Tim, Hi Robert, >> >> finally i'm back in the boat (i hope). > Steady as she goes. > >> [x] did 4 tests, passed 3, one still pending > And the doctor said...? He he. :) > >> [x] set up two servers > Ooh, I like restaurants. > >> [x] even found a couple of days (not more :( ) for having a social life > Ooh, do tell !
well, maybe you have heard of these 'friends' some people have. I was able to meet some of them ;) > >> [x] some new hardware installed (hopefully for greater >> MusE-productivity :) ) > Ooh, do tell ! a new and large monitor for my old laptop (1024x768 is a bit uncomfortable for programming) some new stuff for my tower PC (quieter fans and stuff like this) and (see above) a whole new server system :) > >> - What's the status of sample-accurate controllers? > Pending. Moving right along, if you caught my status message the other day. > Should be soon. It's been a real slog, but light at the end of the tunnel now. > >> - What's the difference between MIDI and Audio controllers? (Will they >> get merged?) > Tough one. I've been talking about this for ages. It's /always/ on my mind. > I revisited this extensively recently for my audio controllers local branch, > which I'm now two steps removed from and want to get back to. > Was not able to merge yet, very tricky global upheaval required. > It involves ALL that stuff we talked about before concerning > track controllers vs. part controllers. We have to make a decision on > which way to go, even a hybrid of the two - draw controllers both on tracks > and parts. I've thought about this /very/ extensively, I'm aware of a > lot of points and issues, how audio and midi controllers are related. > I am now leaning toward the opinion that drawing controllers directly > on tracks was a *mistake* although I supported it. I think i can agree with it being a mistake in the way we have it now: I think, we should *definitely* have per-part controllers for everything. Because if i make a tune (regardless whether its MIDI or audio) i want to set effects on that tune. Not on a whole track. For larger ambient stuff, per-track controllers are handy. But also MIDI tracks shall have them ;). Alternatively, controller-only-parts could be used. But then we'd need to think about what to do with overlapping and contradicting controller information from multiple parts. Averaging maybe? But what to do when such a part suddenly ends... Just don't take this part into account for averaging? This would lead to a jump in the effective ctrl value. I think we should have Controllers on parts, as with MIDI. when they overlap, behaviour is undefined for MIDI parts, and part-specific for audio parts (because we can pipe every audio part through his own effects pipeline.) whoa. but do we want to give every part his own effects pipeline? That would possibly be rather tedious, because for every small part you'd need to set up effects again and again... Maybe better got with "undefined behaviour" alias "first come, first serve" as with MIDI controllers? I think so. (we could however maybe let each part *extend* the effect pipeline customly. but.... no.) > The reason concerns > moving them around together with wave track parts. I feel it just cannot > be done without actually /assigning/ chosen points to a part. Fully agree. > Now before you suggest adding a 'move with part' option to the controllers > just like muse_evolution had, think carefully about it, about what happens > next after the points have been dropped. Again I feel it cannot work > satisfactory when the points and parts are completely separate. yup, this would suck. > Thus you can see where this is leading - all tracks would need to allow parts > to be drawn. not all. Synth tracks wouldn't need to. Frankly, i don't like the idea of synth tracks anyway. Synthes should be the same as MIDI output devices. And not the Synth track, but rather the MIDI track(s) which are using that synth output shall offer these controllers. And outputs, inputs, auxes don't need part controllers, for them, track-controllers are enough. > There's a lot of other stuff to mention here like the editors, > but I'll leave it at that for now. > >> - Status of sample rate conversion and stretching? >> - Live-Stretching? >> - Offline stretching? >> - Caching of audio process work? > > Nothing here to report. Just trying to keep up with my three current tasks: > 3) The sample accurate controllers (soon). > 2) Then back to my latency fixes. This is important. Things happening right > now in conjunction with the audio engine work. Hopefully soon. > 1) Then back to my audio controllers local branch. That's the one where > I posted a pic of the new all-inclusive audio/midi controller automation > dialog - no more clumsy menus and allows midi controller *graphs* to drive > audio controllers. okay. then i can try to get some stretching work in MusE. > > Also I want to try to help with the BSD-ification of MusE. > I am increasingly convinced that if we are ever to run MusE on Mac, > Windows, smart phones and all this new hardware and OS, this is a > very good goal to strive for. We need to 'genericize' MusE to the > lowest possible common denominators of all these OSs, so BSD > is probably a good start. At the very least change any Linux-only > system/library calls to BSD-compatible calls, as you requested. > I have to admit I never used to pay attention to the compatibility stuff > but now I do. good! :) (unfortunately, FreeBSD is pretty bad at audio, it basically fulfills all these "no drivers available" prejudices linux is fighting against. but still we should port it, because without usable music apps, there never will be usable drivers) > > Sadly, the Gods of computers won't let me succeed with BSD. Much time spent. > The PC-BSD installation I had on a drive strangely self-destructed. > Yep. I went to fire it up one day, and the whole thing just destroyed > itself during boot and got worse and worse the more I tried to boot. > I do not believe it is the drive but I need to test it. > So I must 're-boot' my whole BSD experience, starting over again. if you want, i could try to assist you via ssh, with freebsd (i have experience with freebsd, not with PC-bsd.). IIRC, you can get a working sshd at a very early stage of installation. do you have a whole spare computer for freebsd, or do you need dual-booting? (grub can chainload the BTX loader from bsd, but that's another thing to be configured) > >> I've seen that you did some things to my new style drum tracks. Can you >> please also quickly summarize what you changed? > > Robert allowed old-style drum maps to be loaded into new-style drum tracks, > via your track list right-click menu. Tres-cool. that's cool indeed :) fine greetings, flo > > Tim. > >> >> >> in the hope of getting stretchers working and into stable soon :) >> flo > > ------------------------------------------------------------------------------ > 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 >
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
