MT-32 vs. CM-32 et al.

[Cloudschatze]

The biggest problem with adding the trimpot circuit is that it is not possible to get the MT-32 to output the necessary -60dB sine wave, so you're left doing the adjustment by ear. I wonder if it is possible to generate the appropriate sine via MIDI and a custom patch...

Pardon my ignorance, but why is this not possible via the Test Mode?

[Laust]

Well, datasheet says to use a -60dB sine wave, but this is not what the test mode offers. Also, the timesharing nature of how the DAC is used means you can't actually measure the output directly at the DAC (well you could, but you'd only see the sine wave 1/8th of the time). Instead it would have to be the at the sample and hold chip.

Besides, it's not even been proven, that the differential linearity error and a lack of trimming is the problem with the old MT-32. The datasheet quite unequivocally states that "Differential linearity error at bipolar zero is guaranteed to meet data sheet specifications without any external adjustment." (and identical values are cited for the PCM54 and 55), so claiming otherwise really needs to be backed up with hard evidence. That means tests of the PCM54 and PCM55 in the same circuit, not merely comparing two different (if similar) synths and concluding that the difference in sound characteristics must be the DAC, just because it is a different component.

I think I'll try grounding the trim pin on the DAC with a 10nF capacitor as suggested in the datasheet and see if it makes any appreciable difference in audio quality. Leaving pins floating is rarely a good idea and I wouldn't be surprised if it can pick up noise this way.

[NewRisingSUn]

Besides, it's not even been proven, that the differential linearity error and a lack of trimming is the problem with the old MT-32.

Very true. Consider them hypotheses made in lack of proper measuring equipment.

Besides, it's not even been proven, that the differential linearity error and a lack of trimming is the problem with the old MT-32.

That, and the fact that the DAC's bit 0 is grounded (with all other bits shifted one bit to the left, dropping bit 14, as seen in the schematic), which either makes the DNL worse (if it is indeed the DNL that is the problem), or it picks up noise via that pin as well.

The "bare" DNL difference should be between the CM-32L and the CM-32LN/CM-500.

[Laust]

Did you mean unconnected? bit0 is not grounded in my MT-32.

[NewRisingSUn]

Maybe it should be.
Try grounding either bit0/trim/both, and tell us how this affects the output. If it turns out that this alone will improve the sound quality, it would indeed be nice.

[Cloudschatze]

I compared the MIDI implementations for the MT-32, CM-32L and CM-500, looking for differences that might cause the vibrato issue. I found these in the Voice Parameters, though I'm not sure if they're even part of the problem:

MT-32:[/u] 00 00 09 P-ENV VELO SENS (0 - 100)
CM-32L:[/u] 00 00 09 P-ENV VELO SENS (0 - 100)
CM-500:[/u] 00 00 09 P-ENV VELO SENS (0 - 3)

MT-32:[/u] 00 00 1C TVF ENV DEPTH (0 - 100)
CM-32L:[/u] 00 00 1C TVF ENV DEPTH (0 - 100)
CM-500:[/u] 00 00 1C dummy (ignored)

Someone ought to play around with the MT-32 values, and see if they have any appreciable effect on the vibrato of a particular patch.



Unrelated, but I saw this in a USENET post and decided to investigate:

For folks with the money, I highly recommend the SC-55mkII for
the best game and commercial .mid file sound.  (The SC-88 unfortunately
has the default Cutoff Frequency (a GS thing) set just a hair
lower which has a subtle distancing effect.  It is just enough
to cut a complete overtone out in the SC-55 Piano 1 midrange (only
2 units of adjustment does bring it back but that's not too helpfull
with games and commercial files which use GS Reset).

It's not just the Cutoff Frequency, but a couple of other parameters as well. Roland increased the ranges for these parameters, but left the default values the same, which effectively makes them "lower" values. Anyway...

[NewRisingSUn]

looking for differences that might cause the vibrato issue. I found these in the Voice Parameters, though I'm not sure if they're even part of the problem:

No, they're not part of the problem. Vibrato is controlled by parameters 0x14/0x15/0x16 (P-LFO), and for some reason, the CM-32LN/CM-500 is interpreting parameter 0x14 (P-LFO RATE) differently.

Try grounding either bit0/trim/both, and tell us how this affects the output.

Any luck?

[Cloudschatze]

looking for differences that might cause the vibrato issue. I found these in the Voice Parameters, though I'm not sure if they're even part of the problem:

No, they're not part of the problem. Vibrato is controlled by parameters 0x14/0x15/0x16 (P-LFO), and for some reason, the CM-32LN/CM-500 is interpreting parameter 0x14 (P-LFO RATE) differently.

Hmm. Is the vibrato issue common to all patches (custom and built-in)? I'm wondering if it's not an issue with the interpretation, but rather, a mistake in the programming of the default, built-in patches.

[NewRisingSUn]

Is the vibrato issue common to all patches (custom and built-in)?

Not to those which have the P-LFOs set to zero --- those have no vibrato, and thus there's no difference (duh). Otherwise, yes. I'm testing by uploading the same timbre to the Timbre Temp Memory, and comparing the results. It's a really matter of interpreting the P-LFO values; the default patches are the same (and if you remember my SQ1 recordings, the custom "velo-brass" has more vibrato on the 500 as well).

So far I have not been able to come up with a formula like CM500value = factor*CM32value. I find the results of value 0x14 quite unpredictable on both units --- setting it to 0 of course completely disables vibrato, but setting it to 0x63 or 0x64 has about the same effect.

[Cloudschatze]

I know I've asked this before, but is the timing of the P-LFO determined by the nearby X-tal oscillator?

[NewRisingSUn]

Unlikely, given that the sound generation is all digital.

[Cloudschatze]

I wonder if the CM-500 MIDI implementation is incorrect, and the P-LFO ranges are not 0 - 100, as specified.

If I connect both the CM-500 and MT-32, select and play any patch, and use the mod-wheel, the CM-500 output is going to oscillate faster than the MT-32, is this correct?

[NewRisingSUn]

Faster, yes, but not more intense. (George Lucas wouldn't be happy). I guess I should make this very clear, also in the Wikipedia article: the CM-500 does not oscillate stronger (with a higher amplitude); it oscillates faster, way too fast.

[Cloudschatze]

Is the MT-32 photo alright, btw?

[NewRisingSUn]

I originally expected more of a frontal view where you can see the display, but this one has its qualities as well, because you can make out the dimensions better.

[Cloudschatze]

I think I captured the MT-32's "good side".

With the light-box I was using, a direct, frontal shot could not be had, and from a higher angle, the MT-32's display reflects an image of the camera lens.

My only problem with the photo is the shadow on the right-hand side, which wouldn't have been there had someone not removed the reflector from the light-box kit.

[Cloudschatze]

Faster, yes, but not more intense. (George Lucas wouldn't be happy). I guess I should make this very clear, also in the Wikipedia article: the CM-500 does not oscillate stronger (with a higher amplitude); it oscillates faster, way too fast.

If anyone is interested, or isn't sure what this all about, here is an example of a tone played back on both a CM-64 and CM-500 using the exact same modulation values.

MT-32/LAPC-I/CM-32L/CM-64 - "Correct" modulation.
CM-500/CM-32LN/LAPC-N(?) - "Someone at Roland didn't know what they were doing" modulation.

[Cloudschatze]

I e-mailed Roland Japan regarding the modulation issue. They verified the problem with one of their test modules, but stated that product support for the CM units ended around fifteen years ago. C'est la vie.

[NewRisingSUn]

Roland obviously never knows what they're doing. After all, there also were some (subtler) differences between the first and second MT-32 generations as well.

[Cloudschatze]

Pardon the ignorance...

I'm curious about something. In an 01 MT-32, the LA32 chip outputs fifteen data bits (SD1 - SD15), all of which are all connected to the DAC. Since SD0 is not being used for data output, the effective resolution is 15-bit.

Does the 00 MT-32 send data on SD0? If not, would its effective resolution then be 14-bit, given the unconnected SD14?