Age | Commit message (Collapse) | Author |
|
Route::Auditioner. this has been the meaning of these terms for years now and it would be better to make it explicit
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@13850 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
speed is reversed (should fix #5264)
git-svn-id: svn://localhost/ardour2/branches/3.0@13848 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@13747 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
incomplete)"
This reverts commit 13708 -- because it's the wrong approach to fix this.
git-svn-id: svn://localhost/ardour2/branches/3.0@13713 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
should fix #5221
git-svn-id: svn://localhost/ardour2/branches/3.0@13708 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@13665 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
13:00 < rgareus> When a slave does initial sync, it sets speed=0, pos=XXX (required by session_process.cc state-machine to init)
13:01 < rgareus> This triggers a locate(roll=false) which in turn triggers a realtime_stop() which in turn triggers a non_realtime_stop().
[..]
13:06 < rgareus> las: the problem I have with non_realtime_stop() is that it does save a pending state IFF get_record_enabled() is true.
13:06 < rgareus> The save can take ages (seconds), which will void the initial sync of the slave.
13:07 < rgareus> The slave enters a live-lock: sync, save, re-sync, save...
13:07 < las> rgareus: understood
13:07 < rgareus> las: I propose to workaround this: only save pending state if there is no slave or the slave is not locked.
13:07 < las> rgareus: another reason why recording + slave == bad idea :(
13:07 < las> rgareus: but yes, that sounds fine to me
13:07 < rgareus> AFICT this is not harmful. It only affects pre-record settings.
13:07 < rgareus> 'did_record' is used to save a full state after each recording.
git-svn-id: svn://localhost/ardour2/branches/3.0@13288 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@13264 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@13256 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@13228 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
roll happened; should help with #5047.
git-svn-id: svn://localhost/ardour2/branches/3.0@13158 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
reset the default speed to 1.0 (and nothing else). hacky, could probably use Session::request_reset_default_transport_speed()
git-svn-id: svn://localhost/ardour2/branches/3.0@13087 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@13084 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
attention
git-svn-id: svn://localhost/ardour2/branches/3.0@13047 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
finished - write/touch passes do not correctly overwrite existing data because the semantics of ControlList::insert_iterator need clarification. more to follow
git-svn-id: svn://localhost/ardour2/branches/3.0@13038 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
I encountered this today writing a transport slave, but it seems to be the same
problem as issue #743 from 8 years ago. The issue is easier to see with a
transport slave client that prints any transport change whatsoever, for example
if the current location is some point well into the session and rewind to start
is pressed, Ardour reports the old position, not zero. With this change, it
reports zero as expected.
See comment about why this was happening. If locating here is evil for some
reason, then some other way of making jack_timebase_callback report the target
position is required. Contrary to what the old comment below this change
suggests, follow_slave() does not update _transport_frame in time.
git-svn-id: svn://localhost/ardour2/branches/3.0@12993 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
during roll.
git-svn-id: svn://localhost/ardour2/branches/3.0@12937 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
Session::start_transport() is called. Only the shuttle controller alters it, and even that only alters it in wheel mode, which means that stopping the transport does not rever the default speed back to zero. To get back to zero either switch the shuttle controller back to sprung mode, or change the speed back to zero (fixes #451 ... yes, really, a 3 digit bug fixed!)
git-svn-id: svn://localhost/ardour2/branches/3.0@12819 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
tidy-ups to related transport code
git-svn-id: svn://localhost/ardour2/branches/3.0@12818 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
are rendered accurately (#4213, #4593).
git-svn-id: svn://localhost/ardour2/branches/3.0@12801 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
being destroyed.
git-svn-id: svn://localhost/ardour2/branches/3.0@12722 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
It's slightly possible that this causes trivial build failures on different
configurations, but otherwise shouldn't cause any problems (i.e. no actual
changes other than include/naming/namespace stuff). I deliberately avoided
removing libardour-config.h since this can mysteriously break things, though a
few of those do seem to be unnecessary.
This commit only targets includes of ardour/*.h. There is also a very large
number of unnecessary includes of stuff in gtk2_ardour; tackling that should
also give a big improvement in build time when things are modified.
git-svn-id: svn://localhost/ardour2/branches/3.0@12420 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@11457 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
till *after* the new _transport_frame value has been set, so that we know when the clicks were accurately cleared
git-svn-id: svn://localhost/ardour2/branches/3.0@11327 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@11326 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
needed. this is a big commit, and breakage is possible. it has been moderately tested. this commit also locks the remote control ID of the master bus to 318 and the monitor section (if any) to 319. the numbers are based on MIDI Machine Control limits
git-svn-id: svn://localhost/ardour2/branches/3.0@11256 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@11018 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@10227 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
don't stop (#4213).
git-svn-id: svn://localhost/ardour2/branches/3.0@10074 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
recording and the corollary - no recording when varispeeding
git-svn-id: svn://localhost/ardour2/branches/3.0@9974 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@9971 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@9895 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
#4147.
git-svn-id: svn://localhost/ardour2/branches/3.0@9792 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
fault :D
git-svn-id: svn://localhost/ardour2/branches/3.0@9654 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
output ports can resolve any notes currently playing (2) remove MidiStateTracker from MidiPort and use a fixed set of MIDI messages (sustain-off and all-notes-off, per channel) to do note resolution (3) move note resolution caused by a LoopEvent psuedo-event to within the main MidiPort::flush_output() loop, so that we resolve (turn off) Notes that come before the loop point, rather than send them out after the note resolution messages
git-svn-id: svn://localhost/ardour2/branches/3.0@9635 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
TransportStateChange to keep GUI up to date when varispeeding
git-svn-id: svn://localhost/ardour2/branches/3.0@9500 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@9401 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@9387 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
alignment, and so on. still needs more tests of actual precise placement of newly recorded material
git-svn-id: svn://localhost/ardour2/branches/3.0@9155 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@9151 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@9149 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
alignment ... working except that we report the wrong information to JACK and i've noticed a couple of odd circumstances where turning on a latent plugin caused punch recording to fail
git-svn-id: svn://localhost/ardour2/branches/3.0@9121 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
worst_playback_latency() just about everywhere we were using worst_output_latency() - the former includes plugin latency. answer appears to break earlier fixes to alignment, but is semantically right, so plan to investigate in another 8 hours or so
git-svn-id: svn://localhost/ardour2/branches/3.0@9112 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
but require the right alignment setting, which doesn't persist correctly at present
git-svn-id: svn://localhost/ardour2/branches/3.0@9107 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@9098 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
(basically, they are always in "ardour does monitoring" mode
git-svn-id: svn://localhost/ardour2/branches/3.0@9081 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@8864 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
latency API
git-svn-id: svn://localhost/ardour2/branches/3.0@8863 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
speed of exactly 0 when they are really just continuously varying it. Fixes strange playhead behaviour during varispeed when the user varispeeds to exactly 0 and auto-return is triggered.
git-svn-id: svn://localhost/ardour2/branches/3.0@8733 d708f5d6-7413-0410-9779-e7cbd77b26cf
|