| Age | Commit message (Collapse) | Author |
|---|
|
- don't alter region frame length on tempo change or position change.
- set region _start correctly (see comments) on tempo map change.
- ensure audio-locked region's beat is set on tempo map change
|
|
A spurious space change was included by mistake.
|
|
The trim processor was moved to the front after the internal return was,
so the trim setting was applied before the signal coming from other
tracks/busses sends was mixed in. Change the order so that trim applies
to audio from internal sends as well.
|
|
To export a MIDI region to a file, the code used MidiRegion::clone()
since it takes care of creating a new file-backed source with the wanted
contents. Nevertheless, it had several side-effects:
- it created and registered a new region which is confusing to users
- it only exported notes that were in the region range, but didn't
remove the region start offset from MIDI events, essentially producing
a spurious silence at the beginning of the exported file (this is not
a problem for region cloning because the newly created region is made
aware of the offset and caters for it).
Add a dedicated code path for export, that uses the new offsetting
capabilities of MidiModel::write_section_to().
|
|
|
|
this simplifies lua-bindings and also let's the compiler worry about
constant primitive types.
|
|
- seems to work quite well, but not tested on live recording.
|
|
|
|
trim.
|
|
rounding.
|
|
length regions from drawing tool.
|
|
|
|
tempo dilation
|
|
ctor.
|
|
- for those not in the know, this series provides a way to
remove the temporal distortion introduced when using an
audio frame-based gui for music-locked objects.
In short, the gui uses an audio frame representation to move
objects. It displays the object using frame_at_beat(), quantizing
the time value to audio frames. This is fine until the user selects
that frame but expects it to be interpreted as a beat.
Thus beat_at_frame() would not produce the user-expected beat
(temporal quantization error of up to 0.5 audio samples).
This is one method of mapping audio time to music time accurately.
|
|
- use exact beats to determine frame position.
- see comments in tempo.cc for more.
- this hasn't been done for split yet, but dragging and
trimming are supported.
|
|
|
|
- hopefully this can close bugs such as 6270 & 6793
|
|
- fixes incorrect length on drag-copying and pasting
midi regions.
|
|
- there is still the problem of being unable to drag
a trimmed region to the left when it's source
(not it's position) would end up on a negative beat.
|
|
|
|
- should fix 6793
|
|
|
|
|
|
|
|
This moves MIDI channel filtering into a reusable class and moves filtering to
the source, rather than modifying the buffer afterwards. This is necessary so
that the playlist trackers reflect the emitted notes (and thus are able to stop
them in situations like mute).
As a perk, this is also faster because events are just dropped on read, rather
than pushed into a buffer then later removed (which is very slow).
Really hammering on mute or solo still seems to produce stuck notes
occasionally (perhaps related to multiple-on warnings). I am not yet sure why,
but occasional beats always.
|
|
This avoids stuck notes if active notes are edited, but without stopping all
active notes in the region on any edit as before.
This implementation injects note ons in places that aren't actually note
starts. Depending on how percussive the instrument is, this may not be
desired. In the future, an option for this would be an improvement, but there
are other places where "start notes in the middle" is a reasonable option. I
think that should be handled universally if we're to do it at all, so not
considering it a part of this fix for now.
|
|
|
|
Firing these signals while locked is not a good idea, Sequence/ControlList need
a better design for this that accounts for recording and lockedness.
|
|
|
|
|
|
This is a little hard-edged in that edits while rolling will prematurely chop
off any playing notes, but at least the state of things actually reflects
reality. More sophisticated solution hopefully to come...
|
|
Attempt to make mistakes much less likely in the future by statically requiring
caller to pass scoped locks where necessary.
|
|
This lets us get a more explicit handle on time conversions, and is the main
step towards using actual beat:tick time and getting away from floating point
precision problems.
|
|
Fix initial read of discrete MIDI controllers.
Fix spurious note offs when starting to play in the middle of a note.
Faster search for initial event when cached iterator is invalid.
So much for dropping the cached iterator. The iterator is responsible for
handling note offs, so that doesn't work. This design means we have some stuck
note issues at the source read level, but they should be taken care of by the
state tracker anyway.
|
|
I am not precisely sure why the cached iterator was causing this problem, it
shouldn't be invalidated, and the times make sense. It may be some lock
related issue since the iterator holds a lock on the source.
In any case, this cached iterator was just to avoid repeated linear search of
the model, but since the model has a logarithmic search, instead just scrap all
this problematic persistent state and search for the appropriate start time
every read. No need to be careful about invalidating when anything changes.
|
|
|
|
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.
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@13084 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@12840 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@12627 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@12401 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
reset _start_beats with _start on MidiRegion::fix_negative_start(). May help with #4736.
git-svn-id: svn://localhost/ardour2/branches/3.0@11984 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@11289 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
even if there is no capture data to process; side effects: remove unused MidiBuffer::merge() and add DEBUG::MidiTrackers as well as more and better MIDI debug tracing facilities
git-svn-id: svn://localhost/ardour2/branches/3.0@11057 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@11015 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
to BBT; fixes part of #4257.
git-svn-id: svn://localhost/ardour2/branches/3.0@10986 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
match the source, so that starts are not corrupted when
tempos change (#4494).
git-svn-id: svn://localhost/ardour2/branches/3.0@10976 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@10300 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
