On 05/24/2014 08:30 PM, Tres Finocchiaro wrote: > > Its not so much about playing straight through as it is about clicking > ahead in a track. In order for the sample track to play at the proper > moment requires iterating through the automation controllers to find > out where the actual play time should start from. > > See, when you play a sample track from the beginning it just naturally > plays through until finished, however jumping onto it from some other > position begs the question "where would this sample have been playing > from?". It also causes other problems, such as the waveform being inn > inaccurate unless it is redrawn at a "stretch" representing the tempo > at that given time. >
Correct. Thanks for the explanation, Tres. > Vesa is asking if we can strip out all standard automation on tempo so > that this can all be calculated properly with a dedicated tempo > automation track. > > I don't disagree fundamentally although I'd vote we instead have a > max-automation events property for it and just lock it from being > dragged to more than one controller. > Well, controllers aren't really the issue here. Controllers should probably be prevented from being connected to tempo at all, but right now you can already only connect one controller to any model. Automation is different from controllers, you can connect as many automation patterns as you want on any model, and furthermore, each model can also have its own global automation track, which is hidden... even worse, you can connect overlapping automation patterns to a model, which causes undefined behaviour ... Are you saying, you'd make tempo only able to connect on one automation pattern? That'd mean that if you want to change tempo at bar 3 and bar 120, you'd have to make a single automation pattern that is 117 bars long... doesn't seem very user friendly. Or are you saying you'd only make tempo being able to connect to one automation track? But that's a bit tricky, because we don't handle connections per-track, we handle them per-pattern... and that would also mean we'd have to separate the tempo-patterns from non-tempo-patterns, and this would make things more complex and less efficient... Can you elaborate a bit more on what exactly you're suggesting here? > But I'm not capable of coding this feature so my opinion is moot. > It's not moot... you can always express ideas even if you're not capable of personally coding them. Ideas are always needed... ------------------------------------------------------------------------------ "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
