So, I recently attempted to implement improvements to sampletrack functionality: most importantly, the way to play sampletracks from any part of the song, in a reliable way, with accurate timing that works with or without tempo automation. It eventually became such a complex project with tons of changes - 11 files changed, lots of core functionality tweaks - that it's not feasible to include in 1.1 so I'm putting it to rest, waiting for 1.2.
Anyway, what did I learn from all this? A couple of things... The tempo automation is always the tricky part in these kinds of things. Without it, it would be a simple matter of just calculating ticks * framespertick and using that as a frameoffset for sampletrack playback. However... Since we allow automating tempo just like any other model, there's three places where tempo changes may be recorded in: - the song-global automation track (invisible, only accessible from the widget's context menu) - regular automation patterns in the song - bb tracks in the song (because they may themselves contain automations) Even worse is that it's possible to connect a controller to tempo. For example, if you connect a LFO with noise selected on the tempo widget, it becomes literally impossible to accurately predict the tempo... sure, that shouldn't be an issue as when is anyone going to want to randomize the tempo, but, well... the option shouldn't be there then. I wrote some functions for calculating the frame offset of any tick by going through all the ticks from the start to the current position, searching for tempo values in each tick, converting ticks to frames by framespertick( tempo ) and adding them up... problem is, this gets exponentially slower the further you go in the song, and also, it seems to somehow break down with long sampletracks - I'm not certain what the problem is, but somehow it gets inaccurate... also, drawing of the sampletrack becomes very slow. I think that many of these problems could be solved if we had a singular tempo map, a single place where tempo values accross the song are cached and can be looked up from. Now, apart from the controller issue (which is just a matter of modifying the widget to prevent controller connections) this could be achieved with the current way of tempo automation - we could add in special code to AutomationPattern, which checks if the pattern is connected to tempo, and if so, reports all changes to a central tempo map. However, it again becomes tricky with bb-tracks - then the bb-tracks would need to have similar code, and automation patterns require more code to ensure they're not in a bb-track so their reports don't conflict with the bb-tracks' reports... *head explodes* My preferred solution would be to create a static, unremovable, special new track type: tempo track. You can't create new ones, you can't delete the old one, it's just always a static part of the song editor. We could use the existing clock icon as an icon for it. It could be moved up and down but by default it'd be at the top. This tempo track would then be the only place where tempo automations are allowed. It would contain regular automation patterns, but with one difference - those patterns are always connected to tempo and can't be connected to anything else. Automation patterns would just require code to check "is this pattern on tempo track" and if they are, set the connection to tempo, otherwise, let it be set anywhere else (but not on tempo). You could copy other automation patterns to it, but they'd be converted to tempo automation patterns. The tempo track would then keep track of the tempo (no pun intended). It would contain a global dictionary of cached tempo values, all accross the track, and determining the tempo at any point would be as simple as looking it up. Furthermore, frame values at each point could also be cached, as well as framespertick-values - then it'd be simple to figure out the frameposition at any time: just go through the dictionary, get the latest saved value at latest tempo change, count up from there by using the framespertick-value saved at the same position. This is getting a bit technical, so I'm just going to say that personally, I'm not going to want to work on the sampletrack branch any further until/unless we get some way to accurately - and *efficiently* - look up tempo. I think a tempo track, one single place to automate tempo, would be the best way to do this, but I'm also open to other ideas. Toby, would love to hear your thoughts on the matter. ------------------------------------------------------------------------------ "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
