What
Are We Talking About?
Why M1D2? - THE GOAL
- To grow the marketplace by providing ALL customers with a more robust
feature set.
Why MIDI2? The Value Proposition
- M1D2 provides a high performance and flexible digital communications
protocol for developers of active and passive MIDI applications.
Who Is The Customer?
Customer Needs
- Products that are easier to use
- Flexibility (screw the limitations!)
- Higher Performance
Challenges...
- Perception of the word MIDI
- Inconsistencies in implementation
- Organizational Bureaucracy (MMA, IA-SIG, SMPTE, AES, WHQL, MOUSE,
BBQ)
- Reliance on Proprietary Entities for Progress
Recommendations
New Name for MIDI 2
- M1D2
- Serial EXpansion Protocol Of Tomorrow
- Computer Related Audio Protocol
Barriers
- Technical Issues
- Fixes to present specifications
- Additions to present specification
- Marketing Issues
- Public Relations
- Business Development
- Executive Issues (MMA)
PROPOSING THE SOLUTION
(Step 1)
- Assist in development of MRD
- Marketing Requirements Document
Technical Issues
Controllers
- Not enough controllers (Whammy bar etc…)
- Not enough standardized controllers,
poorly defined
- Slurs, Tonguing controllers (VL, VA techniques)
- Control for mixing consoles
Parameters - aux send, EQ etc…
Joy stick controller
- Controller streams aren’t high enough resolution
- But still need data thinning - ie. fade
Controllers Continued...
- No accommodation for 3D
- No accommodation for DSP control
-Needs property set for DSP
- Bank select is not standardized
- NRPNs not standardized
General Note Information...
- Not enough micro tuning tables / flexibility - scales
- Not enough notes (triggers for automation, etc...)
The Wire
- Half duplex problem.
- Serial Speed is too slow.
- Data Streams bogs down due to high quantity of controller data - i.e.
fade
The File Format
- No multi format file handling (MIDI + audio /video/etc.),
- Too many individual file formats,
- Need universal looping formats,
- Double byte character sets,
- Multiple time signatures
Ease of Use!
- Not plug and play - -full identification
- Instrumentation
- Patches
- Device ID
- Sample Rate
- Polyphony
Functionality Issues
- Sys-ex SUCKS
- Too much reliance on sys-ex
- Every voice parameter should get its own controller: Sys-ex becomes
unnecessary
Catch All
- Assignable priority system - ie. channel 10 shouldn’t always be #1
- Not time-stamped
- SDS not widely implemented on computers - fix is DLS?
Catch All II
- Doesn’t sync easily
- SMPTE too coarse - need sample
accurate
- No MIDI file copy protection
- printing, notation display, file
modification "save as…"
- Note Events vs. Channel events
- Don’t affect everything on one
channel
- Too few channels
Business Development Issues
- Computer companies are not talking with Music companies
- Hardware Page is obsolete -
- 5 pin din is specified
- Need more industry involvement in MMA
Biz Dev. II
- Proprietary nature of GM/GS and XG creates problems for developers
- Protocol is linked to hardware
- Too Difficult to Use
- Too many jack formats, sometimes requires adapters etc…
Marketing Issues
- Bad reputation / perception
- Motivating MMA Members
- Name is vague - or not vague enough
PROPOSING THE SOLUTION
(Step 2)
- Assist in development of MRD
- Marketing Requirements Document
- Summarize not only for BBQ - but for submission to the MMA Tech board
- CALL FOR ACTION
- Submissions from BBQ attendees for any further discussion points
- Endorsement of M1D2 petition.
section 5 |
