| Age | Commit message (Collapse) | Author |
|---|
|
but basically functional for audio files
|
|
periodic save is done with maybe_write_autosave()
|
|
is follow-edits. when you select a range, the playhead should jump to the start of the range and begin to play the selection. BUT (unlike previous implementation) if the user wants to relocate the playhead, then that should be allowed. The user should always remain in charge of the playhead location. NOTE: your previous config setting will be invalidated. You must re-save a session to overwrite with the new config variable
|
|
modifying the range with keyboard commands.
|
|
Manually resolved conflicts in import.cc and session.cc
|
|
|
|
temp. disable save during batch updates, save once at
the end.
|
|
|
|
memory leaks
|
|
amend to 8f52bf7d9f
|
|
sources, especially when created via import
|
|
|
|
Session::source_by_path() to check if an AUDIO filesource with a given path already exists.
::source_by_path() was written for MIDI files only. I fixed the call and renamed the two similar functions (one for audio and one for MIDI) to make it more clear.
|
|
|
|
|
|
change markers
|
|
the "play loop" button.
If enabled, then the button simply changes the behaviour of the "play" button rather than actually starting playback. If disabled
transport behaviour should be unchanged from before.
|
|
renaming
|
|
region on demand and cloning/unlinking
Existing code would cause data loss due to creation of two Source objects referring the same path, one with removable flags and one without. Careful code review suggested a variety of thinkos, function naming problems and other confusion that caused this. I have tried ot extensively comment what is going on with these operations, because it is one key area in which MIDI differs from audio: with audio, capture is the only way to add a new audio region, but for MIDI there are GUI input events that can add a new region.
|
|
renaming
|
|
region on demand and cloning/unlinking
Existing code would cause data loss due to creation of two Source objects referring the same path, one with removable flags and one without. Careful code review suggested a variety of thinkos, function naming problems and other confusion that caused this. I have tried ot extensively comment what is going on with these operations, because it is one key area in which MIDI differs from audio: with audio, capture is the only way to add a new audio region, but for MIDI there are GUI input events that can add a new region.
|
|
|
|
|
|
|
|
libardour symbols (revision and ardour_config_info)
|
|
#include paths)
|
|
building with MSVC. Currently includes debugging information and things that are just commented out until we have known compatibility with the other platforms (i.e. contains stuff to be removed at a later date)
|
|
merge windows branch to get changes from there
|
|
|
|
|
|
|
|
ardour,but ... )
|
|
(libltc, rubberband, taglib, vamp-sdk)
|
|
|
|
|
|
|
|
Conflicts (hopefully resolved):
gtk2_ardour/wscript
libs/ardour/ardour/audioregion.h
libs/ardour/ardour/debug.h
libs/ardour/ardour/directory_names.h
libs/ardour/ardour/filesystem_paths.h
libs/ardour/ardour/session_event.h
libs/gtkmm2ext/gtkmm2ext/utils.h
libs/panners/1in2out/wscript
libs/panners/2in2out/wscript
libs/panners/vbap/wscript
libs/pbd/pbd/debug.h
libs/pbd/pbd/file_utils.h
libs/pbd/pbd/pathexpand.h
libs/pbd/pbd/ringbuffer.h
libs/pbd/pbd/ringbufferNPT.h
libs/pbd/pbd/search_path.h
libs/pbd/pbd/stacktrace.h
libs/pbd/pbd/uuid.h
libs/pbd/pbd/uuid_boost.h
libs/surfaces/control_protocol/control_protocol/basic_ui.h
libs/surfaces/control_protocol/control_protocol/control_protocol.h
|
|
|
|
|
|
|
|
into the JACK backend)
|
|
state of the click IO object
|
|
|
|
|
|
|
|
n_physical_{inputs,outputs} members which were (a) not initialized early enough (b) not used anywhere except monitor bus connection.
Things almost make sense now.
|
|
|
|
into its own method. sorry, ardour build-from-source folk :)
|
|
to be complete)
|
|
every session member is now initialized using C++ constructor syntax
session construction reordered to clarify the split(s) between work
where the engine is not relevant and work where is it is. this
split is still not 100% obvious, but is enormously clearer than
previously.
if engine/backend are not running as session is created, and the SR
of the sample rate is known, attempt to force backend to that value.
|
