Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
Double clicking on a file or pressing the Return key will now import it.
This means with autoplay enabled you can navigate a directory of audio files
using the up and down arrow keys and import the wanted files (with Return)
without having to touch the mouse.
Being able to use double click to import a file means you don't have to move
the mouse back and forth between the file browser and the import button.
You can still manually audition the file with space as before.
This needs further work:
Type-1 SMF are always
"One [Ardour] track per [MIDI] track"
Only type-0 SMF have the option
"One [Ardour] track per [MIDI] channel"
and
"One [Ardour] track per [MIDI] file"
This is ambiguous with multi-channel audio or multiple selection,
mixed audio+midi and worse with mixed type0/1 .mid selection.
This calls for a dedicated dropdown to select MIDI Import Disposition
for type-0 SMF.
The instrument dropdown can be very wide (depending on available synths)
and combined with other dropdowns and the copy-checkbox in a single row,
the min. width was well above 1400px.
Too many users report they import their first tracks and can't find them.
Previous default was "at file timestamp". If a file has no timestamp,
the import dialog shows "00:00:00:00" but in absence of a timestamp,
Editor::add_sources() first checks target tracks and adds add it after
the last region, then falls back to use preferred edit position as
insert point.
In the rare case where a file has timestamps it may show up a few hours
in the future.
conclusion: import-at-timestamp is not a good default.
When importing to new tracks, newly created tracks are selected
Editor::track_selection_changed()
-> SoundFileOmega::reset()
-> SoundFileOmega::reset_options()
-> check_info() fails -> Glib::signal_idle() error message.
it is unclear why check_info would fail in this case since it
worked in the first place.. best guess: a concurrency issue
opening the file.
Glib::operator<<(std::ostream&, Glib::ustring const&) involves
loadlocale which is not thread-safe on OSX.
This fixes various seemingly random crashes on OSX.
Don't close the window when clicking on Import. Changing "OK" to "Import" makes
it clear what action is being taken by the button. I quite frequently imported
several files from different directories using "Apply" and then would click on
OK to finish using the dialog only to have the last import occur again
unintentionally.
Another option would of been to change "Apply" to "Import" and "OK" to "Import
and Close" and not have a Close button.
This button closes the window, it doesn't actually cancel any importing that
has taken place and cancelling the import in progress is done by the Cancel
button in popup progress dialog
see 87b89a6
IMPORTANT NOTE: In theory, the correct glibmm function should have been Glib::filename_from_utf8() but I couldn't make that work on Windows and
ended up using Glib::locale_from_utf8() instead. sfdb import will therefore
need to get re-tested on the other platforms (especially in a non-English locale).
If this fix doesn't work we should probably revert to the previous strategy
but using the global specifier "::g_open()" explicitly…
… and only on PLATFORM_WINDOWS (POSIX #define g_open open) fails regardless.
This reverts commit 1a619472ca.
On Unix systems "#define g_open open" interferes with class member function
IMHO this is the wrong approach, the filename should be converted using
glib::filename_from_utf8().
For sfdb stuff, use glib file functions in preference to ANSI or libsndfile handling. On Windows, we need functions which understand UTF-8 (so that we'll be able to import sound files, even in a non-English locale).
