From music intelligence to a useful learning product.
Prepared for Paul Williams. Start with what to deliver, who benefits and what proves it works. Technical research supports the decisions.
01
Start here: prepare for the job they described
Your goal is to demonstrate product judgment and delivery ownership, with enough technical understanding to make useful decisions.
Meeting evidence supplied by PJ
The CEO said their first planned project connects education, music and AI, targets the U.S., and needs education expertise and natural wording for native users. PJ also reported a year-end delivery goal and an interview test. The actual test brief, audience age, learning objective and assessment rubric have not been provided.
Your evidence
Your most relevant contribution
Lead with learning design, customer discovery, prioritization, requirements and follow-through. Your Stanford music-and-education project is a conversation connection supplied in the meeting transcript; clarify its exact artifact and outcome before describing it as shipped software.
KidsLoop gives you teaching/reporting and team leadership evidence; Edugo gives you AI language-product delivery; Rakuten gives you evidence-based scope decisions. Don’t describe yourself as a music-model researcher.
Study plan
90-minute first pass
15 min: product, users and vocabulary.
20 min: real-time transcription and education-dashboard papers.
20 min: reviews and failure scenarios.
25 min: write a one-page release plan for one learner.
10 min: explain your choices aloud in plain U.S. English.
Use the paper checkboxes and practice prompts below for deeper preparation.
02
Company story, reach and product reality
Separate public capability claims from evidence of customer value.
Official positioning
The story SORI tells
SORI positions itself around adaptive music that reacts to live context. It emphasizes responsiveness, synchronized sound and expressive performance, and presents musicians, media, advertising, smart glasses and vehicles as application areas. AI-MIDI is the concrete self-service product. The other application areas should not all be treated as commercial launches.
The company homepage displays “720,000+” artists worldwide. This is a company marketing claim with no public denominator, time window or paying/active-user breakdown found. Performance showcases establish public demonstrations, not retention or learning efficacy. No verified revenue, funding total, classroom reach or controlled learning-impact evidence was found in this research.
Ask: Does reach mean visitors, signups, converters or repeat users? What is the strongest evidence of useful outcomes?
Four people have public SORI associations and relevant research. This is not a verified complete current staff roster.
Confirmed public association
TaeGyun / Taegyun Kwon
Founder and CEO; KAIST MACLab records MS 2018, PhD 2024 and postdoctoral work before SORI. Research spans piano transcription and expressive performance. Start with real-time transcription, D3RM and VirtuosoNet.
Ask him: Which research capability is the foundation of the education release, and which aspects remain experimental?
His own site explicitly lists SORI-AI researcher from May 2026. Work connects score images, symbolic notation and audio. Publications cover U-MusT, Korean traditional notation and music reconstruction. The site contains an inconsistent award-year label; use the paper’s venue record rather than repeating that label.
Company-associated LinkedIn profile; personal page identifies a KAIST researcher focused on real-time musical interaction, sound design and multimodal analysis. Coauthor of flutist onset-timing work with Kwon and Juhan Nam. Her personal page alone does not establish a current SORI job title, so avoid inventing one.
Public profile describes joining SORI after speech-AI work at Samsung; GitHub also lists SORI. His publications concern sound-event detection and auditory understanding. Relevant to sensing and reliable audio interpretation, but not proof these papers power AI-MIDI.
Juhan Nam / KAIST MACLab: frequent coauthor in Kwon and Choi’s work. Dasaem Jeong / Sogang: faculty researcher and DongMin Kim’s listed advisor; works on music information retrieval, expression and creative AI. Their research explains the ecosystem, but no evidence here establishes that either is a SORI employee or a formal company advisor.
Research by a team member is not automatically SORI-owned IP or evidence of deployment. Read the abstract, task definition, data, metrics and limitations before the architecture.
Read first
Real-time piano transcription
Taegyun Kwon, Dasaem Jeong, Juhan Nam · 2024
What: Audio → note events with compact autoregressive models. Explores accuracy, model size, latency and unseen-piano evaluation.
PM takeaway: What can run during a live lesson? A strong offline result does not establish real-time readiness. Inspect latency and cross-dataset results.
Evidence type: Benchmark / architecture paper. Summaries are based on public abstracts, author pages and publication records, not reproduction of experiments.
Joonhyung Bae, Hyeyoon Cho and colleagues, including Taegyun Kwon · 2025
What: Combines score, video and motion capture in a web prototype informed by a professor’s teaching needs. Technical feasibility uses 109 performance datasets.
PM takeaway: Your closest education bridge. Feasibility and one expert’s needs are not proof of learning gains or broad market demand.
Evidence type: Prototype / feasibility study. Summaries are based on public abstracts, author pages and publication records, not reproduction of experiments.
Hounsu Kim, Taegyun Kwon, Juhan Nam · ICASSP 2025 / preprint
What: Refines piano-roll predictions using discrete denoising conditioned on acoustic features. Reports MAESTRO F1 improvements over its comparisons.
PM takeaway: Ask whether refinement’s compute cost is worthwhile for batch conversion versus live interaction. No evidence this is the current production model.
Evidence type: Benchmark paper. Summaries are based on public abstracts, author pages and publication records, not reproduction of experiments.
Jongmin Jung, Dongmin Kim and colleagues · 2025 preprint; researcher site lists 2026 TASLP version
What: Uses a shared tokenized representation for score images, audio, MIDI and MusicXML. Introduces 1,300+ hours of paired score/audio data and improves task baselines.
PM takeaway: A path to a coherent read–listen–edit experience. Dataset hours are research-data volume, not SORI user reach.
Evidence type: Multitask research. Summaries are based on public abstracts, author pages and publication records, not reproduction of experiments.
What: Studies video gesture and breath cues before an initial duet note. Preparatory cues predict roughly when; triggers refine timing. Includes expert interviews and cue data.
PM takeaway: Human coordination includes intent and timing, not just pitch. Initial-entry findings do not prove continuous accompaniment is solved.
Evidence type: Multimodal performance research. Summaries are based on public abstracts, author pages and publication records, not reproduction of experiments.
Dasaem Jeong, Taegyun Kwon, Yoojin Kim and colleagues · ISMIR 2019
What: Models expressive tempo, dynamics, articulation and pedaling from a score.
PM takeaway: Correct notes are not the same as a convincing performance. Compare model metrics with listening judgments.
Evidence type: Expressive-performance research. Summaries are based on public abstracts, author pages and publication records, not reproduction of experiments.
Hyemi Kim, Jiyun Park, Taegyun Kwon, Dasaem Jeong, Juhan Nam · 2023
What: Studies audio mixing for piano transcription when another instrument is present.
PM takeaway: A solo-piano benchmark cannot be generalized to arbitrary mixed audio. Segment realistic input conditions.
Evidence type: Domain robustness research. Summaries are based on public abstracts, author pages and publication records, not reproduction of experiments.
Danbinaerin Han, Mark Gotham, Dongmin Kim, Hannah Park, Sihun Lee, Dasaem Jeong · ISMIR 2024
What: Uses Transformers and a representation for reconstructing historical Korean court music.
PM takeaway: Notation and musical traditions differ. Preserve provenance and distinguish reconstruction from historical certainty.
Evidence type: Cultural-heritage research. Summaries are based on public abstracts, author pages and publication records, not reproduction of experiments.
Be able to explain the distinctions without claiming to implement the research.
PM analysis
Transcription versus generation
Transcription: infer musical events from a recording. Generation: create or complete musical material. Rendering: turn note events into sound. Expression: timing, loudness, articulation and pedal choices. These are different jobs and require different tests.
PM analysis
MIDI versus a readable score
MIDI is an event representation: pitch, timing and other controls. MusicXML preserves notation structure for score tools. Converting notes into a playable score also requires decisions about rhythm spelling, voices, rests and layout. Raw MIDI success does not establish readable notation or beginner playability.
PM analysis
Alignment, following and recognition
Alignment: match recording moments to score positions. Score following: keep track during live performance. OMR: recognize notation from an image. Polyphony: multiple simultaneous notes. Stem separation: isolate sources before analysis, with possible artifacts.
PM analysis
A product pipeline to reason about
Check input format, rights and recording suitability.
Choose a supported model and isolate a useful section.
Transcribe / align.
Show understandable preview and corrections.
Export or guide a practice activity.
Measure downstream usefulness and repeat use.
This is a PM model, not a disclosure of SORI’s internal architecture.
06
Products, experiences and users
One technology may serve different user jobs. Do not collapse them into one broad learner persona.
Current product / upcoming distinction
AI-MIDI web and API
Web: creators converting recordings into editable notes. API: developers embedding conversion in tools. Documentation describes HTTP and Python use with success-based API credit spending. Guitar/multi remain labeled beta; drums are not released. Audio-to-score appears as a waiting-list proposition on the main product page.
SORI lists AI–human piano performances and interactive exhibitions, including flute collaboration, score following, piano transcription and responsive accompaniment. These show live creative experiences. Concert audience, installation visitor and paying software user are distinct populations.
Small, self-selected discussions identify problems to investigate. They cannot establish prevalence, conversion rates or current defect rates.
Direct product mention / anecdote
Favorite-song motivation, long notes
A May 2025 Synthesia poster linked AI-MIDI as a way to learn songs they wanted to play and said harder songs could produce overlong notes. Other commenters compared tools and emphasized playable results.
Opportunity: a short phrase, duration correction, repeat/slow controls and a goal users care about. Validation: interview learners and observe whether the generated output is playable.
A January 2023 musicproduction discussion described AI-MIDI merging an ensemble into one track. Current documentation now advertises separate tracks for the paid Multi beta model. The old review is a historic need signal, not proof the same defect persists.
Opportunity: demonstrate supported separation, inspect individual tracks and communicate uncertainty.
A June 2024 discussion recommends separating stems before feeding them to AI-MIDI; other users discuss DAW integration, tempo and alternative converters.
Opportunity: explain when a clean solo source is enough versus when separation is useful; measure total cleanup time, not just conversion time.
A 2026 category discussion distinguishes editable MIDI from readable notation and calls out cleanup and pricing confusion. It is not a verified SORI customer review.
Opportunity: clarify output types and credit usage; offer teacher-ready notation only when quality and rights support it.
Loopy Pro’s audio-to-MIDI discussion includes user experiments with AI-MIDI and editing strategies. Use it for workflow questions and reproducing cases, not endorsement statistics. No formal customer interview sample or representative review dataset was found.
The CEO’s meeting explanation makes education a relevant release direction. It does not establish the target instrument, learner age or pedagogy.
Proposed MVP
P0 candidate: learn one favorite phrase
Hypothesis: an adult beginner with a piano or MIDI keyboard wants to practice a short passage from permitted audio. Start with a supported instrument, clear input and a teacher-reviewed phrase. Let the user hear the passage, see notes, slow playback, loop it and attempt it without the guide.
Learning outcome: independently perform that passage at a chosen tempo. Success: improvement on a later unguided attempt, plus return to meaningful practice. Favorite-song motivation is review-supported; this feature design is proposed.
Make one error visible: missed note, premature onset or long release. Show what happened, explain the likely musical consequence, demonstrate, then request another attempt. Do not shame learners with a score or claim a physical-technique diagnosis from audio alone.
Teacher review should distinguish model errors from learner errors before corrective feedback is treated as authoritative.
Proposed teacher workflow
Teacher-facing preparation
Prepare a short exercise with goal, prerequisite, approximate difficulty and suggested next step. Make source/output/edit history visible. Validate whether this saves preparation time without increasing review burden. Do not silently simplify a piece or misrepresent the original.
Research-inspired extension
Multimodal technique education
The pedagogy-first viewer paper studies making physical feedback concrete through synchronized motion, video and score. It is a prototype with limited pedagogical sampling. If SORI pursues similar work, begin with expert-defined observable behaviors and test camera reliability before recommending wrist/posture changes.
Use task language such as “Choose a short section,” “Listen to the preview,” and “Try again without the guide.” Test “MIDI,” “transcription,” “score,” “practice” and “credit” for comprehension. Avoid promising “perfect” conversion or implying a score is an assessment of the learner when it is confidence in the model output.
09
Tradeoffs, guardrails and failure modes
Show that you can preserve usefulness under imperfect conditions. These are design recommendations unless marked as published policy.
Technical / product tradeoff
Latency versus accuracy
Live accompaniment needs stable end-to-end timing; batch editing can tolerate refinement. Measure tail latency, jitter and recovery on target devices, not only average model time. Failure: a correct note arrives late and disrupts a performer. Mitigation: bounded supported conditions, safe silence/fallback and human control.
Noise, reverb, overlap, pedal, rapid passages and unusual timbre can change results. False notes, missing notes and wrong durations create different harms. Mitigation: input guidance, short previews, editable output and case-based acceptance criteria; do not extrapolate piano results to drums or every genre.
Preserving rubato and pedal supports faithful performance, but learners may need simplified timing. Make simplification an explicit alternate mode with labeled differences. A “clean” quantized result can erase expression; a faithful result can still be unplayable for a novice.
Published policy distinguishes web-transcription training consent from API processing. API inputs/outputs are stated not to be used for training and deleted within 24 hours, subject to retained operational records. Web training consent permits anonymized training copies with limitations on reversing trained-model influence. Explain these differences before upload.
Use owned/licensed material; public availability does not establish permission. For an education release, clarify student/guardian consent, recording visibility and retention with appropriate specialists.
Make separate API/web credit wallets and paid-action boundaries understandable. Public terms describe previews and failed jobs differently from successful paid use. Proposed checks: retries do not double-charge, failed jobs release holds, users can see job state and recover exports.
A transcription mistake must not become a learner penalty. Avoid simplistic talent rankings, causal claims of learning improvement, and posture/medical advice unsupported by appropriate observation. Prefer interpretable feedback, teacher override and testing across skill levels, devices and musical traditions.
10
Product stickiness and meaningful impact
These loops are product hypotheses. No public cohort-retention data was found.
PM analysis
Creator loop
Record idea → convert → inspect/edit → use in a project → return for the next idea. Stickiness comes from dependable exports, less cleanup and integration with existing tools. Measure second successful project and time to usable output, not upload volume alone.
PM analysis
Learner loop
Choose valued phrase → achievable practice → specific feedback → unguided success → next challenge. Persistent goals and progress can support return use. Avoid rewards that incentivize easy repetitions without transfer or hide lack of progress.
PM analysis
Teacher and developer loops
Teacher: prepare → assign → inspect attempts → adapt. Developer: integrate → monitor reliability → expand volume. Value depends on saved effort, quality and predictable costs. Exportability builds trust; trapping user material is not a healthy retention strategy.
PM analysis
Suggested scorecard
Activation: first usable MIDI/first completed practice task.
Learning: unguided pre/post task, later retention, unfamiliar variation.
Retention: repeat useful action by cohort and persona.
Business: paid conversion and compute/support cost per successful job.
Guardrails: invalid feedback, complaints, consent issues and duplicate charges.
These are proposed measures, not SORI’s existing KPIs.
11
AI test preparation: likely skills, not a leaked rubric
The test format is unknown. Prepare first for the PM and education needs described in your meeting.
Inferred from your meeting
Higher-confidence preparation
Define a learner and the problem to solve.
Choose one achievable year-end release.
Turn uncertain requests into requirements and non-goals.
Write native, understandable U.S. user copy.
Describe a learning activity and evidence of usefulness.
Coordinate research, design and engineering dependencies.
Unconfirmed possibilities
Possible supporting AI tasks
Use AI to investigate, draft or prototype; check the result.
Explain transcription versus generation and MIDI versus notation.
Compare latency, accuracy and cost.
Propose realistic input cases and failure handling.
Read a paper/API and extract product implications.
No evidence confirms a coding exam, model-training task, specific tool, or required music theory level.
Practice only
Practice case: deliver by year-end
Prompt: “Build a U.S.-focused music-learning experience using available transcription capability.”
Ask age, instrument, skill level, input source and target outcome.
Separate existing capability from new research dependencies.
Pick one short, supported learner task.
Define must-haves and explicit exclusions.
Set a discovery/prototype/closed-pilot/release sequence.
Write acceptance criteria, risk owners and stop conditions.
Explain what you cut to protect the date.
Do not assume unspecified weekly capacity or promise a delivery date before dependency review.
A concise answer structure
“For [specific user], the problem is [observed task]. I’d first validate [uncertainty]. The initial release would support [bounded experience], using [available capability]. I’d exclude [research-heavy scope]. We’d know it works through [user outcome], with [quality/rights guardrails]. These dependencies determine whether the date is credible.”
Practice questions — click to reveal answer cues
A user says the MIDI is accurate but useless. What do you do?
Observe the destination workflow. Determine whether the job is editing, notation, performance or beginner practice. Measure correction effort and playability rather than declaring success from note detection.
Would you prioritize multi-instrument conversion or a guided piano lesson?
Tie the choice to target segment, repeated demand, existing capability, learning outcome and delivery cost. Choose a bounded path supported by evidence; do not pick the more impressive demo by default.
How would you evaluate an AI-generated practice exercise?
Expert-check notes, difficulty and prerequisites; observe comprehension and task completion; measure unguided learning and later retention. Separate model confidence from mastery.
What happens if a model fails during live performance?
Design a rehearsed fallback, human override and recovery boundary. Validate tail latency and bad inputs. Do not have an unbounded model invent accompaniment while the performer loses control.
What is a good acceptance criterion?
Example: with a teacher-approved supported piano recording, a learner can select a short phrase, preview it, loop it and complete an unguided attempt. Agree quality and device thresholds with experts; mark illustrative numbers as provisional.
Why hire you instead of another ML researcher?
Explain your education and product contribution: select the right learning problem, define scope, write usable requirements, make tradeoffs and coordinate delivery. Complement research rather than claiming its expertise.
12
Study sequence and a practical test kit
A product manager should finish with decisions and artifacts, not a pile of architecture notes.
Session 1 · 60–90 min: inspect web product and API docs without purchasing; draw one user journey; list supported, beta and upcoming features.
Session 2 · 90 min: read the real-time and pedagogy-first abstracts, methods and limitations; record one capability, one constraint and one product implication per paper.
Session 3 · 60–90 min: read the linked community cases; separate historical bugs, current documentation and category needs. Draft five interview questions.
Session 4 · 90 min: produce a one-page opportunity brief, release scope, user flow, acceptance criteria and plain-English copy. Critique it for unsupported assumptions.
PM analysis
If you run hands-on comparisons
Use recordings you own or are licensed to upload. Try clean solo, pedal-heavy, rapid-note and mixed-source cases; keep the same excerpts across tools. Record model/date/input conditions, time, edit effort and export behavior. Do not pay, create credentials or accept training consent merely to complete this study guide.
This guide does not claim a hands-on conversion benchmark was performed.
PM analysis
Questions to resolve before the actual test
What is the output, time limit and evaluation rubric?
Which AI tools, external research and code are permitted?
Who is the learner and what is the learning objective?
Which capability is already deployable?
What team and constraints support the year-end target?
Can the test use synthetic/owned data rather than customer files?
13
Sources and verification boundaries
Research checked October 14, 2026. Sources are clickable; external links open in a new tab.
This guide uses official product/policy pages, researcher profiles, academic records, accessible paper abstracts and community discussions. It does not establish an exhaustive staff list, the production model architecture, actual interview questions, representative customer sentiment, or independent proof of the homepage reach claim. No proprietary white paper or test rubric was found.
Some author/publication pages contain inconsistent dates or version labels. Use the linked publisher/arXiv version history for bibliographic detail. Prior research may predate employment at SORI.