| Age | Commit message (Collapse) | Author |
|---|
|
MidiSource XML nodes
|
|
|
|
|
|
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
|
|
|
|
|
|
(such as those held in a MidiPlaylist's RegionTrackers
|
|
|
|
- add more debugging output detecting regions whose
beat and frame position do not align on a playlist.
this is required as a check as we have never used
frame rounding on constant tempi before 8884a5723dc
|
|
Fixes the multiple reader issue #6541 properly without resorting to a
linear search kludge.
All the read state has been pulled out into a MidiCursor which the
caller is required to pass. The playlist keeps cursors for all the
regions it is reading, any number of cursors are allowed at a time.
MidiCursor should probably be made a smarter and more fool-proof
object (and/or possibly merged with some of the other tracker/fixer
stuff) but for now I wanted to keep it simple.
|
|
|
|
- we already have start_beats, so don't try to recalculate
something similar for the position comparison.
|
|
|
|
|
|
_length_pulse from MidiRegion.
- _start/length_beats are now quarter notes regardless
of loaded session version.
- also restores note colour update
|
|
seamless looping (if using)
|
|
- MidiSource _length_beats is in quarter notes.
Here we duplicate length_beats for backwards compatibility
|
|
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().
|
|
|
|
rounding.
|
|
|
|
|
|
A somewhat hacky solution to address missing note-off events when a
linked midi-region is used on separate tracks at the same time.
see the source-code comment for further info.
|
|
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.
|
|
|
|
|
|
This reverts commit ec947ff8fd2cf229284f757b8bd6b0f96cbd6383.
|
|
Locking should prevent this from being a problem, but taking a reference to the
cached iterator and mutating it directly causes occasional crashes for me for
reasons I can't quite figure out.
This fixes the issue and is arguably more sane anyway, so whatever.
|
|
Attempt to make mistakes much less likely in the future by statically requiring
caller to pass scoped locks where necessary.
|
|
I suspect this is an underlying cause of several tricky to reproduce bugs, but
we'll have to wait around and see...
|
|
Hopefully-desired behaviour is that controls created in the GUI are linear, so
clicking in stuff works like other automation, but controls that originated
from recording are set to discrete so Ardour plays back the input exactly,
instead of doing crazy things like linear interpolation of already high-rate
user input, hold pedals, and so on.
Hopefully that remains the desired behaviour, because we're basically screwed
for ever making any control discrete by default, since we only save the mode to
XML at all if it's not the default, which is currently linear.
|
|
Among other things, this means that automation controls/lists have the actual
min/max/normal/toggled of parameters, and not those inferred from the Parameter
ID, which is not correct for things like plugin parameters.
Pushing things down to the Evoral::ParmeterDescriptor may be useful in the
future to have lists do smarter things based on parameter range, but currently
I have just pushed down the above-mentioned currently used attributes.
|
|
This is not used anywhere in Evoral and is just a wrapper around the PBD
RingBuffer anyway. Towards a (once again?) independently buildable/testable
Evoral and fewer cross-dependencies.
|
|
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.
|
|
non-capture driven MIDI region creation operations).
See comments in Session::new_midi_source_name() for details.
|
|
reports about missing MIDI files on the forums and IRC
|
|
|
|
_origin is set, it means that the file is "external" to the session (aka "embedded") and for some purposes this is more significant than _file_is_new. rename SourceFactory::createReadable() to ::createExternal() to more clearly indicate its purpose; remove never-supplied "origin" argument from SourceFactor::createWritable(). Fixes problems caused by 864ce8f0
|
|
This changes how things work a bit, but I am committing it for 3.0 since the
previous revision often crashed (and never worked), this one seems to work
fine, and the code is quite a bit more cogent.
I have tested the following use cases with live input and audible output:
* Non-loop recording, armed before roll
* Non-loop recording, arm while rolling
* Loop recording, armed before roll
* Loop recording, arm during roll
In the last case, the source/region is created starting at the loop start
rather than the current transport frame as usual so time makes sense when it
wraps around.
See the documentation added to the code for details, but the basic idea here is
to simply push MIDI events to the source with increasing monotonic time,
ignoring looping altogether. Essentially we pretend the loop does not exist,
but the source knows all the details so it can implement whatever behaviour is
appropriate.
Currently, this is simply recording a complete non-destructive copy of the
input, which is a good thing. Perhaps not what the user expects of loop
recording, but at least it works and is one sensible option. We will need to
add more later.
Display while recording is a little bit wacky, but whatever.
git-svn-id: svn://localhost/ardour2/branches/3.0@13940 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
git-svn-id: svn://localhost/ardour2/branches/3.0@13939 d708f5d6-7413-0410-9779-e7cbd77b26cf
|
|
and fix const cast warnings generated by new flags
git-svn-id: svn://localhost/ardour2/branches/3.0@13124 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
|
|
pbd/file_utils.h and ardour/session_dir.h
git-svn-id: svn://localhost/ardour2/branches/3.0@12829 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
|
