Often one needs to make sure that all the relevant settings are made
before one actually starts recording. The Lua interface can take care of
this task easily, that the operater by just one action can make sure
that the relevant settings (e.g. recenables, playhead position, etc.)
are ready for recording. This example was written with a quasi live
podcast scenario in mind.
See `scripts/prepare_record_example.lua` for details.
Clearing location markers is a frequent task and should be automizable. For
example it is handy to clear all the markers when restarting the recording
from scratch after a failed recording.
There were two issues:
The first is that TrimDrag::aborted was calling TrimDrag::finished with a null
GdkEvent which caused a segfault when dereferencing. So avoid that by passing
in a dummy event as we are just going to undo the operation in the next step
anyway so it shouldn't matter if it is valid(AFAICT).
The other is that TrimDrag:aborted was calling Editor::undo() which was in turn
calling TrimDrag::aborted leading to infinite recursion and stack overflow.
Calling Session::undo() directly seems to avoid that issue.
This fix feels like a bit of a hack...but it seems to work and is better than a
crash.
If a Session is saved and then the start or end session markers are moved,
closing the Session will not result in "Unsaved Session" dialog being presented
even though the Session has been modified. This change sets the Session as
modified when either the Session start or end markers are modified.
This commit changes item "gtk_bases" from light (color22) to darker (color88). The knob of "Enable/Disable MIDI input" in Edit List had the same colour and was not visible. This commit makes it clear visible, and it has no much influence on a general design.
- after reports that a tempo with non-4.0 note type
would produce a ramp in the preceding section, an incorrect
assumption was made leading to a bogus 'fix' that redefined
Tempo's pulses_per_minute().
the real fix was simple:
the ramp's function constant was calculated using the note type
of the proceding tempo rather than the current one.
- this patch reverts e82482e8e9 and a4d67279e0
and maintains the old definition of Tempo::pulses_per_minute()
It seems that 'strftime()' (on Windows) works differently from its non-Windows counterparts. Specifically, some formatting options (e.g. %F) are not recognised in the Windows implementation.
Fortunately, glibmm comes to our rescue here! So let's use the glib implementation which will hopefully work the same on all platforms.
