EQDefaultCurves.xml should be in
* Unix: prefix/share/appinfo
* Windows: the directory where the executable file is located
* Mac: appinfo.app/Contents/Resources bundle subdirectory
according to http://docs.wxwidgets.org/trunk/classwx_standard_paths.html#5514bf6288ee9f5a0acaf065762ad95d
I'm guessing that people making those releases should know what that means. The Win one is already sorted.
Patch by Rick Yorgason
I modified it to use linear instead of n squared ring buffer size after verifying that this yields better performance on my mac and pc.
When looking for default curves, EQDefaultCurves.xml is searched for in the DataDir first, then the exeDir, then the error dialog is popped up.
Error dialog stays open while user visits web site to get EQDefaultCurves.xml.
The 'normal' set of curves EQCurves.xml is still in DataDir.
the list of dependent libraries for static library linkage, so they go in libs.private. This was causing the duplication of CFLAGS into the final link (which was clumsy but largely harmless), but also build failures for people with funky multi-part options in their CFLAGS (which is where it was found), because some of the flags didn't survive pkg-config's manipulations and came out corrupted.
This is just a workaround for what appears to be a portaudio bug, where Pa_OpenStream() resets the device level that port mixer should control.
Looked at portaudio src (pa_win_wmme.c's OpenStream()) but I couldn't find the origin of the problem.
Substantial changes to MixerTrackCluster::UpdateMeter() such that it now uses the original Meter::UpdateDisplay() rather than the override I wrote.
I think some of the ideas in the override were good though, mainly to use max and rms from blockfiles rather than passing interleaved sample buffer to Meter::UpdateDisplay() and having it recalculate those values. May be worth revisiting. Definitely worth testing for performance issues relative to 1.3.12.
Also, since all we're doing here is updating the meters, maybe we should remove it from TrackPanel::OnTimer() and do that in audacityAudioCallback where it calls gAudioIO->mOutputMeter->UpdateDisplay(). Thread issues?
Substantial changes to MixerTrackCluster::UpdateMeter() such that it now uses the original Meter::UpdateDisplay() rather than the override I wrote.
I think some of the ideas in the override were good though, mainly to use max and rms from blockfiles rather than passing interleaved sample buffer to Meter::UpdateDisplay() and having it recalculate those values. May be worth revisiting. Definitely worth testing for performance issues relative to 1.3.12.
Also, since all we're doing here is updating the meters, maybe we should remove it from TrackPanel::OnTimer() and do that in audacityAudioCallback where it calls gAudioIO->mOutputMeter->UpdateDisplay(). Thread issues?
// I suggest that when this is no longer experimental, rather than all these #ifdef's,
// this be done by factoring, i.e., add two subclasses to MixerTrackCluster,
// MixerNoteTrackCluster and MixerWaveTrackCluster, such that all the common
// code is in the parent, and these #ifdef's are only around
// MixerNoteTrackCluster rather than sprinkled throughout MixerTrackCluster.
This bug was introduced in commit 10680 and caused in MixerTrackCluster::UpdatePan(), by using USE_MIDI (which is on in releases) instead of EXPERIMENTAL_MIDI_OUT (which is off). It checked whether a NoteTrack pointer was NULL, and if not, hid the Pan slider (not used in NoteTrack clusters). But an invalid pointer is non-null, so was causing the Pan slider to always be hidden.
