| Age | Commit message (Collapse) | Author |
|---|
|
- also use the return from AutomationLine::drag_motion () in
anticipation of it correctly reporting its clamping to
AutomationRangeDrag.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There is anecdotal evidence that using mpeg4 as codec leads to issues
(xjadeo indexes and gets stuck at 99%, likely in libavcodec).
The main motivation for using mpeg4 is/was windows/VFAT 2GB file limit
and improved video quality. This will have to be revisited.
|
|
|
|
if Terminated() connects in the same thread and deletes the class itself
the closure in interposer_thread() can fail.
|
|
- also removes many uninitialised variable warnings in
editor_drag.cc found by cppcheck.
|
|
|
|
|
|
- Also fix selection undo when creating notes w/control
in MouseContent mode.
|
|
Also moved duplicated code to one function.
|
|
File glob "*.ardour" -> application/x-ardour is defined in ardour.xml
|
|
|
|
Also opt for version-agnostic mime-type (file-format version
is independent of program-version and of file-extension)
|
|
Currently when a GhostRegion is deleted by its "parent" RegionView it emits the
static GhostRegion::CatchDeletion signal which is connected to the
RegionView::remove_ghost method of every RegionView instance.
With a static GhostRegion::CatchDeletion signal a particular test session
causes 31 Million calls of RegionView::remove_ghost on Session deletion and the
session takes 70 seconds to close with a debug build.
The lifetime of a ghost region is tied to both the TimeAxisView(TAV) and
RegionView(RV) in that when a RegionView is deleted all GhostRegion instances
associated with the RegionView should be deleted or when a TimeAxisView is
deleted all ghost regions that are contained in the view should be deleted.
This means that there needs to be notification between GhostRegion and both
classes. Instead of using a signal for this as we know there are only two
listeners and GhostRegion already holds a reference to the TimeAxisView, also
take a reference to the parent RegionView in the GhostRegion constructor and
use it to notify the RegionView when GhostRegion destructor is called so it can
drop any references it holds.
Using a direct function call in the GhostRegion destructor to notify the
TimeAxisView and RegionView "parents" brings the unload/close time down for the
test session from 70 seconds to 4.5 seconds.
The GhostRegion also references canvas items that are added to the TimeAxisView
canvas group or at least a canvas group that it manages. So when the
TimeAxisView is destroyed and the canvas group that is the parent of those
items is destroyed, the GhostRegion's canvas items will also be
deleted/destroyed by the parent canvas item/group. This means the GhostRegions
must be destroyed when the TimeAxisView they are contained in is destroyed or
there will be dangling references to canvas items that have already been
deleted and trying to delete them again will be bad.
|
|
|
|
When loading a Session add the Session patchfiles directory to the
MidiPatchManager search path and only process/parse the files for that
directory rather than refreshing/reparsing all the files. Similarly for unload,
just unload the devices that are from the Session specific midnam files instead
of removing the path and refreshing/reparsing all the files.
This will not remove the "system" midnam files as they are always added first
and duplicates from the session patchfiles directory are ignored.
|
|
This is so we can compare and see if we have already parsed the file
|
|
The MidiPatchManager only requires a reference to the session to get the path
to the Session midnam directory so change it so that the path is passed to
MidiPatchManager::add_search_path on Session construction and removed on
Session Destruction. This will also make it easier to test and reduce compile
times etc.
For the common case where the Session doesn't have a Session specific midnam
patch files directory(for instance a new session) it won't cause a refresh and
reparsing of all the midnam files. This saves about 2 seconds to load a Session
on my machine(fast machine with SSD), or about half the time spent in the
Session constructor for a new session.
There is still going to be that initial cost of parsing the midnam files when
the first session is created after starting Ardour. Options to remove that
would be to parse the files asynchronously and or use a faster xml
parser(eventually), neither of which seem worth doing at this stage.
This change will cause a performance regression for the uncommon case where a
Session with Session specific midnam files is unloaded and then another Session
with Session specific midnam files is loaded as it will cause the common midnam
files in midi_patch_path to be parsed twice(unload and load).
|
|
|
|
I prefer to use these as they are more explicit than using the overloaded
operators.
|
|
MidiPatchManager::refresh already adds the patch files contained in the session
folder
|
|
|
|
Currently when loading a session for the first time MidiPatchManager::instance
creates the MidiPatchManager singleton which calls MPM::refresh and all the
midnam files are parsed etc. MPM::set_session is then immediately called and
all the MPM state that has just been set when parsing all the midnam files is
cleared and the parsing of all the files is performed again but this time with
any session specific midnam patch files.
MPM::instance and MPM::set_session consume about 55% of the time spent in the
Session ctor according to kcachegrind and removing the double call to refresh
brings Session construction time for a particular test session down from 7.5s
to 5.5s
|
|
able to load
In the function 'LV2Plugin::add_state()' the snprintf() call can easily print 19 or even 20 bytes - so a 16-byte buffer wasn't large enough.
|
|
|
|
|
|
|
|
|
|
There is a highly unlikely case where the render thread can have zero
requests in the queue, but it is not supposed to be terminated.
1) WaveView::queue_get_image();
wake up thread, *but* the thread does not start yet
2) WaveView::cancel_my_render_request();
and now the thread starts.
1,2 are initiated by user actions from the GUI thread and are normally
orders of magnitude slower than scheduler-thread wakeup.
|
|
|
|
|
|
|
|
|
|
Before it could not overwrite.
|
|
|
|
|
|
AutomationControl::writable() and use them.
Classes derived from AutomationControl now check ::writable() in their ::set_value() methods to ensure that they
do not attempt to overwrite data sent to them while automation playback is underway.
|
|
|
|
|
|
|
|
- looks like the install target for these has been removed, but
the existence of these may be of help to packagers.
|
|
|
