Though current_frame is an integral type (framepos_t), it was being
added to as if it were floating-point, leading to an ever-increasing
rounding error when creating the grid for bars/beats/ticks.
A large part of the packaging is shared in package.sh, this approach should
work on windows with another dll list in package-waves.sh and redefined
copydll function(which I've added untested as copydll-waves.sh)
Also add support for 64bit mingw builds via ARCH env variable. If unset
defaults to 32bit build
Newer versions of mingw-w64 can be built with an included pthread implementation
called winpthreads which uses an integer type for pthread_t but pthreads-win32 does
not.
Add a value for Ripple to EditMode enum.
Add Ripple edit mode to edit mode dropdown, by adding it to the
Editor::build_edit_mode_menu() helper function, and remove the old code that
added items to the (now unused) Editor::edit_mode_strings.
Add the regions that should be affected by the drag to RegionDrag::_views so
that the drag carries them along automatically.
Use a copy of the RegionList in Playlist::core_ripple(), since bad things
happen when iterating over regions and they get moved around in the list.
Handle rippling in removal of regions from playlist.
When dragging in ripple mode, exclude all regions that lie before the
original start position of the selected regions being dragged from
rippling: this is what Mixbus does.
Make editor dragging respect snap-to settings, by using the existing
compute_x_delta() function, which did almost the right thing. Move setting
of _last_frame_position out of that function so all ripple-dragged regions
can move.
Ripple when dragging from region list: even though Mixbus doesn't do this, it
seems like a good idea.
Prevent multi-track selection being dragged across tracks, by making
RegionMotionDrag::y_movement_allowed() virtual, and overriding it in
RegionRippleDrag to forbid dragging of selections containing regions on more
than one track to dofferent tracks in ripple mode.
Remember which TimeAxisView a ripple-mode drag that's allowed cross-track
drags started from, so that the effect of rippling regions after any region
that's dragged off that track can be undone.
When adding regions in splice mode, exclude the region being added from
possibly being shuffled. I don't know whether this might have some other
adverse effects, but it fixes an obvious defect in 'Splice' mode where
newly-recorded regions 'jump' to the playhead position when recording
stops, and since splice mode is pretty much broken anyway, I don't think it
can make matters any worse.
Move clear_changes() of the playlist on which a region has been dragged
before calling set_layer() on that playlist, so that undo of region drags
in layered mode undoes any layer changes too.
Should fix#5904
e.g. Audio in -> Midi out plugins (on an audio-track).
Midi-buffers do exist in the route but no corresponding
(physical) Input port-buffer exists and ardour crashed.
Now, the plugin itself still only accesses the mapped ports
(ChanMapping), but the mapped buffers are at most
"processor_max_streams" and at least the required
in+out buffers for the plugin.
Note that the following source files can be removed once we know this works on all platforms:-
backends/wavesaudio/wavesapi/akupara/threading/atomic_ops.hpp
backends/wavesaudio/wavesapi/akupara/threading/atomic_ops_gcc_x96.hpp
backends/wavesaudio/wavesapi/akupara/basics.hpp
backends/wavesaudio/wavesapi/akupara/compiletime_functions.hpp
(to accommodate the fact that in ptw-win32, 'pthread_t' is subtlely different from its non-Windows counterparts)
Conflicts:
libs/pbd/MSVCpbd/pbd.vcproj
Some users always want the same fade in/out style, e.g., constant power,
symmetric, fast etc.
To avoid having them change the fade style manually for each fade, use a
global configuration variable instead.
