From: Florian J. <flo...@we...> - 2012-03-25 22:38:33
|
"Tim E. Real" <ter...@ro...> schrieb: >On March 25, 2012 11:13:32 PM Florian Jung wrote: >> Am 25.03.2012 22:44, schrieb Robert Jonsson: >> > Hi Tim, >> > >> > Den 25 mars 2012 20:24 skrev Tim E. Real<ter...@ro...>: >> >> On March 25, 2012 12:49:41 PM Florian Jung wrote: >> >>> Am 22.03.2012 18:23, schrieb Tim E. Real: >> >>>> On March 22, 2012 3:15:26 PM Florian Jung wrote: >> >>>>> you definitely want my "layered" tracks feature then. it would >> >>>>> allow >> >>>>> you >> >>>>> to record clean waves (or use the "clean" output of any >software >> >>>>> synth), >> >>>>> and pipe it through various effects. if you don't change the >> >>>>> effects, >> >>>>> muse automatically uses a recorded version of the clean wave >> >>>>> piped >> >>>>> through all your effects, not wasting cpu cycles. but if you >> >>>>> change >> >>>>> some >> >>>>> plugin there, muse transparently re-applies the effect, giving >> >>>>> you the up-to-date output. think of it as cache ;) >> >>>>> await it in muse 2.1 or 2.2 ;) >> >>>> >> >>>> Sounds neat. Good to save cycles. >> >>>> Sort of similar to our bounce feature. >> >>> >> >>> or even a replacement for bounce. i can't think of any situation >> >>> where >> >>> one would want to bounce if muse can do it internally anyway; and >> >>> even >> >>> if we want to keep "bouncing", we could drastically simplify it, >by >> >>> just taking the "prerecorded"/cached wave. >> >> >> >> Bounce is intended to take exactly 'what you hear' at the output >> >> >> >> and dump it down to a final file or track with conversions if >> >> necessary.>> >> >> It is a very handy one-step to create a final 16-bit CD-ready >track. >> > >> > Yes and that is definitely a good function. There is however the >> > bounce-to-track feature which I believe is the one Florian means, >with >> > his intended freeze functionality bounce-to-track would not be >needed >> > and quite improved. >> >> yup, i meant that. >> still, that "bounce everything to a single track" would only require >> mixing the already existing cached waves together, not requiring to >play >> it back actually (not even internally); > >But... this is not enough. All plugin effects must be applied and >automation > of their controls applied as time progresses. >So we can't just statically mix waves together. The whole thing has to >be done >as if it is playing, chunk by chunk, whether in high speed 'freewheel >mode' > or not. > >The audio caches only hold a small portion of the wave during play, >acting as a 'lookahead' buffer so that it's not hit with a lot of file >reads > at once. not the "cache" i'm talking about. i mean the caches used by that "prerecord stuff" feature (which would allow yoi to use many cpu intensive effects you cannot do in realtime *without* the hassle of having to use multiple wave tracks, and to re-bounce, mute, etc stuff manually when necessary. see my old emails titled "audio workflow for muse" and some more recent, cant recall theor subject right now) these "caches" actually hold wave information for whole tracks, if you want even "layered" that is: you have (transparently!) your original wave, the wave with effect1 on it, and rhe wave with eff1 and eff2 on it. usually muse plays back the last wave (1+2), causing no cpu usage and you have both effects. if you want to change effect2, muse automatically applies the new effect2 on the "wave+eff1(but not +eff2)" wave (and overwrites the 1+2 wave), without the need for doing the effect1 calculations as well. i meant these "caches". > >> but only if the user decides to >> use caching everywhere... this should be possible, but not default or >> so. needs more thinking ;) >> >> >> I don't know if we can so easily do that internally in a way that >is >> >> different>> >> >> from how we do it now. >> >> >> >> Did you know that bounce can make use of Jack's freewheel mode >> >> >> >> to dramatically speed up the operation? >> > >> > I've been meaning to get back to this, as some might recall I made >a >> > bug about freewheeling which someone else (florian?) could not >> > reproduce. > >There is a bug I know of: In freewheel mode if you stop the bounce > before it is done MusE is left in a messed up state forcing a restart. >In this condition MusE thinks that it is still in freewheel mode after >stop, > so any further playback is messed up - too fast. how could that be? jack clients should not care whether they are freewheeling or not. they just give data in their process() calls whenevrr jack is calling them; they depend on jack's clock, not on any real clock. btw, it seems to.me that muse is "an alsa application which also supports jack". how about turning it in "a jack application which also.supports alsa"? this also removes the need for high-freq-timers if only using jack. then we can simply let jack do the timing work (the user needs either a fast timer or a high latency anyway, but that's jack's job then. it was made for that.) also it would greatly simplify porting to bsd, windows etc. muse would basically on any system.which can run jack and gcc then (without alsa support of.course, but actually alsa support is obsolete due to jack) what about doing this.in muse 2.1? >Tried to fix once, had only partial luck. >IIRC it involves turning off freewheel mode at the right time, > which I found was tricky. > >> >> yep, it was me who could not reproduce it. >> >> > I think there needs to be a plugin involved, maybe a vst, as that >was >> > what I had when I got it to misbehave. Then the output gets all >> > scrambled. We should fix it but since there is a workaround I think >> > it's post 2.0 > >So far my tests showed synths and plugins were OK, don't recall seeing > any trouble there. Possibly could be wrong about VST though... > >Tim. > >> >> yep, agreed. so not a release-critical bug. tim, do.you agree that it isnt releasecritical? greetings flo >> >> greetings >> flo >> > > >------------------------------------------------------------------------------ >This SF email is sponsosred by: >Try Windows Azure free for 90 days Click Here >http://p.sf.net/sfu/sfd2d-msazure >_______________________________________________ >Lmuse-developer mailing list >Lmu...@li... >https://lists.sourceforge.net/lists/listinfo/lmuse-developer |