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
Previously, this calculation was based on the current transport frame and last
time, both absolute, with the effect that loop recording would flush the first
time and never again.
The fix is to keep track of the actual duration of the capture, ignoring the
transport position, and flush as that reaches the threshold.
git-svn-id: svn://localhost/ardour2/branches/3.0@13938 d708f5d6-7413-0410-9779-e7cbd77b26cf
Apologies for the noise, trying to dice a bunch of changes into reasonable commits...
git-svn-id: svn://localhost/ardour2/branches/3.0@13937 d708f5d6-7413-0410-9779-e7cbd77b26cf
Also make it work for pencil.
This is the canonical Ardour MIDI noob "I can't even create notes, this crap is
impossible to use or doesn't work at all" use case:
1) Create MIDI track
2) Click in that track, with object or pencil tool
3) ** A region is created ** - aha!
4) Click in that region, notes are created
Breaking step 3 ruins everything. Please don't.
git-svn-id: svn://localhost/ardour2/branches/3.0@13932 d708f5d6-7413-0410-9779-e7cbd77b26cf
Make midnam test suite pass again.
The Ardour test suite does not pass. I commented out old crossfade stuff, but
I am not familiar enough with the parts that fail to fix it. It might be a
good idea for someone to look into this. Ideally we'd have the test integrated
into everyone's workflow, but they add quite a few files to compile...
git-svn-id: svn://localhost/ardour2/branches/3.0@13931 d708f5d6-7413-0410-9779-e7cbd77b26cf
Completely eliminate static MIDI controller name code.
Reduce dependency on midnam_patch.h (which would have saved me several hours if I did it earlier).
Store controller name numbers as an integer.
Keep controller names in a map keyed by int instead of a list for fast lookup.
More cleanup of MIDI::Name code.
git-svn-id: svn://localhost/ardour2/branches/3.0@13927 d708f5d6-7413-0410-9779-e7cbd77b26cf
Colon seems most consistent, the separate space is to fix the spacing in the dialog while re-using the existing translation string 'New name:'.
git-svn-id: svn://localhost/ardour2/branches/3.0@13924 d708f5d6-7413-0410-9779-e7cbd77b26cf
Use const references where appropriate.
Fix incorrect use of (either confusingly named or often abused) Patch tag Number attribute.
git-svn-id: svn://localhost/ardour2/branches/3.0@13923 d708f5d6-7413-0410-9779-e7cbd77b26cf
This seems impossible, but it happens. Reproduction instructions:
1) Click in an empty portion of MIDI track to create a region
2) Add a CC lane
3) Click some points into lane (perhaps unnecessary)
4) Switch lane to linear mode (perhaps unnecessary)
5) Attempt to extend region leftward (with draw tool, but probaby doesn't matter)
6) Boom
Note trimming still doesn't work in this case and something seems deeply broken, but at least it doesn't crash now.
git-svn-id: svn://localhost/ardour2/branches/3.0@13922 d708f5d6-7413-0410-9779-e7cbd77b26cf
... I think. Not sure precisely, conditions were fuzzy, I just tortured my
mouse button until I could reproduce it.
git-svn-id: svn://localhost/ardour2/branches/3.0@13921 d708f5d6-7413-0410-9779-e7cbd77b26cf
I can't really make sense of this, they seem to be conflicting and of different origins, but I doubt it's worth my time to figure it out.
Also clean up the other one a bit.
git-svn-id: svn://localhost/ardour2/branches/3.0@13918 d708f5d6-7413-0410-9779-e7cbd77b26cf
The colour on the text doesn't seem to be what it should be, though. I think
Gtkmm2ext::convert_bgra_to_rgba might be broken...
git-svn-id: svn://localhost/ardour2/branches/3.0@13916 d708f5d6-7413-0410-9779-e7cbd77b26cf
Support loading note names per ChannelNameSet (like GM) in addition to per Patch (like DM5).
git-svn-id: svn://localhost/ardour2/branches/3.0@13913 d708f5d6-7413-0410-9779-e7cbd77b26cf
This fixes the note name displayed at a given time to be based on the correct program at that time, and not one in the future.
git-svn-id: svn://localhost/ardour2/branches/3.0@13912 d708f5d6-7413-0410-9779-e7cbd77b26cf
Do this via a simple MasterDeviceNames::note_name() function. The same really
needs to be done for program names, this stuff is absolutely brutal to use.
Store note names in a vector indexed by number instead of a list with string
"numbers" for reasonable lookup time.
Make some references const that should be.
git-svn-id: svn://localhost/ardour2/branches/3.0@13908 d708f5d6-7413-0410-9779-e7cbd77b26cf
