This data was generated asynchronously and is not required to be "silenced"
the way that session data would be. Compare also to the similar tests for
sync-related MIDI ports
This is needed for save-as and archiving, LV2 state may not be saved
otherwise if lilv_state_equals() returns true.
Also if thestate is saved as part of save-as or archiving or
template, the state-version did increase.
Upcoming normal save will reference a plugin state that does not exist
in the current session bundle.
state-restore does not set the same flag, so lilv_state_equals()
returns false even for identical states and a new state is saved regardless
actual fix also depends on http://dev.drobilla.net/ticket/1145
This should be the final part of a fix for bug #7025, which means the id
property of PBD::Controllable is restored and a new id is not generated at
first save.
I'm assuming this was a typo, comparing with the wrong name meant the state of
the MuteControl was never being restored. This also fixes restoring bindings
associated MuteControl instances.
This is part of a fix for bug #7025 which means the id property of
PBD::Controllable is restored and a new id is not generated at first save.
This also fixes restoring bindings associated SoloControl instances, which is a
bit surprising hasn't been noticed/reported.
This fixes the libpbd testCanonicalPathUTF8 and libardour
open_session_utf8_path unit tests
You can now have Sessions with localized names containing characters that
aren't in the system codepage on Windows.
It also fixes the issue where a Session would not open when it was moved into a
path with characters that aren't in the system codepage.
The only use case for calling canonical_path/realpath on the session path
AFAICT is for resolving relative paths that are passed via the command
line/terminal. I'm doubtful that works correctly on Windows because of
character encoding issues with the current API we use for that(not glib), so it
is slightly ironic that this issue was caused by an incorrect implementation of
a function that is not really necessary on Windows at this point in time.
This currently fails because the windows only realpath implementation in
pbd/pathexpand.cc, which is called from PBD::canonical_path to resolve the path
uses Glib::locale_from/to_utf8. As I demonstrated in the
testOpenFileUTF8Filename test case Glib::locale_from/to_utf8 are not the
correct functions to use for this use case as it converts to/from utf-8 to the
locale's current character encoding. On Windows this is most often a single
byte encoding such as Windows-1252 and conversion will fail if the path
contains any characters that are not in system codepage.
The default scheduling on windows seems fairly erratic or is at least in the
VM that I'm running these tests on, so increase the timing slack a bit so the
test has a better chance of passing. It is still quite easy for it to fail
though, especially if you for instance manipulate the terminal window somehow
while running the tests but it does not really matter in any case as this test
serves its purpose in testing the PBD::MMTimers API.
The issue is that when ExportDialog is destroyed
ExportFileNotebook::FilePage::on_hide is called which in turn calls
ExportProfileManager::save_format_to_disk() in order to save changes to the
analysis and soundcloud upload checkboxes. This then causes the
ExportProfileManager::FormatListChanged signal to be emitted, which in all
other cases is emitted when the format list is modified so that the GUI can
rebuild the format selector menu in ExportFormatSelector::update_format_list
when a format is added or removed.
The problem when doing this in the destructor is that some of the widgets have
already been destroyed, specifically the issue was in
ExportFileNotebook::update_soundcloud_upload trying to access the
soundcloud_selector member that had already had its destructor called.
As it is not necessary to call this signal in the first place and it just
causes unnecessary GUI updates remove the signal emission.
let the user/developer know if this does occur rather than just silently
skipping the file.
Fix some whitespace issues while we are changing indentation.
The paths are in UTF-8 encoding and ::rename expects paths in the system
codepage encoding so ::rename will fail for any paths that contain characters
that aren't in the system codepage.
This fixes Flush Wastebasket on Windows where paths contain characters that
aren't in the system codepage(usually most non-ascii characters).
The path is in UTF-8 encoding so use Glib functions to properly support paths
containing characters that aren't in the system codepage.
This fixes Clean-up Unused Sources on Windows where paths contain characters
that aren't in the system codepage(usually most non-ascii characters).
Some Mixbus users (on Windows) have reported seeing ludicrously high figures for the amount of disk space that'll be recovered if they choose to clean up unused sources. I can't see anything obviously wrong in Ardour's code - except for one situation where we don't check a return value after calling 'g_stat()'.
On Windows, the relevant path should be (hopefully!) in UTF8 format and the first thing that g_stat() does is to convert it to UTF16. If that conversion fails for some reason, g_stat() will return an error status and statbuf will be uninitialized - but at the moment, we're not checking this. As an experiment, let's check the returned value and find out if these user reports go away.
Unfortunately, if it does fix the problem then we've got an even bigger problem - because somehow, a Windows user can create source files with invalid names which can't be later deleted!!
Clearing location markers is a frequent task and should be automizable. For
example it is handy to clear all the markers when restarting the recording
from scratch after a failed recording.
If a Session is saved and then the start or end session markers are moved,
closing the Session will not result in "Unsaved Session" dialog being presented
even though the Session has been modified. This change sets the Session as
modified when either the Session start or end markers are modified.
- after reports that a tempo with non-4.0 note type
would produce a ramp in the preceding section, an incorrect
assumption was made leading to a bogus 'fix' that redefined
Tempo's pulses_per_minute().
the real fix was simple:
the ramp's function constant was calculated using the note type
of the proceding tempo rather than the current one.
- this patch reverts e82482e8e9 and a4d67279e0
and maintains the old definition of Tempo::pulses_per_minute()
