JP80x0 midi to coefficient mapping tables

Pitch

Midi	Pitch
0	1555
1	1647
2	1745
3	1849
4	1959
5	2075
6	2198
7	2329
8	2468
9	2615
10	2770
11	2935
12	3110
13	3295
14	3491
15	3698
16	3918
17	4151
18	4397
19	4658
20	4936
21	5230
22	5541
23	5871
24	6220
25	6590
26	6982
27	7396
28	7836
29	8302
30	8794
31	9317
32	9873
33	10460
34	11082
35	11742
36	12441
37	13181
38	13965
39	14792
40	15672
41	16604
42	17589
43	18635
44	19747
45	20921
46	22164
47	23485
48	24883
49	26362
50	27930
51	29585
52	31345
53	33209
54	35179
55	37270
56	39494
57	41842
58	44329
59	46970
60	49767
61	52725
62	55860
63	59171
64	62691
65	66418
66	70358
67	74541
68	78988
69	83684
70	88659
71	93941
72	99534
73	105450
74	111720
75	118342
76	125382
77	132836
78	140716
79	149082
80	157976
81	167368
82	177318
83	187882
84	199068
85	210900
86	223440
87	236684
88	250764
89	265672
90	281432
91	298164
92	315952
93	334736
94	354636
95	375764
96	398136
97	421800
98	446880
99	473368
100	501528
101	531344
102	562864
103	596328
104	631904
105	669472
106	709272
107	751528
108	796272
109	843600
110	893760
111	946736
112	1003056
113	1062688
114	1125728
115	1192656
116	1263808
117	1338944

 

Detune:

Midi	uC
0	1
1	1
2	2
3	2
4	3
5	3
6	4
7	4
8	5
9	5
10	6
11	6
12	7
13	7
14	8
15	8
16	9
17	9
18	10
19	10
20	11
21	11
22	12
23	12
24	13
25	13
26	14
27	14
28	15
29	15
30	16
31	16
32	17
33	17
34	18
35	18
36	19
37	19
38	20
39	20
40	21
41	21
42	22
43	22
44	23
45	23
46	24
47	24
48	25
49	25
50	26
51	26
52	27
53	27
54	28
55	28
56	29
57	29
58	30
59	30
60	31
61	31
62	32
63	32
64	33
65	34
66	35
67	36
68	37
69	38
70	39
71	40
72	41
73	42
74	43
75	44
76	45
77	46
78	47
79	48
80	49
81	51
82	53
83	55
84	57
85	59
86	61
87	63
88	65
89	67
90	69
91	71
92	73
93	75
94	77
95	79
96	81
97	83
98	85
99	87
100	89
101	91
102	93
103	95
104	97
105	99
106	101
107	103
108	105
109	107
110	109
111	111
112	113
113	115
114	117
115	119
116	121
117	123
118	125
119	127
120	129
121	137
122	145
123	153
124	169
125	193
126	225
127	321

 

Mix

Midi	Mix
0	102400
1	118784
2	135168
3	151552
4	167936
5	184320
6	200704
7	217088
8	233472
9	249856
10	266240
11	282624
12	299008
13	315392
14	331776
15	348160
16	364544
17	380928
18	397312
19	413696
20	430080
21	446464
22	462848
23	479232
24	495616
25	512000
26	528384
27	544768
28	561152
29	577536
30	593920
31	610304
32	626688
33	643072
34	659456
35	675840
36	692224
37	708608
38	724992
39	741376
40	757760
41	774144
42	790528
43	806912
44	823296
45	839680
46	856064
47	872448
48	888832
49	905216
50	921600
51	937984
52	954368
53	970752
54	987136
55	1003520
56	1019904
57	1036288
58	1052672
59	1069056
60	1085440
61	1101824
62	1118208
63	1134592
64	1150976
65	1167360
66	1183744
67	1200128
68	1216512
69	1232896
70	1249280
71	1265664
72	1282048
73	1298432
74	1314816
75	1331200
76	1347584
77	1363968
78	1380352
79	1396736
80	1413120
81	1429504
82	1445888
83	1462272
84	1478656
85	1495040
86	1511424
87	1527808
88	1544192
89	1560576
90	1576960
91	1593344
92	1609728
93	1626112
94	1642496
95	1658880
96	1675264
97	1691648
98	1708032
99	1724416
100	1740800
101	1757184
102	1773568
103	1789952
104	1806336
105	1822720
106	1839104
107	1855488
108	1871872
109	1888256
110	1904640
111	1921024
112	1937408
113	1953792
114	1970176
115	1986560
116	2002944
117	2019328
118	2035712
119	2052096
120	2068480
121	2084864
122	2101248
123	2117632
124	2134016
125	2150400
126	2166784
127	2183168

 

Midi proxy/Voice assigner

A tiny but exciting win today - I wrote the first line for the XM8 main controller, more specifically a midi proxy/distributor that copies all incoming midi to separate outs. This will let me support multiple voice cards without rewriting the interface (yet).

More importantly though, the proxy does a round robin voice assignment, so instead of forwarding note on/off messages directly, it sends the next note on to the least recently used voice (and makes sure to send note off first, at least for now. This paves the way for polyphony, which is something I've litteraly been waiting a decade for!

As for the communication, I use the serial TX and RX pins directly, from a Teensy 4.1 TX to a Teensy 4.0 RX. It worked immediately, no external components necessary.

It should also be possible to send MIDI at a higher bitrate, right now it runs at the standard 31250bps, I expect that at least 115200 should be problem free.

Don't cut the red wire!

 

I'm actually reusing the original voice card controller prototype board for the MIDI proxy, as it has everything needed for receiving MIDI onboard and exposes pins for all the teensy pins. 

Next up is connecting two full voice cards. I can't wait, this is sooo cool!
 

Gritty noise on panner and oscillator mix volume pots

While testing, I heard a lot of digital sounding noise on the output when turning the volume or pan pots. I first suspected it to be digital noise from the midi connection.

After extensive testing, I've concluded that this is not noise per se, instead it has two causes:
- The midi input is stepped, each pot has max 128 positions
- The CV is linear, so changes are more audible when the volume is low

I tried adding filtering of the output CVs, e.g. making the change take more time even if the midi said to change things instantly. This worked fairly well but when turning the volume pot slowly I could still hear stepping at the lower end.

This is because the steps are of equal size, but audio loudness is exponential. A one unit change when the volume is low is much larger and audible than a one unit change when the volume is high.

I have already added support for response curves, changing to an "exp_1" curve took care of most of the stepping.

As for the filtering, a "max 64 units change per update" gave a good result. 256 is too much. 

Right now the filtering happens at the DAC update, it should be moved to the midi side as the rest of the matrix works as it should.

Envelope time curve - midi mapping

After looking at the transfer function of the Little Phatty, I decided to redo the mapping for my XM8. In the same way as with the level function, I'd like to make it dynamically changeable, to be able to dial in the perfect transfer function per envelope.

The LP has an envelope time (per the manual) of 1ms to 10s (10.000ms).

The midi transfer function, with f(x) in ms, is thus

f(x) = 10^(x/(127/4)), for x=0 to 127

To get a changeable function, I looked at my previous work on envelope curves. I have a general function with built in steepness.

A function starting at 0,0 and ending at 1,1 with variable steepness can be written as

f(x) = a * 10^(steepness * x) - a

where

a = 1/((10^steepness) - 1)

Extending this to a case where we want a highest value for input and output, we get

f(x) = Y_max * ( a * 10^(steepness * (x/X_max)) - a)

where again

a = 1/((10^steepness) - 1)

Unlike the LP function, this starts at 0, since I use a 0-indexed time where 0 is the shortest possible time, around 1ms. If we want a different starting point, we get

f(x) = Y_min + (Y_max - Y_min) * (a * 10^(steepness * (x/X_max)) - a)

Fooled by running status. Again and again.

The midi protocol is not very complex. But one thing keeps making me trip: Running statuses. You can send a status byte, and as long as you don't send a new status byte you may keep sending data bytes for the same status. This is very convenient when sending for example filter sweeps etc.

In my work on the MPG-200 this has made me trip several times. Because:

The source for my midi data has mostly been my Moog Little Phatty. It sends running statuses of course. But when I reboot my mpg-200 without restarting the LP or playing a note, the LP don't send the status message again, and the MPG-200, having just booted, has no way of knowing what it is receiving as it has not seen any status message. It has fooled me more than once.

Today it happened again, but in a more subtle way. I have spent the last week trying to figure out a very strange bug I noticed after a large refactoring of the MPG-200 code: After changing the CC for the filter cutoff using sysex, things worked fine when sending the correct CC from my sysex/web midi based pg-200. But after rebooting nothing worked. Sending a sysex clear memory somehow reset things and the CC started working again.

I stripped down the program to the minimum and it still happened. I discovered though, that sending a midi note on had the same effect. Today I had time to think more thoroughly about it and came to the conclusion that it could not be the part of the program that treats the received bytes, it had to happen on reception. So I hooked up my logic probe to the midi rx line and watched what came into the MPG-200.

Guess what - after a restart, the web gui, knowing nothing about the restart, did not resend the status message. That explained almost everything, I had tripped in the running status issue again. But a little more research uncovered a few other interesting things:

Sending a midi note on from the LP actually reset the running status, so the status message was sent again. This surprised me, how does the web gui know that the LP has sent a midi on? I also tried to refresh the web gui to 'restart' the midi interface, but this did NOT work, it still did not send a new status message.

Then it dawned on me. I am using the LP as my midi interface. It is the LP that holds the state, NOT the web midi adapter! So even if the web midi did restart, the LP knew it was currently sending a particular CC, and so did not resent the status - and of course sending a note on merged into the same data stream and made the LP resent the CC status later.

Oh well, I am just glad I figured this out, even though it's a bit embarrassing.