> .. delay the loading of tracks on the CueControl ..
I think you refer to my changes in EngineBuffer::slotTrackLoaded. The intention was to prevent the track to be loaded at position 0 and the seek to cue position. Now the track is loaded instantly at at cue position. I think this will not put an additional delay on loading tracks because CueControl::loadTrack was called from the GUI thread just after EngineBuffer::slotTrackLoaded and before the track was is playable.
> .. using -1 playposition ..
"track_samples" = 0 is no reliable indicator to detect that no track is loaded, because EngineBuffer::slotTrackLoaded() sets
"track_samples" to a valid value but "visual_playposition" was still pointing to the playposition of the track loaded before.
"visual_playposition" is reliable after seeking to cue point and after the next EngineBuffer::process() cycle.
In my work for waveform de-jerking in daschuers_trunk I have discard "visual_playposition" in favour of a VisualPlayPosition class
which is designed to sync sound output with the waveform display and deals with the limitations of the Qt event queue.
Do we need such a high precise "visual_playposition" CO for MIDI as well or is it enough for now to refer to the "playposition" CO for Midi?
> .. lack of error handling in the waveforms. ..
For me, my changes are fixing the root bug of this problem as explained above. In engine-control-refactor branch you have moved EngineBuffer::slotTrackLoaded to the Engine thread. When merging, we have to ensure that CueControl::loadTrack is still called from the engine worker pool.
Hi RJ,
thank you for your review!
> .. delay the loading of tracks on the CueControl ..
I think you refer to my changes in EngineBuffer: :slotTrackLoade d. The intention was to prevent the track to be loaded at position 0 and the seek to cue position. Now the track is loaded instantly at at cue position. I think this will not put an additional delay on loading tracks because CueControl: :loadTrack was called from the GUI thread just after EngineBuffer: :slotTrackLoade d and before the track was is playable.
> .. using -1 playposition ..
"track_samples" = 0 is no reliable indicator to detect that no track is loaded, because EngineBuffer: :slotTrackLoade d() sets playposition" was still pointing to the playposition of the track loaded before. playposition" is reliable after seeking to cue point and after the next EngineBuffer: :process( ) cycle.
"track_samples" to a valid value but "visual_
"visual_
In my work for waveform de-jerking in daschuers_trunk I have discard "visual_ playposition" in favour of a VisualPlayPosition class
which is designed to sync sound output with the waveform display and deals with the limitations of the Qt event queue.
Do we need such a high precise "visual_ playposition" CO for MIDI as well or is it enough for now to refer to the "playposition" CO for Midi?
> .. lack of error handling in the waveforms. ..
For me, my changes are fixing the root bug of this problem as explained above. In engine- control- refactor branch you have moved EngineBuffer: :slotTrackLoade d to the Engine thread. When merging, we have to ensure that CueControl: :loadTrack is still called from the engine worker pool.
Kind regards,
Daniel