From: Tim E. R. <ter...@ro...> - 2012-03-26 07:33:07
|
On March 26, 2012 12:40:36 AM Florian Jung wrote: > "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". OK. I still don't follow, but I remember the emails but it went over my head. > > >> 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; Freewheel mode means Jack (even our dummy driver could) calls your process as quickly as it can as soon as the previous process has returned, WITHOUT waiting for the next timing period. It's a cool thing. That's how it's able to whip through the song so quickly. Similar to how one processes a file, not in real-time, applying effects for example. One just whips through it without regard to synchronized timing 'periods'. So the bug is that this mode remains on if bounce stopped prematurely. Know what I mean? > 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) I would say not yet. Large sysex support for example? Jack uses back-ends like ALSA. That doesn't make them obsolete. Saying ALSA is obsolete is like saying Jack makes FFADO and all the other back-ends obsolete. > > what about doing this.in muse 2.1? Getting to that slowly. Talked about that a bit recently with Robert in the list. Separation of Jack and ALSA is a fairly higher priority for me because of all the work I've been doing in the engines and such. I found there are advantages to using ALSA midi with a fast timer when using a large Jack audio buffer. Don't discount it completely. Anyway, separation will happen... > > >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? What, that one? No not really. Unless some poor soul gets messed up by it :) Tim. > > greetings > flo > > >> greetings > >> flo > > |