Open mixxxbot opened 2 years ago
mixxxbot
commented
2 years ago Commented by: rryan Date: 2013-03-22T01:09:16Z
Yea, I think the controller system needs to be updated to include timestamps on all messages that get passed around (even expose them to script land). I think this is probably a huge source of jitter in scratching since there are arbitrary delays inserted from the time we read the message to the time we process it.
mixxxbot
commented
2 years ago Commented by: Pegasus-RPG Date: 2013-03-22T06:16:40Z
Also note that some (usually moving platter) controllers send their own time stamps, so it would be advantageous if a script could override the ones PM supplies, where scratching is concerned at least. This ties in to the manipulation consolidation blueprint (linked.)
mixxxbot
commented
2 years ago Commented by: daschuer Date: 2013-03-22T07:06:51Z
Lauchpad leaks in blueprint discussion threads. So i will comment here https://blueprints.launchpad.net/mixxx/+spec/manipulation-consolidation.
It is a good idea to clean up and unify the scratch path in mixxx. But I am in doubt if we can do it in the first place. Because of so much different issues with different scratch sources I would prefer to first divide it even more and tweak specialized solutions to the maximum. In the second step we can try to find common paths and unify theme without performance regressions.
For example I have joust tweaked the position scratch for a standard mouse Bug #1117806. So it works fine. but all other position scratchers (I hope there aren't any jet) will not work that well. So i would prefer to introduce a CO "Standard Mouse Scratch" and maybe offer a additional un-ironed CO "porsition scratch" for the rest.
mixxxbot
commented
2 years ago Commented by: Pegasus-RPG Date: 2013-03-22T08:39:34Z
While there will indeed be differences in how scratch data from various input sources will need to be massaged, I currently believe that the strategy for handing the input data (e.g. a PID controller) should be the same regardless of the source of that data. As long as sufficient tweakable parameters are provided in that common class, each source can tune them as required while all benefit from improvements. I'd rather do the factoring now (then extend the common class as needed for additional sources) rather than later so that the work is only done once. Also see the comment I put on the whiteboard in the blueprint.
mixxxbot
commented
2 years ago Commented by: daschuer Date: 2013-03-22T09:27:48Z
A PID was the first approach how we have started against Bug #1117806.
But we have learned, that a simple PID controller does not suit to give acceptable results. After a lot of measurements and simulations we end up in a complex combination of an IIF + PD + Fuzzy.
Controller wheel scratch should be much simpler, because we need not do a position scratch. (Please correct me if I am wrong) It can be a rate scratch because we are not that much tied to the track position like waveform scratch.
My hope is that we get good results if we eliminate the jitter due to the midi time stamp and an IIF (low pass filter) to iron out remaining spikes.
I would be happy, if we could do this instantly in a common solution without performance compromises. IMHO a challenging task!
mixxxbot
commented
2 years ago Commented by: Pegasus-RPG Date: 2013-03-22T10:53:06Z
I'm not exactly sure what you mean by a 'position scratch' but I'm taking it to mean that the input provides track position information? If so, then that's needed for vinyl control in absolute mode too (which already works very well,) but not for controllers since they always send relative position information.
Combining the three inputs into a common solution would have a performance benefit I think since then you only need one high-resolution timer instead of three separate ones.
mixxxbot
commented
2 years ago Commented by: daschuer Date: 2013-03-22T11:20:54Z
Yes right, waveform scratch is using:
COs "scratch_position_enable" and "scratch_position"
while the rest I think is using "scratch" or "scratch2" and "scratch2_enable"
I am not sure which high-resolution timer your mean. Simply query our new PerformanceTimer does not hurt. What would hurts is an other real-time task apart from the Audio-Engine-Task and the time critical waveform renderer (currently in GUI Thread). This is the issue of Bug #1157579.
mixxxbot
commented
2 years ago Commented by: rryan Date: 2014-03-24T23:06:07Z
It can be a rate scratch because we are not that much tied to the track position like waveform scratch.
The main issue we face with rate scratching is sticker drift. The user will notice if the play position drifts from where they started with over time. If you turn a wheel a full revolution then turn it back (no matter the speed) it should be ~exactly where you started in the track otherwise people will say we have drift.
mixxxbot
commented
2 years ago Commented by: daschuer Date: 2014-03-24T23:24:56Z
OK then we have to look at the use cases:
1: scratching as effect: rat scratching produces the best sound 2: seeking though a track: position scratch hold the position.
Haven't we the same two modes for vinyl control?
mixxxbot
commented
2 years ago Commented by: ywwg Date: 2014-03-25T19:09:23Z
fwiw, "sticker drift" is a very hard problem. The solution should be very carefully considered and designed.
mixxxbot
commented
2 years ago Commented by: Pegasus-RPG Date: 2016-04-28T14:13:32Z
In the controller system, we're currently converting position deltas from the controllers into velocities and manipulating the deck speed with that. To me that's sub-optimal and is practically guaranteed to cause sticker drift. If the waveform scratching is already position-based (which by definition is drift-free,) it seems to me that the Controller system needs only to pass along the position deltas and time stamps to a common ScratchProcessor class that uses the same processing as that in the current waveform scratching. (Then the waveform would also be connected to this ScratchProcessor and simply pass along mouse position data and time stamps.) Thoughts?
mixxxbot
commented
2 years ago Commented by: Pegasus-RPG Date: 2016-04-28T14:16:55Z
Can someone also please document "scratch_position_enable" and "scratch_position" at http://mixxx.org/wiki/doku.php/mixxxcontrols ? It may be as simple as changing the controller system to use those instead of scratch2.
mixxxbot
commented
2 years ago Commented by: daschuer Date: 2016-04-28T19:32:00Z
scratch_position_enable: Enables the PositionScratchController controller. It is set when you press the left mouse button on the waveforms or the spiny.
scratch_position: is the track plyposition calculated from Mouse position on the waveform or spiny.
They are intentionally not documentation, because they are where not designed for controller or skin mappings.
It took me quite long to get acceptable results for mouse scratching by tweaking the filter algorithm and parameters.
One of the target was to remove the wobbling sound when the mouse as moved with constant tempo near rate 1.0 On of the difficult issue was that there is no time stamp but an extreme jitter of the mouse position per time. This was improved by a II-Filter. Than there is a PD-Filter, which tries to keep the velocity const and some surrounding conditions to handle some exceptional cases.
The filter parameters where tweaked exporting the time and value data to an "ooo Calc" sheet and generate X Y graphs. Than I have added the filter formulas and watch how the output graph as changes
Since we have the midi time stamps, smoothing the controller scathing should be somehow simpler. At least it may require different Filter settings.
Reported by: daschuer Date: 2013-03-20T07:09:53Z Status: Confirmed Importance: Low Launchpad Issue: lp1157573 Tags: controllers, midi
Depending on the wheel resolution and the controller polling rate and the audio buffer size, we may see a jitter which may result in an unwanted speed oscillation. Bug #6950 This possible could be avoided if we take the midi time stamp into account http://portmedia.sourceforge.net/portmidi/doxygen/structPmEvent.html