Feature Request: Implementing a Tear-Off / Detachable Architecture for the FL Cloud Browser Panel

[RJPR86]

To the Image-Line Development Team,

I am writing to formally suggest a significant UI/UX architectural enhancement for the FL Studio ecosystem: the implementation of a fully detachable, independent window instance for the Browser panel, specifically regarding its integration with the FL Cloud content delivery system.

Current Limitation & Workflow Friction:
The current implementation locks the Browser (and by extension, the FL Cloud sound library interface) into the main parent MDI (Multiple Document Interface) container. While the Browser supports vertical/horizontal docking and pinning, it lacks the ability to be "torn off" into a separate, top-level window handle (HWND).

This presents significant ergonomic and technical bottlenecks, particularly for producers utilizing multi-monitor arrays or high-DPI workflows:

1. Render Context Priority: When scrubbing through FL Cloud previews while simultaneously sequencing in the Playlist or manipulating parameters in the Channel Rack, the single-threaded UI repaint context often forces the main window to prioritize the Browser's asset loading, causing micro-stutters in the GUI thread when assets are streamed from the cloud cache.
2. Screen Real Estate Fragmentation: To keep the FL Cloud browser visible for rapid auditioning, users must sacrifice horizontal or vertical workspace within the main project view. Unlike the Mixer or Plugin windows (which support Free and Detached modes via the wrapper settings), the Browser remains a persistent child widget.
3. Multi-Monitor Inefficiency: On high-resolution displays (4K+), resizing the main project to accommodate the cloud browser forces the entire rasterization pipeline to recalibrate. A detached window would allow for a dedicated display entirely reserved for the FL Cloud asset browser, operating as a secondary process view.

Proposed Technical Solution:
I propose the decoupling of the Browser's UI representation from the main TMainForm. Specifically:

- Implementation of a Tear-Off Flag: Introduce a TFormStyle = fsStayOnTop or a similar top-level window flag for the Browser shell, allowing it to exist as a standalone process thread separate from the main Arrangement/Playlist rendering context.
- Asynchronous Asset Loading Optimization: If the Browser is instantiated as a separate window, the HTTP client responsible for FL Cloud's sound previews and waveform generation could theoretically operate on a separate UI messaging pump. This would prevent the main timeline transport from experiencing buffer underruns during heavy cloud-based sample previewing.
- Persistent State Memory: The detachable state should be written to the EnvManager.ini or a dedicated layout preset, allowing users to save this detached configuration as part of their custom workspace layouts (Alt + 1-4).

User Experience Rationale:
In its current state, the Browser acts as a modal bottleneck within the parent frame. By granting it the same detachable autonomy that is already afforded to the Mixer, Playlist, and Piano Roll (via the "View" menu), FL Studio would align its cloud-based workflow with the modular paradigm that defines the software's core philosophy.

I strongly urge the team to consider this a priority UX enhancement for future releases (FL 25+). It bridges the gap between physical hardware workstation setups and the burgeoning ecosystem of FL Cloud.

Thank you for your time and continued development of the industry standard.

Sincerely,
Roberto