Type Piano performance and setup guide
Type Piano is a focused standalone instrument. The complete application is free, and the same performance state drives computer-keyboard input, a native MIDI controller, and the on-screen A0-C8 keyboard. This guide explains the quickest path to sound, then shows how to reason about sustain, patches, audio setup, and platform availability without assuming capabilities the application does not claim.
Start with the computer keyboard
Open Type Piano and use the illustrated typing layout to play a compact range immediately. Move the active octave when the notes you need sit outside that range, and choose a velocity level before comparing sounds. Hold Space for temporary sustain; use the visible sustain state to confirm whether released notes are being held by the pedal model. The 88-key display distinguishes physically held notes from sustained tails, which makes a stuck control easier to diagnose.
The computer mapping is deliberately a performance surface rather than a typing game. It shares note ownership with the other inputs, so a note held by a MIDI keyboard is not silenced merely because the matching computer key was released. Pointer input follows the same rule and supports glissando across adjacent keys.
Connect a MIDI keyboard
Connect and power the controller before selecting it in Type Piano. The operating system must enumerate the device before the application can offer it. Native MIDI note messages carry velocity into the engine, and sustain-pedal CC64 messages operate the same sustain state used by Space and the screen control.
If the device is missing, check the cable, USB port, operating-system MIDI list, and whether another application has exclusive ownership. Reconnect after changing the physical setup. Type Piano reports connection attention instead of treating a vanished input as a successful silent session. It does not promise that every controller driver behaves identically, so the host device list remains the first source of evidence.
Choose the right instrument
Studio Grand is the direct sampled-grand presentation. Felt Room shapes the same verified acoustic source toward a softer, closer response. Both stream velocity, release, resonance, and pedal material from the packaged Salamander bank rather than loading the whole library into memory at launch.
Classic EP is not another acoustic sample label: it is a velocity-responsive FM electric-piano engine. Glass Piano is an additive voice designed for a clearer, more bell-like attack. Compare instruments at the same input velocity and output level; otherwise a louder patch can be mistaken for a better one.
Understand sustain and release
A physical key can be released while its note remains audible because the sustain pedal is down. Type Piano tracks held and sustained states separately, releases pedal-retained notes when sustain lifts, and uses available release, resonance, and pedal layers for the sampled instruments. If notes continue unexpectedly, release Space, unlatch the on-screen sustain control, and verify that the MIDI controller is not still sending CC64 down.
Keep the audio path stable
Realtime performance depends on the host audio device, driver, buffer, and system load. Close competing audio clients when startup fails or sound breaks up. Begin with a stable buffer before attempting a lower-latency setting. Confirm that the formal sample bank is ready; the sampled patches cannot honestly fall back to an unrelated sound while presenting themselves as the packaged grand piano.
Type Piano does not advertise a fixed latency number because that would ignore the host audio path. It also does not claim to be a VST, DAW, recorder, sequencer, notation editor, or lesson platform. Use a separate recording or production tool when the job extends beyond direct standalone performance.
Verify the package boundary
The sampled voices use Salamander Grand Piano V3 recordings by Alexander Holm under CC BY 3.0. Release packaging pins the source evidence, attribution notice, legal text, filenames, sizes, and checksums. This is both an integrity control and a clear separation between Hannes Software's proprietary application and the sample library's own license.
Linux and Windows files listed on the official download page are public releases. The Windows NSIS installer uses an explicit unsigned, no-target-host-acceptance exception: its checksum proves the package bytes, but signing, install/uninstall, audio, MIDI, architecture, UI, and platform-security acceptance remain unverified. A macOS file is not released merely because it can be assembled; the signed, notarized, and stapled universal DMG must first pass native acceptance on macOS. Always use the official Type Piano download page as the public package source of truth.
Return to the Type Piano product overview for the complete capability boundary and free-edition summary.
<!-- multilingual-help-closeout:start -->Direct answer and acceptance boundary
For “Type Piano performance and setup guide”, the short answer is: Learn how Type Piano connects computer keys, native MIDI, and the on-screen 88-key instrument to four local sound engines, expressive sustain, and a verified streamed piano bank. Treat that statement as a result to verify, not as a promise that every input, device, project, or environment behaves identically. A complete result records the starting state, the exact action, the visible output, and the condition that proves the task is finished in Type Piano.
Evidence-first operating procedure
Work from a small, repeatable case before changing a full project. Record the application version, operating system, input or device identity, relevant settings, and the expected result. Perform one deliberate action, preserve the first unexpected transition, and compare it with a known-good run whenever one is available. Changing several controls at once may hide which condition fixed or created the problem.
Checkpoint 1: Type Piano performance and setup guide
Treat “Type Piano performance and setup guide” as a separate acceptance gate for “Type Piano performance and setup guide”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.
Checkpoint 2: Learn how Type Piano connects computer keys, native MIDI, and the on-screen 88-key instrum
Verify “Learn how Type Piano connects computer keys, native MIDI, and the on-screen 88-key instrument to four local sound engines, expressive sustain, and a v” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.
Checkpoint 3: Start with the computer keyboard
For “Start with the computer keyboard”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.
Checkpoint 4: Connect a MIDI keyboard
Use “Connect a MIDI keyboard” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.
Checkpoint 5: Choose the right instrument
When “Choose the right instrument” is ambiguous, compare one known-good case with one failing case under matching conditions. Mark the first meaningful difference rather than listing every later symptom. That first boundary usually produces a clearer support request and a safer next experiment.
Checkpoint 6: Understand sustain and release
Close “Understand sustain and release” only after the saved, exported, or reopened result still matches the observed state. Temporary UI feedback is useful, but durable evidence is stronger. Record any limitation that remains so the next reader does not interpret an incomplete path as a successful one.
Checkpoint 7: Keep the audio path stable
Treat “Keep the audio path stable” as a separate acceptance gate for “Type Piano performance and setup guide”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.
Checkpoint 8: Verify the package boundary
Verify “Verify the package boundary” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.
Checkpoint 9: Type Piano is a focused standalone instrument.
For “Type Piano is a focused standalone instrument.”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.
Checkpoint 10: The complete application is free, and the same performance state drives computer-keyboard
Use “The complete application is free, and the same performance state drives computer-keyboard input, a native MIDI controller, and the on-screen A0-C8 key” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.
Acceptance matrix
| Checkpoint | Evidence to retain | Pass condition |
|---|---|---|
| Type Piano performance and setup guide | Initial state, one action, and resulting state | A second operator can reproduce the stated outcome |
| Learn how Type Piano connects computer keys, native MIDI, and the on-screen 88-key instrument to four local sound engine | Initial state, one action, and resulting state | A second operator can reproduce the stated outcome |
| Start with the computer keyboard | Initial state, one action, and resulting state | A second operator can reproduce the stated outcome |
| Connect a MIDI keyboard | Initial state, one action, and resulting state | A second operator can reproduce the stated outcome |
| Choose the right instrument | Initial state, one action, and resulting state | A second operator can reproduce the stated outcome |
| Understand sustain and release | Initial state, one action, and resulting state | A second operator can reproduce the stated outcome |
Failure isolation, recovery, and handoff
If a check fails, stop at the first failed boundary. Preserve the source, project, session, or capture; duplicate it before destructive editing; and change one variable per experiment. Repeating a broad workflow after several simultaneous changes may produce a different result without explaining why.
Separate absence of evidence from evidence of absence. A blank view may mean the wrong input, scope, filter, permission, device, time range, or project state rather than “nothing happened.” Verify the acquisition or import path before interpreting a decoder, editor, report, or export.
Before handoff, reopen the durable artifact and inspect its beginning, the decision point, and its end. Record version, platform, relevant configuration, expected behavior, observed behavior, and the smallest reproduction. Remove or redact sensitive material and confirm the recipient is authorized to receive it.
Questions and answers
What is the fastest reliable way to start?
Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.
What evidence should be saved?
Keep the input identity, application version, platform, relevant settings, exact action, first unexpected transition, and final output. If the workflow creates a project, session, report, or export, close and reopen it before treating it as durable evidence.
When should the procedure be repeated?
Repeat it after an application, operating-system, driver, firmware, model, source, or workflow change that can alter the result. Preserve the earlier accepted case so the comparison uses the same acceptance boundary rather than memory.
When is the task ready for handoff?
It is ready when another authorized person can identify the input, repeat the action, see the same result, understand any remaining limitation, and open the saved artifact without relying on undocumented local state.
Related guides
Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic:
<!-- multilingual-help-closeout:end -->