Producer Rig redesign handover

What this prototype is

A front-end redesign of the existing ENSO WAVE Producer Rig. It reorganises the existing features into five connected workspaces and shows the proposed additions, clearly labelled. It runs on representative data with no connection to the production backend or to Suno.

• Every screen is interactive: settings change, undo and redo work, projects save to the prototype's own database, and payloads can be copied or downloaded.
• Producer replies, section check-ins and the songwriting coach come from small local rule sets so the approval flow can be reviewed. They stand in for the live Producer.
• Sketch audio in the transport is a local WebAudio synth that plays chords, bass and drums from the settings. It is a listening aid, not a generated take.
• Generation, extension and repair are gated behind a connected service. Settings can simulate a service to review the flow; simulated results are labelled and only create mock versions.
• Genre families, presets and instrument names are representative and must be replaced by the existing preset metadata.

Source of truth and verification

The redesign brief referred to screenshots and a developer walkthrough. They were not attached to the brief this prototype was built from, so the feature list comes from the written brief.

• Rows marked Verify in the relocation map need checking against the current build before development starts.
• Where the brief said preserve or existing, the feature is marked Preserved or Relocated. Where it asked to add or include something new, it is marked Proposed.
• Nothing in the prototype claims an integration that does not exist. Simulated behaviour is always labelled.

Status legend

The five workspaces

Existing features to preserve

• Seven genre families, the preset library and the preset metadata.
• Groove modes, World Flavour, regional and musical influences.
• Rack-style structure modules, motif behaviour and musical identity.
• Gurn / Girth as an optional character control, with its existing behaviour.
• Key, BPM and Energy, kept together in one module.
• Wubs, dubstep modulators, bassline patches and bass layers.
• Low, mid and high rhythmic layers and drum divisions.
• Talk to the Producer and the existing producer intelligence.
• The lyrics editor, songwriting coach, rap and singing modes and vocal settings.
• The Suno payload workflow: style, lyrics, exclusions and instructions, with copy and export.
• Create, Rig, Output, Library and More navigation.
• All existing generation logic. The prototype's payload mapping is representative only.

What changes in the layout

• Five workspaces replace the single long Rig page. They share one project state, so moving between them never loses work.
• A persistent shell: top bar with brand, workspace tabs, project name, save state, undo, redo, Save, Export and settings; app rail with Create, Rig, Output, Library and More; timeline with transport; the workspace; and a right-hand inspector.
• Rig maps to Music, Lyrics and Arrangement. Output maps to Generate and Refine.
• Music is a chain of eight connected rack modules. Basic controls come first and technical parameters fold under Advanced.
• The target duration slider becomes an exact minutes and seconds readout with typed entry, keypad, steppers and presets.
• Wubs, modulators, patches and layers are reunited in Bass Design.
• Instrument selection is centralised in the Instrument Library. Its bass and drum tabs mirror their design modules so each setting has exactly one home.
• Talk to the Producer sits at the end of Music and returns suggestions instead of changing settings.
• Lyrics move to their own workspace, separate from the music configuration.
• The arrangement technique grid becomes compact, sortable section cards with a full panel per section.

Shell layout and breakpoints

Project state

One project object holds everything that is saved and undoable. UI state, such as selection and open panels, and browser preferences are kept apart.

ProjectState {
  music: { genre, structure, character, harmony, bass, drums, instruments[] }
  lyrics: { mode, instrumental, language, blocks[], vocal }
  arrangement: { sections[] }
  generate: { styleOverride, exclusions[], instructions, target, targetSectionId }
  locks: { genre?, structure?, character?, harmony?, bass?, drums?, instruments?, vocal? }
}

Section { id, type, name, bars, energy, tension, layers[], bassBehaviour,
          drumBehaviour, vocalBehaviour, motif, transitions[], notes, approved }
LyricBlock { id, sectionId, text, performance, approved, sameAs }
InstrumentPick { id, role, register, articulation, timbre, intensity,
                 placement: 'all' | sectionId[] }

• Undo and redo snapshot the whole project. Continuous gestures such as knob drags and typing merge into one step after a short pause.
• Instrument placement is stored once, on each instrument, and shown in both the library and each section.
• Lyric blocks link to sections by id. Removing a section keeps its words as unplaced lyrics. A block can repeat another section's words with sameAs.
• Approvals live in the project: module locks, section approval and lyric block approval.

Producer suggestion contract

Every automated change, whether from the Producer, a check-in, the coach or a fit-to-length, uses the same suggestion object, so nothing can change settings silently.

Suggestion {
  id, scope: 'music' | 'section' | 'lyrics' | 'arrangement', sectionId?
  title, detail
  changes: [{ id, module, targetId?, label, from, to, selected }]
  actions: [{ label, href, sectionId? }]
  status: 'pending' | 'applied' | 'dismissed'
}

• The live Producer should return changes as data and never apply them. The client applies only the changes the user ticks.
• A change is blocked when its module, section or lyric block is approved. Blocked changes stay visible with an Approved label.
• Check-in sends one section and must only return changes for that section. Notes about neighbouring sections come back as links, not changes.
• Applying a suggestion is one undo step and shows an Undo action.

Payload mapping

Representative mapping used by the prototype. Production keeps the existing generation logic; this table shows what each field draws on.

Validation checks in Generate

• Empty arrangement (blocking).
• No preset selected.
• Tempo outside the preset's range.
• Hybrid preset whose tempo range does not overlap.
• Progression written for the other key family.
• Instrumental on while lyrics exist.
• Vocal sections without lyrics.
• An excluded term that matches a selected instrument or the chosen voice (blocking).
• Vocals excluded while sections use vocals (blocking).
• Arrangement length more than 15 seconds away from the target.
• Style or lyrics longer than the length guide (blocking).
• A drop with neither bass nor drums, or a drop calmer than its build.
• Wubs on with every bass layer off.
• Lyrics that are not placed in any section.

Backend and integration work

Accessibility and interaction

• Every control works from the keyboard. Knobs, faders and meters are sliders with arrow keys, Page Up and Page Down; segmented controls use arrow keys; sections reorder with the keyboard or with Move up and Move down.
• Colour is never the only signal. Section blocks carry names, status badges carry labels, and the curves have a legend and a table view.
• Text meets WCAG AA contrast on the dark panels and focus rings are a visible cyan.
• Motion respects the reduced motion setting.
• Touch targets are at least 32px in dense rack areas and 44px or more in navigation and mobile sheets.

Open questions for the developer

• Confirm the seven genre family names and the exact preset metadata fields.
• Confirm what Gurn / Girth controls today and how it maps into the payload.
• Confirm which of rap and singing modes, vocal identity, delivery and phrasing exist today.
• Confirm whether the current Producer can return structured changes, or only text.
• Confirm the style and lyrics length limits for the Suno plan in use.
• Confirm which features the connected service supports: section previews, extension, repair and cost quotes.
• Confirm where generated audio is stored and whether waveform peaks are available.