bf28ecfc4c
fix enum registration for key enforcement policy (it's a bitmask)
2021-11-18 14:16:37 -07:00
9f4bf02980
change type of MidiTrack's key enforcement to new enum type
2021-11-18 11:16:50 -07:00
987c4de725
extend set of key enforcement policy flags
2021-11-18 11:13:29 -07:00
ae8c755d51
add new KeyEnforcementPolicy enum type
2021-11-18 11:00:00 -07:00
1793c9a61a
add new properties for musical mode & root
2021-11-18 08:30:46 -07:00
9f76d688fd
provide missing implementations for MidiTrack key API
2021-11-18 08:30:46 -07:00
1555896d8e
Extend API for MusicalMode and MusicalScale to expose mode type as a member
2021-11-18 08:30:46 -07:00
55a0aadc74
Modify ParameterDescriptor::midi_note_name() to offer chance to get a non-octave-version
2021-11-18 08:30:45 -07:00
7f88c71bd3
implement MusicalKey::in_key()
...
Limited to 12 tones per octave for now
2021-11-18 08:30:45 -07:00
fb7dd71c45
add default key and boolean to define whether or not to enforce it
2021-11-18 08:30:45 -07:00
4801f488c5
reflect name change in files
2021-11-18 08:30:45 -07:00
a7907d9e99
reflect rename in libs/ardour/wscript
2021-11-18 08:30:45 -07:00
46242a0079
rename scale to key
...
Scale is just a silly biased overly limiting name for Mode, so use
Key for "Mode + Root"
2021-11-18 08:30:45 -07:00
b4d6b888bb
initial data structure for musical scales (derived from mode)
...
This is built around a MIDI-like assumption that we have a fixed (integer) number of
note IDs and a semitone between them. We will need to expand this definition in the
future to handle Bohlen-Pierce, maqams and various other non-12TET scale systems
2021-11-18 08:30:45 -07:00
5ba6e14310
triggerbox: catch a very strange condition via abort(), to help with debugging.
...
Not easily reproducable, but definitely a bug somewhere.
2021-11-17 21:16:38 -07:00
ddf93aca19
triggerbox: make a somewhat half-baked attempt to resync a trigger that ended too early.
...
Instead of just restarting it inside the same ::run() call, mark it as waiting,
so that it will restart at the next quantization point.
This isn't a final or even fully correct solution, but it's a useful test of
the idea.
2021-11-17 21:14:56 -07:00
6e404ea7bf
tempomap: reimplement TempoMap::bbt_walk()
...
This still needs work to deal correctly with negative (backwards/earlier)
walks.
2021-11-17 15:59:03 -07:00
b1b5553d1d
tempomap: allow access to TempoMap::bbt_at () variant
2021-11-17 15:58:33 -07:00
fcf0c253ad
control surface changes to follow TempoMap::sample_at() API change
2021-11-17 15:57:54 -07:00
c24cabead0
GUI changes to follow TempoMap::sample_at() API changes
2021-11-17 15:57:30 -07:00
2aefb472e2
temporal: change API of TempoMap::sample_at() to not require an explicit sample rate
...
We have a mechanism to get the engine sample rate and use that widely. We
should use it here also.
2021-11-17 15:56:06 -07:00
3c9bebda00
remove debug output
2021-11-17 12:16:39 -07:00
180c1d7759
tempo map: slight reorganization of ::get_grid
...
This avoids resetting beats based on superclocks in case where we
already do the opposite.
2021-11-17 12:16:39 -07:00
7dbf2445f5
tempo map: NOOP: expand comment to explain more
2021-11-17 12:16:39 -07:00
a5ccb521e6
tempo map: NOOP helpful comment, perhaps
2021-11-17 12:16:39 -07:00
73c87064a5
tempo map: NOOP correct comment text
2021-11-17 12:16:39 -07:00
c7adea3ec0
tempo map: really no-op code change to provide another useless compiler const hint
2021-11-17 12:16:39 -07:00
d9b1d2ccc8
temporal: NOOP add helpful comment about bar_mod argument
2021-11-17 12:16:39 -07:00
b3451f4055
tempo map: fix computation of superclocks_per_note_type_at()
...
Code used position as an absolute, rather than offset from the point
that defines tempo. It worked if the point was at zero, but not
otherwise.
2021-11-17 12:16:39 -07:00
a417cbae4b
tempo map: fix a potential bug (not seen in the wild) when generating the grid
...
the "p" variable could point to _points.end(), so we cannot indirect and use
p->sclock() value unconditionally.
2021-11-17 12:16:39 -07:00
1ba2e28d6f
tempo map: fix grid generation with ramped tempos
...
The old code used the instantaneous tempo at T0 to compute where the next
quarter note would be. This is incorrect, since the tempo is
changing (continuously, for now) during the time represented by that quarter
note. Instead, we need to add a quarter note (or technically, whatever the
tempo note type is) to get a new position in beats, then compute the superclock
time at that location (which will use our equations for tempo, including the
use of omega, the ramp factor).
2021-11-17 12:16:39 -07:00
8972ed1517
temporal: add Tempo::note_type_as_beats()
2021-11-17 12:16:39 -07:00
7edcda4fc1
temporal: logic fixes for several tempo map modification methods
2021-11-17 12:16:39 -07:00
d61fc1e871
triggerbox: add passthru property to control input passthrough (monitoring)
2021-11-17 12:16:39 -07:00
1fb8779361
delete/cancel triggerbox worker thread at exit
2021-11-17 12:16:39 -07:00
1532ebb38f
temporal: truncate ::to_string() method for timeline types to ::str() for easier use in debugger
2021-11-17 12:16:38 -07:00
4fe1fec54e
when setting a default audio region envelope, coerce the endpoint to AudioTime
...
Comment in code explains more
2021-11-17 12:16:38 -07:00
7a12458244
temporal: improve implementation of TempoMap::meter_at() and more templating
...
Needed to move template defns around to ensure that required instances are defined
2021-11-17 12:16:38 -07:00
4128088b70
temporal: TempoMap::tempo_at() ... templates FTW
2021-11-17 12:16:38 -07:00
fb2281129a
temporal: add clarifying comments to TempoMap::remove_*()
...
These comments should correct an impression left in the commit message for
6e9e28343bc3695d that there may be some sort of problem with synchronization
of TempoMap changes. The actual problem is that TempoMap edits are done using
RCU, so the modifications are performaned using a copy of the map, but with
map elements taken from the pre-copy version.
2021-11-17 12:16:38 -07:00
b67965f499
temporal: add the entire _points list to output of TempoMap::dump()
2021-11-17 12:16:38 -07:00
8a59f3fe8e
temporal: fix issue with removal of tempo, meter and bartime points
...
The correct algorithm is to traverse the type-specific list of points,
find the point (if any) whose time matches that of the argument (because
we do not allow multiple points of the same type at the same time), and
then use that discovered point from the _points list.
This approach is required because the actual argument may no longer be
in the tempo map (due to a change made by another thread). The lack of
sync, however, needs investigation.
2021-11-17 12:16:38 -07:00
4d5cf43789
triggerbox: use correct API to track tempo
2021-11-17 12:16:38 -07:00
5b5ca546e0
temporal: fix incorrect implementation of TempoMap::tempo_map()
...
std::lower_bound() is not appropriate here. We need to find the first
TempoPoint after the given time, then return the one before that.
2021-11-17 12:16:38 -07:00
e7e44351cc
temporal: move implementation of quarters_per_minute_at() into .cc file
2021-11-17 12:16:38 -07:00
a0e134e1b3
temporal: update comment on a method that suggest not using it; provide TempoMap::quarters_per_minute_at ()
2021-11-17 12:16:38 -07:00
4f3bf37680
temporal: implement a faster method to lookup TempoPoint
...
There is no reason to build a TempoMetric if you only need the Tempo
2021-11-17 12:16:38 -07:00
5105083394
triggerbox: first pass at using "realtime" rubberband rather than pre-stretch
2021-11-17 12:16:38 -07:00
e1b2a24221
Fix error message (include plugin ID)
2021-11-17 18:46:29 +01:00
83225886a1
Fix gcc4 builds ('EEXIST' was not declared in this scope)
2021-11-15 19:12:00 +01:00
