Hi Dan, Good news and bad news - The good news is that I think I know what the problem is, the bad news is that I don't know how to fix it.
I _think_ the problem is the fact that EngineBufferCue(.cpp) doesn't use ControlObjects (or in this context, ControlObjectThreadMain, since it gets called from the GUI thread) when setting the playback position. Instead, it talks directly to EngineBuffer, and I can see those changes cue changes not happening or something. I've also noticed it is highly dependent on your latency. If you hit cue twice very quickly with a low latency (say 16 ms), you won't get the problem. (So it's also possible that trying to cue twice in less time than the latency just won't work, which makes a bit of sense to me.) Anyways, I tried fixing it by setting up the ControlObjects properly in EngineBufferCue, but I ran into some problems. The functions in EngineBuffer that were previously used to get the playback position get the position in some units I don't understand. I tried to do the conversion, but no luck. I don't have time right now to figure out the units though. I tried an alternative approach as well, but apparently the waveform view reads the cue position in those funky units and converts it. By the way, this isn't a problem with the new cue code, it's been a problem for a long time. Because it goes away with lower latencies, it hasn't been at the top of my list. It's definitely worth putting in the bug tracker though... https://bugs.launchpad.net/mixxx/ :) Thanks, Albert On Wed, 2008-04-30 at 13:15 -0400, Dan Gendreau wrote: > This morning I noticed that the new Cue code has some usability issues. > I set a cue point at the start of a drum sample and was trying to use > the cue button to play with some break beats. > > Description: > When I repeatedly press cue quickly to play the drum sample, sometimes > it plays from the start of the cue, other times it starts further into > the sample, cutting off the first drum beat. Repainting the whole > waveform display occurs every time you release the cue button and if I > wait for the waveform to completely redraw, it always starts the cue > cleanly. > > When rapid cueing like this, there also seems to be a good chance that > the play position does not revert back to the cue point as the cue > button is released. As a result, the next press of the cue button moves > the cue point to wherever it was left. > > To reproduce the behavior: > 1) Set a cue point just before a drum beat > 2) press the cue button rapidly (say 2-4Hz) > > At first I thought the problem might be related to handling mouse > double-clicks differently, but it also glitches under midi note control. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Mixxx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mixxx-devel ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
