On Windows, when opening a plugin editor, destroying the plugin
instance, and then creating a new instance and opening its editor, the
plugin would crash because the VBlankDispatcher singleton could not be
recreated.
The X42 stepseq.lv2 has an input atom port without the "control"
designation, but that still supports time:Position events. In order to
support this plugin, JUCE hosts will now send position info to any input
atom port that is marked as supporting this event type.
The host sync feature in stepseq.lv2 also requires the bar count to be
included in the position information.
Previously, activateBus would fail if the new BusesLayout wasn't
supported, as reported by isBusesLayoutSupported. However, according to
the VST3 docs, a host is allowed to enable and disable buses in any
combination, and the plugin should be able to handle this gracefully.
The ability to enable/disable individual buses without failure is
particularly important because there's no VST3 API to set a complete bus
layout in one go. That is, the only way to set all buses active or all
buses inactive is to set the appropriate state on each bus individually,
which in turn means that at some point, some buses will be active and
some will be inactive. Disallowing such 'intermediate' states may
prevent the host from putting the plugin into other (valid) states.
To ensure that the VST3 wrapper always accepts activateBus calls, it now
keeps track of the activation state of each bus as requested by the
host. When the host tries to change the activation state, the wrapper
will try to set the host's "ideal" bus layout on the AudioProcessor. If
this fails, the AudioProcessor will retain its previous bus layout.
The buffer remapping inside the process callback has been made more
robust, to handle cases where the host and the AudioProcessor disagree
about the activation state of each bus:
For input buses:
- If the host has activated the bus, but the AudioProcessor decided to
keep the bus inactive, the host's input will be ignored.
- If the host deactivated the bus, but the AudioProcessor wanted to keep
the bus active, the AudioProcessor will be provided with silence on
that bus.
For output buses:
- If the host has activated the bus, but the AudioProcessor decided to
keep the bus inactive, the wrapper will clear the host's output
bus buffers.
- If the host deactivated the bus, but the AudioProcessor wanted to keep
the bus active, the AudioProcessor's output on that bus will be
ignored.
The AudioBuffer passed to the wrapped AudioProcessor will no longer
contain any pointers from the host's ProcessData. Instead, the host's
inputs will be copied (in JUCE channel order) to a temporary buffer,
and this temporary buffer will be passed to
AudioProcessor::processBlock. After processBlock, the buffer contents
will be copied to the host's output buffers.
This change is intended to avoid a potential issue when reordering
channels into JUCE order, which may necessitate copying a host input
channel to a different host output channel. In the case that the host is
using the same buffers for both inputs and outputs, copying an input to
an output channel may end up overwriting another input channel, breaking
the plugin's inputs.
The TextHolderComponent and Viewport::componentHolder don't have any
accessible semantics, so they shouldn't be included in the accessible
component hierarchy.
Previously, when navigating in a text editor by words, the cursor would
get 'stuck' after moving a single word. This issue should now be
resolved.
Additionally, the cursor position was not updated properly when
adjusting a selection, and would instead be moved to the end of the
selected range. With this patch applied, the cursor should now be set to
the correct position when modifying selections. When extending a
selection backwards, the cursor will display at the beginning of the
selected range, rather than the end.
Finally, most Android apps announce the 'skipped' characters or words
whenever the cursor is moved, but this feature was broken in JUCE. This
patch enables this feature.
Previously, activateBus would fail if the new BusesLayout wasn't
supported, as reported by isBusesLayoutSupported. However, according to
the VST3 docs, a host is allowed to enable and disable buses in any
combination, and the plugin should be able to handle this gracefully.
The ability to enable/disable individual buses without failure is
particularly important because there's no VST3 API to set a complete bus
layout in one go. That is, the only way to set all buses active or all
buses inactive is to set the appropriate state on each bus individually,
which in turn means that at some point, some buses will be active and
some will be inactive. Disallowing such 'intermediate' states may
prevent the host from putting the plugin into other (valid) states.
To ensure that the VST3 wrapper always accepts activateBus calls, it now
keeps track of the activation state of each bus as requested by the
host. When the host tries to change the activation state, the wrapper
will try to set the host's "ideal" bus layout on the AudioProcessor. If
this fails, the AudioProcessor will retain its previous bus layout.
The buffer remapping inside the process callback has been made more
robust, to handle cases where the host and the AudioProcessor disagree
about the activation state of each bus:
For input buses:
- If the host has activated the bus, but the AudioProcessor decided to
keep the bus inactive, the host's input will be ignored.
- If the host deactivated the bus, but the AudioProcessor wanted to keep
the bus active, the AudioProcessor will be provided with silence on
that bus.
For output buses:
- If the host has activated the bus, but the AudioProcessor decided to
keep the bus inactive, the wrapper will clear the host's output
bus buffers.
- If the host deactivated the bus, but the AudioProcessor wanted to keep
the bus active, the AudioProcessor's output on that bus will be
ignored.
The AudioBuffer passed to the wrapped AudioProcessor will no longer
contain any pointers from the host's ProcessData. Instead, the host's
inputs will be copied (in JUCE channel order) to a temporary buffer,
and this temporary buffer will be passed to
AudioProcessor::processBlock. After processBlock, the buffer contents
will be copied to the host's output buffers.
This change is intended to avoid a potential issue when reordering
channels into JUCE order, which may necessitate copying a host input
channel to a different host output channel. In the case that the host is
using the same buffers for both inputs and outputs, copying an input to
an output channel may end up overwriting another input channel, breaking
the plugin's inputs.
The TextHolderComponent and Viewport::componentHolder don't have any
accessible semantics, so they shouldn't be included in the accessible
component hierarchy.
Previously, when navigating in a text editor by words, the cursor would
get 'stuck' after moving a single word. This issue should now be
resolved.
Additionally, the cursor position was not updated properly when
adjusting a selection, and would instead be moved to the end of the
selected range. With this patch applied, the cursor should now be set to
the correct position when modifying selections. When extending a
selection backwards, the cursor will display at the beginning of the
selected range, rather than the end.
Finally, most Android apps announce the 'skipped' characters or words
whenever the cursor is moved, but this feature was broken in JUCE. This
patch enables this feature.
This change fixes an issue where the touch keyboard failed to show when
selecting a TextEditor.
On the current versions of Windows 10 and 11, the undocumented
ITipInvocation workaround no longer seems to be required, so it has been
removed.
The isTabletModeActivatedForWindow function is no longer needed, and has
been removed. This function also appears to return inconsistent results:
the window may be in 'desktop mode', but devices with touchscreens
should still display the keyboard when selecting a TextEditor by touch.
Previously, individual components had to ask the peer to hide and show
the keyboard, by calling textInputRequired() and
dismissPendingTextInput() respectively. When an onscreen keyboard (OSK)
was required, most Peer implementation would directly hide/show the OSK
inside these function. However, the iOS ComponentPeer implementation
instead listened to the application's global keyboard focus, and only
opened the OSK when the focused component was also a TextInputTarget
with active input.
The iOS scheme seems like a better design, as it enforces that the OSK
hiding and showing is synced with the keyboard focus of the application.
In the other implementations, it was possible for a Component to call
textInputRequired even when it didn't have the keyboard focus, putting
the application into an inconsistent state. The iOS scheme also makes
the TextInputTarget interface more useful, as it enforces that the OSK
will only display for components that implement TextInputTarget, and
return true from isTextInputActive().
This patch changes all Peer implementations to match the iOS
implementation, improving consistency. Each time the global keyboard
focus changes, refreshTextInputTarget is called automatically, and the
OSK is shown if the focused component is a TextInputTarget that returns
true from isTextInputActive, and hidden otherwise. Components can also
call refreshTextInputTarget manually. This should be done whenever the
component updates the return value of isTextInputActive(). Effectively,
the Peer is now responsible for keeping track of the focused
TextInputTarget, rather than allowing individual components to hide and
show the OSK at will.
Additionally, this patch adds an option to the TextEditor to
automatically dismiss the OSK when the mouse is clicked outside of the
editor. This should improve user experience on mobile platforms, where
touches on sibling components may cause a TextEditor to gain keyboard
focus and unnecessarily display the OSK.
This change fixes an issue where the touch keyboard failed to show when
selecting a TextEditor.
On the current versions of Windows 10 and 11, the undocumented
ITipInvocation workaround no longer seems to be required, so it has been
removed.
The isTabletModeActivatedForWindow function is no longer needed, and has
been removed. This function also appears to return inconsistent results:
the window may be in 'desktop mode', but devices with touchscreens
should still display the keyboard when selecting a TextEditor by touch.
Previously, individual components had to ask the peer to hide and show
the keyboard, by calling textInputRequired() and
dismissPendingTextInput() respectively. When an onscreen keyboard (OSK)
was required, most Peer implementation would directly hide/show the OSK
inside these function. However, the iOS ComponentPeer implementation
instead listened to the application's global keyboard focus, and only
opened the OSK when the focused component was also a TextInputTarget
with active input.
The iOS scheme seems like a better design, as it enforces that the OSK
hiding and showing is synced with the keyboard focus of the application.
In the other implementations, it was possible for a Component to call
textInputRequired even when it didn't have the keyboard focus, putting
the application into an inconsistent state. The iOS scheme also makes
the TextInputTarget interface more useful, as it enforces that the OSK
will only display for components that implement TextInputTarget, and
return true from isTextInputActive().
This patch changes all Peer implementations to match the iOS
implementation, improving consistency. Each time the global keyboard
focus changes, refreshTextInputTarget is called automatically, and the
OSK is shown if the focused component is a TextInputTarget that returns
true from isTextInputActive, and hidden otherwise. Components can also
call refreshTextInputTarget manually. This should be done whenever the
component updates the return value of isTextInputActive(). Effectively,
the Peer is now responsible for keeping track of the focused
TextInputTarget, rather than allowing individual components to hide and
show the OSK at will.
Additionally, this patch adds an option to the TextEditor to
automatically dismiss the OSK when the mouse is clicked outside of the
editor. This should improve user experience on mobile platforms, where
touches on sibling components may cause a TextEditor to gain keyboard
focus and unnecessarily display the OSK.
reuk
attila
Tom Poole