Hey Shanx, Sorry for the brief response (at work), but in general, could you clarify why you need to know whether or not the engine has sync'd yet? In general, all the scratch and wheel controls work as accumulators. You add or subtract from the value of controls like wheel or scratch2, then the engine processes them and resets them to 0 once it has processed them.
The way you're going about it (creating a thread) is probably not the best way to know when the engine has processed data. If you use the controls like accumulators, then you can listen to valueChanged signals from the engine and look for when the value is cleared. You can use that to trigger any logic you'd like in the waveform widgets. Also, you shouldn't really rely on ControlObject::sync() calls to mean that the engine has done work. Incoming messages from MIDI also cause sync's. In the future, other thing might cause sync()'s. You should rely on the engine accumulator controls you're using (e.g. scratch2) to tell if the engine processed them (via their valueChanged signals). Thanks, RJ On Wed, Mar 30, 2011 at 4:51 PM, shanx <[email protected]> wrote: > Has anyone ever tried to tame mixxx's engine? > its a different beast altogether ;) > > There is a design based drawback of my last approach, let me explain by > starting from what I was trying to do. > Its simple, I set the distance traveled by mouse as rate using scratch2 CO > but before I do this I check if engine has yet synced > (ControlObject::sync()) last value I have set. This check calls for 3 cases: > 1. Engine has synced exactly once -> great, this is what I want. > 2. Engine has not synced yet -> add the last value of distance to current > value then set > 3. Engine has synced more than once -> last set value has been used more > than once, so subtract the product of last value and one less than number of > times engine has synced from the present value and set this new resultant > value. > > The design problem is in case 3. > Just imagine what will happen to sound output. Engine has first played the > audio few seconds more than needed and then I try to bring waveform one on > one with mouse by playing those extra few seconds in reverse. Crap! > > So here is a *new* approach: > Set the new rate only after engine has synced last value. > To do this, I have started a thread which checks if engine has yet synced. > If yes, shoot a signal that will tell a slot in WGLWaveformViewer to > calculate new distance and set it. > Cool, at first sight it looks as of this is should work. :-) > > I have already implemented this approach, This approach has a design flaw > again - sometimes engine is so fast that before the slot in > WGLWaveformViewer sets a new value, engine has already synced again. That > means my last set value has been used more than once! > > Now I need some help. > In a nutshell this is what is to be done > "Set the new rate only after engine has synced last value." > > Any idea guys? Any random idea how this can be done. Random ideas might > help me to make up something that may work. > > > > > > ------------------------------------------------------------------------------ > Create and publish websites with WebMatrix > Use the most popular FREE web apps or write code yourself; > WebMatrix provides all the features you need to develop and > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf > > _______________________________________________ > Mixxx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > >
------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
