Feature Requests

Description: Enable moving or copying widgets to another page without rebuilding —preserving size/position, styling, actions, variables, and MIDI/OSC mappings. Offer Linked Instance (mirror-style) and Independent Copy modes, plus a Relink Wizard to adapt targets on the destination page. Problem: Recreating widgets on a different page is slow and error-prone: mappings break, actions must be rebuilt, and layouts drift. Duplicating by hand also risks conflicts (double-mapped MIDI, wrong targets). Users need a fast, reliable way to reuse existing UI across pages. Proposed Solution: Commands: Move to Page… and Copy to Page… (multi-select supported). Instance Modes: - Linked Instance (Mirror): shares logic/actions/parameters with the source; optional per-instance visual overrides (color/label). - Independent Copy: full duplicate; all bindings cloned with safe remapping. Relink Wizard (context-aware): - Auto-map targets by name/tag/color (e.g., reroute to local tracks/clips/groups). - Resolve MIDI/OSC conflicts (offer remap, scope, or disable). - Report dependencies (missing buses, AUv3, pages) with one-click fixes or placeholders. Layout Preservation: keep coordinates, size, z-order, anchors ; optional scale to destination grid and “keep safe text size”. Bundles & Library: save/load Widget Bundles (with assets/fonts/icons) and drop them onto any page. Cross-Page Links: show a small link badge on mirrored widgets; jump to Master ; command Make Independent / Re-link to… . Assets: carry embedded images/genmoji; de-duplicate on paste; warn on large assets. Safety & Undo: single undo step; late-press guard for widgets that trigger transport; dry-run preview. Actions & API: Move/Copy Widget(s) to Page , Create Linked Instance , Make Independent , Run Relink Wizard , Select Destination Page , Replace on Destination . - Vars: widget.instanceId , widget.linkGroupId , widget.isLinked , widget.pageName . Benefits: Build complex UIs faster—reuse proven widgets across pages without rebuilding. Fewer mapping mistakes; consistent behavior via linked instances . Clean migrations when reorganizing shows or making “performer vs. FOH” pages. Portable widget packs for teams and templates. Examples: Copy a Transport strip to a “Performer View” as a Linked Instance so one edit updates both pages. Move a Fader bank to a new FOH page; the Relink Wizard retargets sends/pans on that page. Duplicate a Scene Grid as an Independent Copy for the MD; MIDI inputs are auto-remapped to a different controller. Save a Looper Controls bundle (buttons + meters) and drop it onto new projects with all actions intact. This summary was automatically generated by GPT-5 Thinking on 2025-11-04. Original Post: Ability to Move Widgets to another page (without rebuilding after copying) Currently copying is the only options but it does not reserve and bindings or most of the linkings / connections of copied widget / Clips.

Description: Add a true dual-screen workflow where the iPad shows a Control Canvas (editing, buttons, faders) while an external monitor shows an Independent Stage Display (clips, big meters, lyrics/teleprompter, flashing BPM, scene cues). Support Mirror or Extended modes, per-screen pages/layouts, and one-tap actions to send widgets/pages to the external screen. Problem: With an external monitor attached, performers typically get mirroring or a single shared UI. This limits stage use (audience/camera view, MD screen, confidence monitor) and forces page switching during shows. Users need separate, purpose-built layouts on each screen—without rebuilding projects or compromising touch control on the iPad. Proposed Solution: Screen Modes - Mirror (current behavior) or Extended ( Control Canvas on iPad, Stage Display on external). - Per-project default mode ; quick toggle in the title bar. Per-Screen Pages & Layouts - Assign any Page to Screen A (iPad) or Screen B (External) ; optional Follow Page rules (e.g., external follows the selected group/scene). - Screen-Only Widgets (e.g., fullscreen clip grid, lyrics/ChordPro, flashing BPM, big clocks/meters) that don’t appear on the iPad. - PiP support to embed a region of one page into the other screen. Placement & Styling - Resolution-aware layout with Fit/Cover/Pixel-perfect scaling, safe margins/overscan controls, and min text size guards. - Brightness cap / Night mode , theme overrides, and “high-contrast stage” preset. Interaction & Safety - iPad remains the sole touch surface ; optional pointer control for external focus switching. - Performance-Safe mode (frame-rate throttle, reduced animations) for the external output. - Privacy filter prevents edit overlays or dialogs from appearing on the stage screen. Routing & Sync - Transport/tempo/scene are shared; screen-specific quantize for visual cues (downbeat flash, lyric advance). - Optional Program/Preview pair: preview next page/scene on external, Swap on cue. Actions & Variables - Actions: Set Screen Mode (Mirror/Extended) , Show Page on Screen (A/B) , Send Widget to Screen B (Fullscreen/Panel) , Swap Screens , Toggle Stage Display Preset , Set External Brightness/Theme . - Vars: screen.mode , screen.external.resolution , screen.external.fps , screen.external.isSafeMode , page.screen . Presets & Export - Save Stage Display presets (e.g., “Clips+Meters”, “Lyrics+Timer”); recall per setlist item. - External screen respects Genmoji , pictograms, and large-type fonts. Benefits: Run two optimized UIs at once : hands-on control on iPad, clear stage/audience view externally. Fewer page switches and safer shows with persistent meters/lyrics/cues. Camera- and FOH-friendly output (contrast, margins, brightness). Reusable presets speed setup across projects and venues. Examples: iPad shows your Control Canvas ; the HDMI screen shows Lyrics + Big BPM + Scene Countdown with high contrast. A Program/Preview layout on the external display previews the next scene; tap Swap at the bar boundary. Send a Fullscreen Clip Grid to Screen B while keeping detailed faders/FX on iPad; PiP a small Master meter back onto the iPad. For theatre, recall the “Confidence Monitor” preset (clock, next cue, current bar:beat, transport state) on the external screen. This summary was automatically generated by GPT-5 Thinking on 2025-11-04. Original Post: Loopy Pro working with two screens at the same time (Ipad and external screen) If i have my ipad conected via hdmi to second display, create and option so when I open an app AUv3 within Loopy Pro, I can view it on that second display while the Loopy Pro homepage remains active and visible in the screen option. This way i can have windows open on secondary/external screens as other apps have as VS Visual Synthesizer This way, I can use both options and screens at the same time. This is VERY usefull for working with Loopy pro.

Description: Allow duplicated/cloned AUv3 effect instances to have individually controllable bypass states, with a setting to choose between the current linked behavior (all clones toggle together) and independent control per instance. Provide fine-grained link options (bypass vs. parameters vs. presets) and clear UI to manage clone groups. Problem: Today, cloned instances typically share bypass —handy for global on/off, but it blocks A/B/C comparisons, per-branch mutes in parallel chains, scene-specific toggles, and CPU saving on a single instance. Users resort to duplicate chains or complex macros to emulate per-instance control. Proposed Solution: Link Modes (per clone group / per instance): - Linked (current): Bypass & parameters mirror the source. - Independent Bypass: Parameters may stay linked; bypass is per instance . - Fully Independent: Bypass and parameters are per instance. - Custom Links: Separate checkboxes: Bypass , Parameters , Preset , MIDI Map (choose what is linked). Controls & UI: - Clone Group badge (A/B/C…) with a quick “Link Bypass” toggle. - Per-instance Bypass , Solo , Mute (pre/post) buttons in the AU frame/title bar. - Context menu: Duplicate (Linked) / Duplicate (Independent) , Make Independent , Link to Group… - Visual indicator when an instance is bypass-linked (chain icon). Actions & Variables: - Actions: AUv3 → Toggle Bypass (This Instance) , Set Bypass (Group) , Link/Unlink Bypass , Link/Unlink Parameters , Duplicate as Independent/Linked , Solo Instance , Bypass Others in Group . - Vars: au.instanceId , au.groupId , au.isBypassed , au.link.bypass , au.link.params , au.cpu , au.presetName . Scenes & Follow Actions: - Scene recall targets instance or group scope; Follow Actions can toggle individual instance bypass at Beat/Bar/Loop with late-press guard. Performance & Safety: - Bypassed instances can sleep/suspend DSP (optional tail-safe release for reverbs/delays). - Micro-fade (5–20 ms) on bypass to prevent clicks; full undo/redo. Benefits: Choose workflow: one-switch global control or granular per-instance toggling. Easier A/B/C comparisons and scene-programming without duplicate chains. Better CPU management by sleeping unused clones. Cleaner templates; fewer workaround macros. Examples: Three cloned comps on vocals: parameters linked, bypass independent for fast flavor A/B/C in rehearsal. Parallel FX chain: keep Reverb linked & always on; toggle Chorus only on instance B during chorus. Scene 1 enables clone A , Scene 2 switches to C with tail-safe bypass to avoid cuts. This summary was automatically generated by GPT-5 Thinking on 2025-11-04. Original Post: Ability to Disable Individual Instances of FX Auv3 Duplicate (A,B,C…) When using Duplicates/ Clones of a Auv3 FX Instance, currently, enabling/disabling one of the duplicates will a enable/disable all of them. Individual control would mean much more flexibility and taking advantage of the duplicates feature.

Description: Let Text widgets show live or snapshot values from other widgets (faders, toggles, radios, menus, meters, clip/mixer props), triggered by On Press , On Select , On Change , On Release , or Timed Poll . Provide a simple templating syntax, formatting options, and safe cross-page references. Problem: Labels often need to mirror state elsewhere (e.g., show the value of a hidden fader or the currently selected radio item). Today this requires ad-hoc variables/macros and isn’t discoverable. There’s no direct way to say “when I press/select here, display that control’s value there,” with formatting, scope, and low latency. Proposed Solution: Binding & Templating: - Inline tokens: {widget:<nameOrId>.value} , {clip.selected.name} , {mixer.track[2].pan} , etc. - Multiple tokens per label with text, e.g., Delay: {widget:DelayMix.value|pct0} @ {tempo.bpm|0.0} . - Format pipes : |0 , |0.0 , |pct0 , |ms , |Hz , |signed , |pad2 , |upper , custom |map tables. Triggers (per Text widget): - On Press (of a target widget), On Release , On Select (radio/menu), On Change (value changed), Interval (e.g., 10 Hz), and Manual Refresh . - “ Snapshot vs. Live ” mode: one-off capture at trigger vs. continuous subscription until dismissed. - Debounce/Throttle to avoid spam during fast moves; hold/long-press variants. Targeting & Scope: - Reference by name, tag, color, or ID ; choose Nearest on Page , This Page , or Project-wide (cross-page safe). - Safe failure text (e.g., “—”) and warnings for missing/ambiguous targets; picker UI to resolve conflicts. Styling & Layout: - Auto-fit text, min/max font size, marquee for overflow, number alignment options, prefix/suffix units, conditional color (e.g., red when > −6 dB). - Optional icon/pictogram alongside value; supports Genmoji and embedded assets. Actions & Variables: - Actions: Text → Bind To Widget… , Set Template Text , Refresh Now , Start/Stop Live Subscription , Set Trigger (Press/Select/Change/Interval) . - Vars: text.boundTargets[] , text.lastValue , text.isLive , text.refreshHz , text.error . Debug & Safety: - Inspector shows resolved tokens and current values; “copy resolved text” for logs. - Sandboxed cross-page reads (read-only) with permission toggle; rate limit for background polling. Advanced: - Conditional templates : {if widget:Rec.state=="record"}● REC{else}idle{end} . - Aggregation : {avg widget:Band*.gainDb|0.0} dB , {max group:"Sends".value|pct0} . - Event queue : buffer last N changes for quick flick-through (“previous value” recall). Benefits: Clear, at-a-glance feedback without exposing the source controls. Faster programming—no fragile macro webs for simple readouts. Consistent, formatted labels across pages and projects. Performance-safe updates with throttling and subscriptions. Examples: A Text widget on the Master page shows Reverb {widget:RevMix.value|pct0} when the Reverb button is pressed , then stays live while held. A Radio for delay times updates a nearby label On Select : Delay: {widget:DelayTime.selectedLabel} . A compact header displays BPM {tempo.bpm|0} • Grid {edit.grid|note} with a 10 Hz interval trigger. Press a “Show Current Send” button: text snapshots {mixer.track[Vox].sendA|pct0} without subscribing. This summary was automatically generated by GPT-5 Thinking on 2025-11-04.

Description: Add dedicated Sustain Pedal (CC64) tools in the MIDI editor: a visual lane with pedal-down regions, smart functions to extend/merge notes under pedal , split at lifts , quantize/humanize pedal on/off , and support for half-pedaling . Include companion lanes for Sostenuto (CC66) and Soft (CC67) , plus one-click “bake/unbake” between pedal data and note lengths. Problem: Pedaled performances (piano, EP) record as short notes + CC64 holds. Editing or quantizing them is tedious: notes look staccato, pedal lifts get misplaced, and repedaling/half-pedal nuance gets lost. Fixing stuck notes, aligning lifts to the grid/groove, or converting pedal gestures into clean legato lengths currently requires time-consuming manual work. Proposed Solution: CC Lanes & Visualization - CC64 lane with pedal-down shading ; threshold & hysteresis to define “down” (e.g., ≥64 by default). - Half-pedal curve (map 0–127 to sustain amount), optional per-instrument response. - Optional lanes for CC66 (Sostenuto) and CC67 (Soft) with distinct shading. Smart Edit Operations - Pedal → Extend Notes: lengthen note-offs to the next pedal lift (legato merge across pedal). - Lift-Aware Split: cut sustained notes exactly at pedal lifts (with optional gap ms). - Render Sustain to Note Lengths / Extract Sustain from Overlaps (bake/unbake). - Quantize Pedal On/Off to grid or groove with feel %, and Humanize (±ticks) for natural lifts. - Repedaling handling: treat short lifts below N ms as continuous sustain. - Half-Pedal Scaling: compress/expand sustain amount by curve; clamp min hold. - Re-articulate after Lift: insert short release gaps or staccatissimo per setting. - Fix Stuck Notes: detect mismatched offs masked by pedal; generate/correct note-offs. Editing UX - Pencil/erase for pedal envelopes; box-edit multiple lifts; nudge on/off by ticks/beats. - Readouts while dragging: On @ 33.3.2 • Off @ 34.1.1 (Δ 0.6 beat) . - Chase state when starting playback mid-clip (reconstruct held notes from current pedal value). Actions & Variables - Actions: Extend Notes Under Sustain , Split at Pedal Lifts , Quantize Pedal On/Off , Bake Sustain to Lengths , Extract Sustain , Toggle Half-Pedal , Fix Stuck Notes . - Vars: cc64.down (bool), cc64.value , cc64.threshold , pedal.liftCount , pedal.halfAmount . Safety & Integration - Works with tempo/quantize changes and groove templates; fully undoable. - Per-track defaults for thresholds, repedal window, and half-pedal curve. Benefits: Clean, legible MIDI that reflects how pedaling actually sustains notes . Faster editing and musically correct quantization of pedal gestures. Preserves nuance (repedals, half-pedal) while fixing timing and stuck notes. Flexible workflows: keep CC64 live or bake into note lengths for export. Examples: Convert a recorded piano take: Bake Sustain to Lengths , quantize lifts to 1/4-groove , then Unbake to restore CC64 if needed. After a tempo change, Quantize Pedal On/Off and Repedal window = 80 ms to maintain natural legato. Use Lift-Aware Split to create re-articulations at each pedal up; add a 10 ms gap for clarity. Enable Half-Pedal with a gentle curve so values 50–90 produce partial sustain instead of binary holds. This summary was automatically generated by GPT-5 Thinking on 2025-10-14. Original Post: Midi editor: process sustain pedal messages Hi, I record piano into midi clip, the clip then has visible dots that mark places where I press and release the sustain pedal. However, I do not see the marks in the midi editor and hence cannot edit them. So loopy records midi messages for pressing and releasing the pedal, but doesn’t allow to process it.

Description: Improve the readability of UI elements like list widgets, stepped dials, and radio buttons by offering customizable or larger font size options. Problem: For many users, especially in live performance or low-light situations, the current text size in list-based or selection-based widgets is too small to read comfortably and quickly. This limits usability and increases the chance of errors. Proposed Solution: – Add adjustable font size settings for: - List widgets - Stepped dials - Radio button groups – Allow bold/high-contrast modes for better visibility – Possibly include UI scaling presets or per-widget overrides Benefits: ✅ Better accessibility for users with impaired vision or on small screens ✅ Faster and more accurate navigation in live contexts ✅ Less eye strain, more focus on performance ✅ Aligns with UX expectations of modern touchscreen apps This summary was automatically generated by ChatGPT-4 on May 2, 2025.

Description: Add an option for XY pads in Loopy Pro to automatically snap to the center (zero) position when released. Problem: Currently, XY pads stay where they are after you lift your finger. For certain workflows—especially modulation control, filter resets, or effect toggles—it's useful if the XY pad returns to zero when no longer touched, similar to spring-loaded joystick behavior. Proposed Solution: — Add a toggle option per axis (X and Y separately) for "Snap to 0 on release" — Optionally configure the snap-back speed (e.g. instant, or glide back in x ms) — Optional mode: only snap when released from inside the pad (not from the edge) Benefits: ✅ Mimics real-world controller behavior (e.g. joystick, spring-loaded fader) ✅ Useful for effects like temporary filter sweeps or dynamic sends ✅ Improves live performance precision ✅ Reduces manual effort to reset control states ✅ Simplifies patch design with fewer extra reset actions needed This summary was automatically generated by ChatGPT-4 on May 2, 2025.

Description: Currently, the “Cancel Count-Ins/Outs” action applies globally—it cancels all scheduled count-ins and count-outs without the ability to target specific clips or types. Users often need more granular control to cancel only some scheduled actions without disrupting others. Problem: In scenarios like switching play groups, triggering multiple clips, or correcting a single mistake, cancelling all pending count-ins/outs is too destructive. Users may want to cancel a count-in for one clip but let others proceed. The lack of targeting results in unintended interruptions during live performance or recording workflows. Proposed Solution: Add standard targeting options (e.g. “this clip”, “play group”, “all clips”, etc.) to the “Cancel Count-Ins/Outs” action. Allow filtering by count-in/out type: - Any - Count-ins - Count-outs - Play count-ins - Stop count-outs - Record count-ins - Record count-outs This would enable gestures or MIDI actions to cancel only specific pending transitions for the targeted clip(s). Benefits: More precise live control over clip transitions. Avoids unintended cancellation of unrelated actions. Enables recovery from mistakes without interrupting the intended flow. Enhances expressive performance workflows and gesture-based control. Examples: Trigger a breakdown section and cancel only the count-in for the next chorus without affecting the rest of the loop transitions. Correct a mistakenly triggered recording count-in without stopping other play or stop transitions. Use a contextual gesture to cancel pending actions only for the clip it's performed on. This summary was automatically generated by ChatGPT-4 on July 24, 2025. Original Post: Allow targeting for “Cancel Count-Ins/Outs” action Currently the “Cancel Count-Ins/Outs” action does not have any targeting options, so it cancels all count-ins/outs. Sometimes users might only want to cancel some of the count-ins/outs. For example, after triggering a mutually exclusive play group to play in order to switch from one section of a song to another, I might then want to cancel the count-in for some of the clips that are about to play (for a breakdown section) while letting the other count-ins/outs continue. Or anytime I trigger multiple clips to play, stop, or record, and one or more but not all was by mistake, I could fix my mistake while still allowing the other actions that were on purpose to continue. This action should have all the targeting options that other actions have. Targeting “this clip” is the option I most want to have because I could set a gesture that cancels count-ins/outs for whichever clip that gesture is performed on. But I can see uses for other targeting options as well.

Description: Provide a Channel-First sort option for MIDI destination pickers (and related lists) so ports appear grouped by device/port and channels are listed 1→16 (plus Omni/MPE), with optional secondary sort by name. Make this selectable per picker and saveable per project/global. Problem: When destinations are sorted alphabetically by name , channel entries for the same port scatter and numeric order is lost (e.g., “Ch 10” before “Ch 2”). This slows mapping, increases mistakes on stage, and makes auditing/changing routings harder—especially in large rigs with multiple ports and MPE. Proposed Solution: Sort Modes (per picker, remembered): - Channel-First: Port → Channel (1–16) → Name . - Port → Channel → Name (explicit variant for multi-port devices). - Name-First (current behavior). - Custom (optional: user-defined order for favorites). Grouping & Display: - Collapse/expand Port groups; within each group show Ch 1…16 , then Omni , then MPE zones (Lower/Upper/Per-Note). - Natural numeric sorting (2 before 10); pinned favorites at top of group. - Compact badges : Port • Ch 10 , Omni , MPE . Filters & Search: - Quick filters: ** ch:10 , port:Keystep , mpe:true , omni **. - Toggle “ Show only channels in use ” to hide empties. Preferences & Scope: - Picker-level toggle (toolbar chip) and Global/Project default in Settings. - Remembers last choice per context (Learn dialog, Mixer input/output, Device target). Edge Cases: - Show channel ranges ( Ch 3–5 ) if the destination is a multi-channel bus. - Stable order when devices reconnect; ghost entries for temporarily missing ports with a relink hint. - MPE: group by zone, then show per-channel details when expanded. Actions & Variables: - Actions: Set MIDI Destination Sort (Channel-First/Name-First/Port-Channel) , Filter Destinations by Channel/Port . - Vars: midiPicker.sortMode , midi.in.channel , midi.out.channel , midi.portName , isMPE . Benefits: Faster, less error-prone mapping—channels are exactly where you expect them. Cleaner audits of complex rigs; easier teaching/documentation. Consistent experience across pickers with per-project/global defaults. Examples: In MIDI Learn, choose Channel-First : Keystep › Ch 1, Ch 2, … Ch 16, Omni, MPE . Select ** ch:10 ** to jump straight to drums. Mixer Output picker groups by Port , listing channels 1→16 ; favorites (Ch 2, Ch 10) appear pinned at top. An MPE synth shows MPE (Lower Zone) first; expanding reveals its channel range, followed by non-MPE channels. This summary was automatically generated by GPT-5 Thinking on 2025-11-04. Original Post: Sort MIDI destinations by channel number, rather than name (or have the option for how to sort) Would be great to have the option to sort the the MIDI destinations in the MIDI destination box by channel number .. when you have many plugins filtered by channel number but sorted by plugin name (current behavior), it feels a bit mixed up ..

Description This feature request proposes the implementation of 14-bit MIDI support within Loopy Pro to enable high-resolution control over internal parameters as well as those of hosted AUv3 plugins. Supporting 14-bit MIDI would dramatically increase the resolution of parameter adjustments—from 128 steps to 16,384—making Loopy Pro suitable for precision-critical use cases in live performance, sound design, and professional production environments. Problems Insufficient Resolution with 7-bit MIDI : Current MIDI support is limited to 7-bit (0–127) messages, which causes stepping artifacts when controlling parameters like filter cutoff, reverb amount, or pitch, particularly on high-quality AUv3 instruments and FX. Limited Expressiveness and Control : Power users and live performers using expressive hardware struggle to achieve the desired smoothness and nuance, especially when dealing with fine-tuned parameters like EQ bands, compressor thresholds, or pitch bends. Underutilized Hardware Capabilities : Many modern MIDI controllers (e.g. Electra One, Faderfox EC4, BomeBox) already support sending 14-bit high-resolution CC (including NRPN and RPN). Without support in Loopy Pro, these devices can't be fully utilized. Proposed Solution Full 14-bit MIDI Support : - Recognize and respond to 14-bit high-resolution MIDI Control Change messages (using MSB/LSB pairs). - Support both NRPN and RPN-based control messages. Enhanced MIDI Learn Engine : - Extend the MIDI Learn system to detect 14-bit CC pairs and assign them as high-resolution parameter sources. Visual Feedback for High-Res Bindings : - Clearly indicate when a parameter is being controlled via 14-bit resolution (e.g., with a visual tag or tooltip in the UI). AUv3 Integration : - Ensure that high-resolution control is passed through to hosted AUv3 plugin parameters that natively support fine resolution. Examples Precise Filter Sweeps : A performer uses an Electra One to send 14-bit CC data to control a synth’s cutoff frequency inside Loopy Pro, achieving silky-smooth filter movements with no audible stepping. Plugin Automation : A producer records high-resolution automation into Loopy Pro using a Faderfox EC4, adjusting reverb decay and EQ gain curves with surgical precision. Cross-Platform Consistency : A user coming from Bitwig or Logic Pro wants the same level of resolution with their MIDI controller when using Loopy Pro live on iPad or macOS. Device-Specific Expectations : Controllers like the Electra One , Faderfox EC4 , and setups using BomeBox or Axoloti expect 14-bit support and already send such data. Without support, Loopy Pro remains the weak link in an otherwise high-res control chain. Benefits Professional-Grade Precision : Ensures Loopy Pro is capable of delivering the same level of detailed automation and live control as top-tier desktop DAWs. Expanded Hardware Compatibility : Allows seamless integration with hardware that sends 14-bit MIDI—common in studio and touring-grade MIDI setups. Improved Sound Design and Live Control : Enables smoother real-time parameter morphing, better modulation routing, and more expressive performances. This summary was automatically generated by ChatGPT-4 on 2025-05-17.