/
notes.txt
105 lines (67 loc) · 3.21 KB
/
notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
Yes, you can reprogram many controllers to put out whatever numbers you need, but wouldn't you rather work with meaningful descriptions, and let the computer handle the numbers?
Voice numbers - different on device, plus MIDI from 0 and MIDI from 1
Also a format for describing MIDI device ins and outs and labeling them, with fields for documentation. (And an interface for creating at least the inputs.)
Public APIs only
Allow help text for all parts
Matching device/ channel/ messge type
Sensible default names for CCs
Eventually graphics options - knobs, faders, light intensities
Program changes will need to combine multiple values. Other things might too
Alt display for abstractions
Flag for hardware / software
Pachinko markup processing model
MIDI-CI is a standard for describing options and having MIDI devices communicate. It's built with the devices in mind more than human interfaces. Some aspects of MIDI-CI duplicate with this, and in the long run it may be possible to generate some MIDI-CI information from this. However, MIDI-CI is also not yet widely used.
Inherited attributes/categories - containers share atomic info unless overridden
RFC 6295 is a wire standard, not a description.
Note by note descriptions for drums, samples, etc.
Support both hex and dec, flag if don't match
What does polyphonic aftertouch look like?
Include date updated in XML - for structure, not just file
Versioning? URL for download latest at
link to manufacturers page, manual, alt page
General MIDI as useful default
Related CCs - groups?
Banks of switches and knobs
Splitting keyboards
Less patch cable metaphor, more listening for
Indicate default or custom
Make it easier to report if something has changed - test against defaults
Describe physical connectors?
Links to graphics, manuals, maybe block diagrams
Warnings and notes
Thru - indicate JD-08 headache
Containers hierarchies to override defaults? Or named sets of overrides
Model names and numbers
Labels for configurable patterns, like waveforms
Indicators for steps
Note features not reachable by midi
Effects pedals
Allow descriptions of musical devices with no MIDI
Local device setip - multiple DIN?
XSLT for a pretty report, maybe JSON conversion
Github repo for xml descriptions of midi devices. BSD-2 license for code. Xml-midi-device-descriptions
Quantize pitch and rhythm as transforms. Streaming vs static
Description linter
WebMIDI pipes
define inputs to outputs as groups
inputs and outputs don't all have to be to the same device
inputs and outputs can be scalable
inputs and outputs can be recorded
allow inputs to change labels on the piping browser
Simple pipes
Inserting functions
Sort of a remixing board for data
Targets as transforms
Always labels
Need to figure out naming or numbering conventions and conversions
Transposition as a simple content transform
Transform and transfer
Chord thickening and thinning as transform
Note on and note off transforms - matching or not?
Connecting transformations, listening to each other, sometimes finishing.
Sequences of transformations becoming available and not available.
A place for dropped things.
Reporting on the flow.
Fast things, like pitch bends
Events need to remember their sources
Discard or pass along?