Hello again, 2013/4/6 Tim E. Real <[email protected]>: > Hey gang, still here. > Slow going here on the audio engine mods but coming along > and some side benefits done like Duplicate Tracks now > copies synth tracks, and copies plugins, and copies controllers > more carefully, and the fixes I mentioned on LAD.
Hope merging to the new svn won't be to troublesome. > Relax, I told RJ I'm not changing the strips at all. Instead > specialized panning and such should be done with plugins > (I might just have to make one). > So your mixes will still sound the same - for now. > > What I do have so far, is sample accurate track controllers (vol, pan) > *and* slew rate limiting on them. > (IIRC around 0.02dB per sample, or around 200 samples for > full vol swing from off to +10dB). > I'll try to put a user on/off switch and volume rate setting. > > So the volume and pan graphs are virtually noiseless. > The actual GUI controls are also quiet now, but still a tad noisy 'cause > it's purely the limiter that kicks in when GUI controls change and our > GUI faders go in 1dB *steps* or higher. > > For all sample accurate controllers, I'm fixing a bottleneck that > Florian pointed out months ago about querying the controllers > once every min-period. Instead I'm using local interpolation > structures so the controllers are queried only whenever the > structures need to change - best-case only once per period now, > another speed boost by splitting up the controller class into > "asking of interpolate points" and a fast "do interpolate". > Another speed boost by using an iterator to step through controllers. > Aiming for efficiency here. Gonna need it since I had to trade-off > some speed for some of these new audio engine features :) > > It occurred to me that I must add this slew rate limiting to the > actual Mute and Solo and Off and Pre buttons - anything > that might abruptly change the volume or source material. > In effect, each of these buttons must become like a smooth > controller instead of a hard-coded switch. Big task, nice, maybe later. > > Anyway I'm trying to open the door to some kind of smooth > fader/cross-fader graphs (separate from the volume graphs). > I note that there is an unused audio controller (that no user > knows about) which is called the 'Mute' controller. > Oddly enough no one has ever bothered to link the actual strip > mute buttons to this Mute controller. > oh wierd. > It occurred to me that we could almost use this Mute controller > for fading - technically that's what fade does, muting on/off. > But being a binary on/off controller, it would need to respect > some sort of slew rate limiting and the true graph would have > to be drawn. And how to support user-variable slopes. > So possibly the solution is yet another controller - a smooth one - > for the fades. With pre-set initial slopes (how?), alterable after > that just like any other controller. > > But then there's cross-fading. Which could essentially be > implemented as 'linked' controllers with modes like > 'mirror', 'invert' and so on. > Oddly enough I'm pondering linked/unlinked controllers for > our multiple-instance rack plugins, and I mentioned linked > controllers to someone in the forum. > And I pondered linked controllers for an alternate form of > panning instead of a knob. Hmm... yep very useful. > > Dunno, still thinking on these faders and controllers. Lots of meat in there, not with you on all of it but sounds cool! > ----- > > Yeesh, me talk way too much, just wanted to say... > > Robert you're on a roll. Super work man. > The SimpleDrums thing is so cool. > > I have a suggestion. > I think it would be simple to replace the off-line resampler code with > RubberBand's off-line functions or something else instead of just SRC. > What was that nice one Flo mentioned? Ah, indeed. stretching would improve it a great deal. I took a look at an example I found in the rubberband sources but it looked awfully convoluted. Is there an offline version of the api? Need a clearer head before trying to adapt that code.. though maybe there are other examples that are easier to adapt. > > This way you could add one more switch to the SD strips, named: > 'Keep length'. So pitch would not affect length. > Or have separate 'Pitch' and 'Length' controls - easy, interesting results. Absolutely. > > By carefully setting their pitch and length controls I think these shifters > can also replace SRC to do the resampling job on non-MusE sample rate files. Yes, as long as the resampling is 'good enough' it should not matter if we are stretching or changing sample rate. > For now I would look at maybe using a dialog or something instead of knobs. > It can take a a while for a large sample to be processed off-line. That may be, though I think rubberband is quite fast. > Wow, we're treading right into territory Florian and I were covering. > We could even do the shifting realtime not off-line if we get our > infrastructure right. All this stuff all kinda blends together. Yeah, the thought struck me but that would require more extensive rewrites but that would be best! > > Anyway thanks. Don'cha just love when ideas materialize into product? > One can stare at a problem for months before a grand solution appears and the > energy and path to actually see it through suddenly magically happens, as if > it could never happen before and might not happen after this moment... > Coding Karma... Indeed :) > Tim. > Regards, Robert ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
