The new enum causes sessions made with this version to "crash" older
versions.
ifdef out Wallclock TM and add an enum hack_table entry. Versions compiled
this way will be compatiable when Wallclock gets turned back on at a later
time.
The reader lock was added during probe to a cure rare crash that happened
when the control protocol info was in the process of being deleted while
probe was running.
This does not work because if automatic device activation is on and a
device with this ability is found (FaderPort), the activate/deactivate
calls from here will try to take the Write lock and trigger a deadlock.
This code is in the process of being reworked as part of a feature branch,
so apply a band-aid for now. Drop the lock before calling
activate/deactivate
NOP for Ardour.
Other products us a transparent logo image which leaves
the splash window the same color as the application background. That
makes the splash window have no delineation once the main up comes up.
On Windows this can take many seconds and in error cases, minutes. Collect
some more infomation on how long this takes on various systems and
also tell the user what is going on.
On some Windows systems, detecting audio/MIDI devices can take a long time.
If something goes wrong, it can take minutes. This can leave the user
in the dark since nothing appears on the screen to confirm that the
program is running.
While other OSes don't have this problem, it seems like acknowledging
that we are running as early as possible is a good thing.
Opening a session using open-with or by double clicking the session
file in the system file browser would crash (abort). Starting
the program first and then opening the session file worked.
The abort was deep in gtk when it failed to create threads for
async operations (g_task_thread_pool_init). The failure was
due trying to create new threads with a priority that matched
the caller. In this case the caller was running with elevated
priority and the thread creation would fail.
The elevation of priority for the main thread happend during the engine
start process. Code in the MIDI input device callback was elevating the
priority of the thread that called the callback the first time. midiInOpen
calls the callback function with MIM_OPEN as part of the windows
MIDI open call. This meant that the main thread was being elevalted.
at ../libs/backends/portaudio/winmmemidi_input_device.cc:224
at ../libs/backends/portaudio/winmmemidi_input_device.cc:80
The main thread should not be running with elevalted priority and when
MIDI data is sent the callback is called from a windows driver thread.
We should not attempt to adjust the priority, so this code was removed.
During normal startup, the New Session dialog triggers the gtk filesystem
worker threads and since this was before the audio engine started
the prioriy had not been elevated yet and everyting worked fine.
If the system had no MIDI ports, this code was never executed and
open-with worked fine
During a normal startup (with MIDI) the main thread would get set
to Class normal, Priority 17. If buffered IO was used in the audio
MIDI setup, the main thread would be Class high, Priority 12.
For ardev to work on windows (msys) the enviroment variable for the
DLL path needs to be used.
Without this, ardour fails to find the VST(3) scanner programs.
For example, the following log text creates a markup error that results in
the session loading dialog being completely empty.
WARNING: VST3<C:\Program Files\Common Files\VST3\Plugins.VST.Someplugin.vst3\Contents\x86-win\Plugins.VST.Someplugin.vst3>: Invalid Module Path
...
Gtk-WARNING **: 16:46:28.447: Failed to set text from markup due to error parsing markup: Error on line 7 char 40: ?Files\Common? is not a valid name: ?\?
With no clear reason why, copying the program to the dmg is running
out of space. Possibly a bug in latest catalina.
Instead of using a fixed extra space amount. Add 25% of the Product Dir
size to the dmg size.
Only enable the master display and meter modes for Qcon devices if this
surface is in the master position. Extenders don't have master meters
or master displays.
Logic to detect an extender has to be based on if this surface object is
the master position. Has master fader is true for all surfaces in this
"device".
Old and new strings are compared before sending to keep traffic down. To
ensure that we send all the required characters be sure to init the last
value to characters that are never going to appear in a real string.
Space is a bad choice since it is a valid character. Use NUL instead.
The device info file allows key names and values to be configured in each
device file. Use that information when building the Functions Keys tab in
the Mackie protocol setup dialog.
While surfaces are being created it is possible to have surfaces, but
not have a master surface yet. This happens when the config calls
for extenders to the left of the master section. Don't assume that
if we have surfaces, the master surface is available.
If there are multiple connections, one might fail due to missing hardware,
but the rest could still be valid.
An easy way to reproduce this was to route "mackie control out" to a device
and to the Midi tracer port. When you opened the session again, connection
from the "mackie control out" to the device would not get restored because
the Midi tracer port does not exist at session start.
This most likely caused other issues with connections when changing backends.
Mackie surfaces use a special peak meter type that returns the maximum
peak for all channels in the strip. The issue was that the implementation
of this meter did not follow the falloff the other peak meters. If a real
peak meter and a combined peak meter were displayed on the surface at the
same time the missing falloff was obvious.
Don't calculate the combined meter during run. Instead calculate it only
when needed based on the already existing individual peak meters.
Transport Masters and Async MIDI port already have a parser available, so
just connect to it.
Normal Midi ports are the only one that need to use the Midi Tracers parser.
Only basic midi ports use the _trace_parser and they enter
here via cycle_start which will pass the _trace_parser to
this function. No need to double up calls.
If the wrong device profile is selected (ex Xtouch One) but another device
is connected (Xtouch), it is possible to have a master fader on the
device, but not in the code. This would then cause a crash when the
master fader was touched.
This just protects from a wrong configuration.
It is not needed in the relative case and causes issues when taking
sessions between platforms.
On windows, the default path would be "\export". When that is used
on linux the resulting fullpath would end up as
/your/session/path/\export
which is then not found on the file system.
This change is consistent with how relative paths are normally written and
does cure the default path when moved across platforms.
It does not solve the larger issue of mixed directory separators.
A relative path of "export\myMixV1" will still fail when moving between
platforms.
To reproduce. Launch, right click in ruler area then drag down
until over the master track and let go.
#0 0x0000555555ba1d44 in boost::shared_ptr<ARDOUR::Route>::get() const (this=0x8) at /usr/include/boost/smart_ptr/shared_ptr.hpp:748
#1 0x0000555555ba0a2f in boost::dynamic_pointer_cast<ARDOUR::Track, ARDOUR::Route>(boost::shared_ptr<ARDOUR::Route> const&) (r=...)
at /usr/include/boost/smart_ptr/shared_ptr.hpp:904
#2 0x000055555650b92b in RouteUI::track() const (this=0x0) at ../gtk2_ardour/route_ui.cc:1885
#3 0x0000555555d0b92f in Editor::popup_track_context_menu(int, int, ItemType, bool) (this=
0x555557a3efd0, button=1, time=600214966, item_type=StreamItem, with_selection=false) at ../gtk2_ardour/editor.cc:1595
#4 0x0000555555e1a4cf in Editor::button_release_handler(ArdourCanvas::Item*, _GdkEvent*, ItemType) (this=0x555557a3efd0, item=
0x555557b2fe00, event=0x7fffffffc310, item_type=StreamItem) at ../gtk2_ardour/editor_mouse.cc:1543
....
If the file has a timestamp, it should be set in the region during import.
This keeps the BWF timestamp from being lost and allows the region context
menu item "Move to original Position" to work.
It does not affect where the region will be positioned during import. That
still follows the import dialog menu selection (playhead, session start,
etc). It just maintains data that the user can decided to use if needed.
This change also allows files to be imported to the source list and then
later placed on the timeline in the correct timestamped position.
This would crash (throw) if ardour was started with an invalid backend
(alsa with no devices avaliable) and then changec to an alredy running
jack. The invalid backend at the start would leave the buffer
size combo empty and switching to the running jack backend did not populate
buffer size list.
Creating a new empty group from the group tab area just looks broken since
nothing visible happens, so hide this item when the context menu is
triggered from this location.
Todd Naugle