On March 13, 2013 09:50:33 AM Robert Jonsson wrote: > Hi Tim, > > 2013/3/11 Tim E. Real <[email protected]>: > > On March 11, 2013 11:52:29 AM Florian Jung wrote: > >> "Tim E. Real" <[email protected]> schrieb: > >> >I'm finally adding sample-accurate track controllers > >> > >> Hi Tim, > >> cool stuff. > >> How are you going to achieve sample-accurateness? I'd like to ask you to > >> keep the subticks in mind, they're kind of dormant, but some day i'll > >> find > >> the time to finish them, plus stretching :) Please tell me.a bit more > >> about > >> it > >> > >> Thanks, > >> flo > > > > I'm handling them exactly the same way as for plugins and synths as in > > > > PluginI::apply(), DssiSynthIF::getData(), and VstNativeSynthIF::getData() > > where we break up the processing period into chunks depending on > > when the various control changes happen. > > > > Looking in your branch I see you have not changed those routines - yet. > > But it raises an important issue, that not only do our tracks and parts > > > > need to respect sub-ticks, but also our audio controllers as well - they > > will need to 'stretch' along with the waves and so on. > > > > I'm not sure how sub-ticks will be incorporated here but I'll defer that > > > > to you for now. > > > > Likely the whole indexing of audio controllers will have to change from > > > > frames to sub-ticks, as well as the ControlFifo system - a scary thought > > :)> > > Virtually all my changes here are happening in AudioTrack::copyData(). > > I've given AudioTrack its own proper ControlFifo, just like plugins > > > > and synths, for sample-accurate volume and pan GUI control movements > > and so on, opening the door for OSC control of volume and pan later. > > > > There is one crucial difference between this code and the code in the > > > > plugins and synths: > > Here in AudioTrack::copyData(), it's the place where more than one > > > > node can call upon a node for its data, this is why we have the audio > > data cache system 'AudioTrack::outBuffers' to save CPU time for the > > next node that calls upon the data, so that processing is only done once > > upon the first call, and any further calls are just copying operations. > > > > So because of that, entirely because of the ControlFifo, it was a bit > > tricky,> > > I had to add a *second* audio data cache buffer which I call > > 'AudioTrack::outBuffersExtraMix', this cache holds extra pre-processed, > > pre-mixed data for the cases of routing one channel into two or two > > channels into one. It was not possible to have just one cache and > > construct the other required mixes upon further calls later, from just > > that one cache.> > > Well, still open for change there, to save CPU time I might instead cache > > > > the control values instead of the actual audio data, still playing around > > with ideas there trying to optimize CPU time as much as I can. > > > > ---- > > I found a stupid multi-channel bug which has been there for a while. > > Towards the end of AudioTrack::copyData() where we mix the data > > > > and send to the caller's buffers, we have lines like this: > > if(srcStartChan > 2 || _prefader) // Don't apply pan or volume to > > extra > > > > > > c > > > > h > > > > a > > > > n > > > > n > > > > e > > > > l > > > > s > > > > > > > > a > > > > b > > > > o > > > > v > > > > e > > > > > > > > 2 > > > > . > > > > > > > > O > > > > r > > > > > > > > i > > > > f > > > > > > > > p > > > > r > > > > e > > > > f > > > > a > > > > d > > > > e > > > > r > > > > > > > > o > > > > n > > > > . > > > > D'oh! That should have been: > > if(srcStartChan >= 2 ... > > > > I verified with Addictive Drums that yes, in fact channel 3, the kick > > drum, > > > > cannot be heard and in fact I was fully expecting MusE to crash because > > it should have been attempting to apply vol[3] where vol[] is really only > > an array of vol[2], so it should have crashed but it doesn't for some > > reason... not sure why. Possibly it is just reading the next memory > > location without triggering a segfault. > > Yeah, there are probably memory areas around it that are perfectly > writeable. Lucky it did not cause any other artefacts.
I think there is no segfault because vol[] is a local stack variable, not an allocated variable. > > About the Pan right vs wrong discussion. I saw the thread on LAD also. > It seems this is quite complicated to do "right". I have no big ideas > except not changing it too much. I think we need keep it simple enough > so users understand how to work the controls. Yeah, I hear 'ya. Don't get too complicated. However I could really use these panners because here's an example: I double-track my rhythm guitars, one take for left and one for right. Then I feed these two mono wave tracks into one stereo Group track. I adjust the pan of one wave track all the way left and the other all the way right so that the stereo Group is operating as two independent channels. Then I slap an effect into the rack such as distortion. This is the convenient part because two copies of the distortion are used and share the same controls and I don't have to play with two different copies in two different strips. But here's the problem: At this point the sound exiting the strip is two independent channels all the way to the left and right. The positions of the extreme left and right wave tracks being fed into the Group cannot be touched because then they would start to bleed into each other in the Group. So I'm stuck leaving them at full left and full right to avoid bleeding. So these panners would really help because then I could properly position the two distorted channels as I wish, before they leave the strip, instead of always being forced all the way left and right. Otherwise I'm forced to work with two independent mono strips, fooling around with two separate copies of the distortion controls. I also often double-track my lead guitar, sometimes even triple for three-part harmony. You can see how it becomes a real pain to fool around with multiple separate plugin copies on separate mono strips... An alternative to all of this is to make our strips true multi-channel, that is, be able to pick and choose which of two stereo outputs are fed into the next strip. But as you know I decided against that due to complexity, except that I allow it for multi-channel soft synths. Of course I've always kind of regretted that decision, but in fairness after all MusE is primarily about making music not studio mixing... But as talking to Fons reminded me, we could never take advantage of such LADSPA plugins as encoders and decoders because we only ever feed two channels max into them. Not to mention we have no way of connecting control outputs and inputs, like compressor outs to ins, as I know that you would so dearly like to have :) Well I've had some plans for that for a while. Start with a new Route type: "Control Route"... If I attempt this panner stuff I'll try to keep things as easy as possible for what MusE is all about... I think users could dig it once they see what it could do. Aw c'mon, admit it, don't you think replacing the pan knob with something as cool as Ardour's graphical panner would look really neat? He he... Tim. > > Regards, > Robert > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
