Recent music-AI and MIDI infrastructure work translated into product decisions.

Keep transport posture visible in-product. MIDI 2.0 Web MIDI, BLE, and managed network transport work means the browser forge should expose whether a capture is legacy MIDI 1.0, UMP-normalized, or profile-ready.

Treat multi-client MIDI and UMP-native operating-system support as baseline assumptions. Browser capture should stay resilient when users run multiple MIDI-aware tools at once, and release notes should call out OS-level caveats explicitly.

Keep the browser engine UMP-first internally and store translation metadata. Windows MIDI Services now makes multi-client routing, MIDI 1.0-to-UMP translation, loopbacks, and scheduled messages normal platform expectations rather than niche studio features.

Treat lookahead scheduling and transport telemetry as core player features. Network MIDI 2.0 pushes UMP and jitter-reduction timestamps into the transport layer, so the browser player should expose queue health instead of hiding timing behavior.

AI music creation needs explicit model-mode choices. The generation surface should distinguish fast clip prototyping from longer structured songs, and should expose tempo, lyrics, mood, and multimodal inputs only when the configured provider supports them.

Treat text-to-MIDI as controlled co-creation, not a prompt box. Product prompts should preserve key, meter, tempo, and structural constraints so generated clips remain editable and musically coherent.

Model long-form music as macro skeleton plus texture. The player now emits a structure brief so generation, loops, and accompaniment can anchor to sections before filling ornamentation.

Keep MidiverseForge explicit about realtime session control: weighted prompts, BPM steering, pause/play/reset behavior, and audio buffering should be first-class UX instead of hidden transport details.

Preserve beat-aware timing structure in the product model. Practice, continuation, and accompaniment features should retain explicit temporal grouping instead of flattening everything into event streams; the forge now computes a beat-grid stability signal on each capture.

Treat rhythm-game style playability as an import/export constraint. MidiverseForge should keep per-lane onset evidence and readable timing windows so practice captures can later become playable charts instead of static analytics snapshots.

Surface profile targets before export or playback. The player now reports inferred readiness for Piano, MPE, drum note-map, default CC, orchestral articulation, and GM function-block profiles instead of treating every MIDI file as a flat note stream.

Prefer compact music-understanding models for responsive product surfaces. Short-form coaching, tagging, and assistive analysis should stay cheap enough to run often instead of batching everything behind heavyweight jobs.

Keep sheet ingestion grounded in robust document understanding instead of one-off heuristics. When MidiverseForge scans notation, the output should stay editable and structurally meaningful.

Treat spatial music surfaces as closed-loop software, not visual demos. The WebXR roadmap should include scene inspection, input emulation, screenshot checks, and bug-fix loops before any VR piano or realm mode is called production-ready.

Do not stop at note correctness. Error detection and future coaching should fuse symbolic and score/audio context instead of treating mistakes as isolated event mismatches; current captures now emit concrete bug-findings before feedback is trusted.

Judge imported and captured performances by structural coherence, not just truth-label matching. The bug hunt now treats saved captures as evidence that can be grouped, exported, and re-evaluated as the score-performance model improves.

Keep timing feedback tolerant to perceptual misalignment. The capture pipeline now preserves signed offsets, median latency, drift, and beat-grid stability so future audio transcription can optimize around human-perceived timing instead of frame-perfect labels only.

Keep practice captures durable and exportable. The product should store enough aligned symbolic detail to support future expressive-rendering training, benchmarking, and score-to-performance workflows.

Treat expression as a distinct product dimension. Feedback, scoring, and AI coaching should separate note correctness from expressive rendering quality and avoid inflated claims of human-level musicality.

Score expression at phrase and section level, not only as aggregate velocity statistics. Conductor Map and future coaching should separate timing, dynamic contour, articulation, and pedaling so practice feedback remains actionable.

Keep symbolic scoring for instant browser feedback, but leave an explicit seam for audio-grade evaluation. The roadmap should not pretend MIDI-only metrics capture expressive quality completely.