On Tue, Dec 8, 2009 at 7:57 AM, Graham Percival <[email protected]> wrote: > NB: if you check out this branch, please bear in mind that I'm not > responsible for the original code. I will make sure that it's in good > quality before submitting patches for trunk, but my priority to date was just > getting far enough that I could meaningfully discuss the below questions. > Having spent about 10 hours working on the previous guy's code, I'm > entertaining various fantasies of a violent nature. Fortunately, he's off in > South America, so I'm safe (he could totally whip me in a fight!).
Who -- Dougie? I'm sure he's spent enough time entertaining violent fantasies about the idiots who wrote the rest of the Rosegarden code! I think much of the pitchtracker code should be qualified as a pragmatic choice rather than an aesthetic one. > 1) Getting audio samples. In order to display a realtime visual display of > the pitch, we obvious need to compute the pitch, which requires raw audio > samples. At the moment, I've used the old src/sound/JackCaptureClient from > earlier work. However, I'm not certain if this is the best way to do things; > if I were maintaining rosegarden, I'd be tempted to insist that the > contributors rewrite src/sound/JackDriver to add realtime capture to the > framework. The reason this did not happen the first time around is that in RG 1.7.x, the JACK driver lives in a totally separate application (not just a separate thread or set of threads) from the GUI. A _lot_ of design issues in Rosegarden can be understood by bearing in mind that the sequencer and GUI always used to be separate processes. Hence, a JACK capture client added to the GUI to avoid having to do some insane kind of IPC. This is what I mean by "pragmatic". If you would like to see what would be involved in using the JACK driver, please go ahead; it should be more feasible now, in the Thorn code. > 2) Is slot pointerPositionChanged the best way of getting continual updates > about time? It depends. pointerPositionChanged is a perfectly good way of getting updates within the GUI, but it is updated by polling on a QTimer within the GUI thread (formerly "within the GUI process" -- in fact in RosegardenMainWindow::slotUpdatePlaybackPosition) rather than being the result of a synchronous notification from the sequencer. So there is a significant degree of extra latency and jitter -- it's OK for continuous updates like the playback pointer, but one would not use it for example to align audio recording (except at the very start of playback where the position value should be good). The alternative would be to get timing values directly from the sequencer in e.g. RosegardenSequencer::updateClocks(), but this would imply that you were using the results in a sequencer rather than a GUI thread. > 3) In order to use the old pitch detector code, I needed to add fftw3 to > Makefile.in. Is that ok? I normally wouldn't like to add a dependency, but > fftw3f was in there anyway. Fine. > 5) I dumped the pitch detector code into src/misc/PitchDetector. What the > right place for it? > This class takes a buffer of samples and produces a pitch value. I didn't > think it was really sound/ material, since it wasn't an audio driver I would put it in sound/ -- there are other things in there that are to do with audio processing rather than being sound drivers. Chris ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
