On 05/24/2014 09:36 PM, Tres Finocchiaro wrote: > > I had misspoken when I called the automation track a controller, sorry. > > Yes, limiting the tempo changes to only one automation track is what > I was attempting to describe and I understand after your explanation > why that may not be as easy as suggested. >
Well, limiting tempo changes to only one automation track... would basically be the same thing as having a dedicated tempo track. What extra advantage is there that you're able to add other automations on that same track? That you can have one less track in the project? I don't think that benefit justifies the added complexity and error surface. Remember the KISS principle... and as corollary, Murphy's law. The simpler we keep things, the less potential there is for things to go horribly wrong... > Conceptually, its still difficult because automation events are often > a line in the sand that must be crossed to have an effect, so weird > things will happen when the event is missed (as does now if an event > is missed), but the act of "looking ahead at automation" is quite > confusing when combined with elements that don't naturally look ahead, > i.e. sample tracks playing at the right tempo while the rest of the > track plays at the wrong tempo. > > This really does open up Pandora's box so to speak. > Actually, in practice, the line does not even get crossed, because of our weird disconnect in our timing systems. This gets a bit complex, but try to bear with me... We process sound in buffers, or periods. That's what the "buffer size" option in settings controls, the period size in which we process audio. Now, our non-sample-exact models (which at this point, other than in the models branch, is all automations) are usually polled once per period by whichever part of the program uses those models. For example, say you have a period size of 256 frames, that means that an effect like an amplifier that has a volume knob, processes sound 256 frames at a time, and each period looks at the volume model to know how much to amplify that chunk of 256 frames. Now if we look at how automation works, we have to look at the playback function of the song editor, which handles the playback of all tracks, tick by tick. Now ticks are different from periods, they're not fixed in frameamount, they're defined as 1/48 of a beat, and the actual length in frames is dependent of tempo. So a tick can be either shorter or longer than a period, but usually, in most cases, it's longer. With a tempo of 140 at 44.1khz, a tick is 393.75 frames, rounded down to 393 frames. So at default tempo, at 256 period size (also a common setting), a tick is processed almost every period, but skipping one every now and then. Most of the time, the tick hits somewhere in the middle of a period, and almost never at the beginning. Anyway, since we first process all track events in the playback routine, before we process any audio in the mixer, what happens is that in practice, if a tick hits somewhere inside a period, the value in the automation is set for that period, from the start of that period. So we basically, in practice, do look ahead for automation events. Now for most automations this isn't a problem. For most automations, we actually want the value to be set per-period, because that's how we process the audio. (Also, that makes it easier to interpolate the values more accurately for sample-exact models.) But for tempo, well... you see the problem? If we handle tempo the same way as all other automation, this is almost certainly going to cause problems and inaccuracies in some places. I tried to work around this in the sampletrack branch, and did manage to get the timing accurate, but these kinds of workarounds can have their own sets of problems... So this is why I think processing tempo separately from all other automations makes sense: we want to process tempo per-tick, but we want to process other automations per-period. ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ LMMS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel
