MegaCommand // MiniCommand Resurrection // MCLive

Could very well be.

I’ll have some time tonight to test and see where things fall apart. I’m hoping it’s just a misprint in the manual, otherwise I’ll have to cleverly disengage active sense during SYSEX transfers.

My assumption is that the manual is a bit unclear and that they just wanted to point out that the delay should be shortened in turbo mode, but that you should still only start sending active sense if there have been no other messages for the duration of the delay.

Again, please note that I don’t actually know what I am talking about with regards to Elektron’s turbo MIDI mode. :slight_smile:

Your guess is as good as mine :smile:

Have you been able to check whether TurboMIDI actually conforms to this or whether the description in the MD manual is imprecise?

1 Like

Peter, unfortunately there’s almost no documentation on the web for turbo midi. I’d have to get in touch with Elektron directly.

Finally got home to the MD. I just removed the active sense timer completely and Turbo midi is stable…
Looks like it’s not mandatory after all :slight_smile:

1 Like

Ah, and now I see why it is important.

Without active sense, the MD won’t switch back to 1x speed if you say turn the mini command off.
This could be a problem.

1 Like

Some Math this morning:

Don’t know why I never bothered to do this before, but here are data transfer rates for MCLive.

Max Transfer Rate (Bandwidth):

MIDI 1x = 31.25kbps/8 = 3.906kB/s
MIDI 4x (Turbo) = 31.25kbps/8 * 4 = 15.625kB/s

Data Size:

Kit = 1.136 kB
Pattern = 4.853 kB

For a write operations, we have to:

Get the current Kit
Get the current Pattern
(Insert the track data into the Kit and Pattern for n tracks)
Send the updated kit
Send the updated pattern

Therefore one write operation is approximately:
2 x (Kit + Pattern) = 10.842kB

Minimum Total time (Midi 1x) = 2.776 s
Minimum Total time (Midi 4x) = 0.694 s

If only we could break the 4x turbo midi barrier.

1 Like

Pasting this here:

This should help us determine what TurboMidi baud possible with ATMega64 inside the Minicommand.

AVR Baud Rate Calc

According to the table above 250K (8x Turbo) should be stable. I haven’t been able to get Turbo midi tests to succeed at this speed.

1 Like

I wish I still had mine. Wesen sent me a prototype as well as final unit. I loved then but ended up selling them when I quit music. Quit until I bought a rytm. I would love too see a similar device designed specifically for the AR.

Wesen used a 6n138 optocoupler on the MIDI In port.
This is pretty standard midi port configuration. I wonder if it’s the limiting factor on our baud rate of 4x.


Looks as though this is the likely candidate for the upper limit of 4x Turbo Midi.

According to a generic spec sheet for the 6n138 the max rise time is 10microseconds. 1/10microseconds = 100kHz equating to a max bandwidth of 100kbps in our case.

4x Turbo midi is 125kbps which is just over the spec.

8x Turbo midi would put us at 250kbps which is way over.

Of course I’d need to physically bypass the 6n138 to verify this.
(potential replacement part 6n135 through-hole. should be an easy swap).

1 Like

This quote from Olivier Gillet of Mutable Instruments might interest you:

The 6N137 is the one that gives the sharpest edges – even with a 10k pull-up. The 6N138 has soft positive edges, you’ll have to use a very low pull-up resistor (220). Both work with the appropriate choice of pull-up. I’m not sure why people prefer the 6N138 – maybe there are situations in which people want to avoid very hard edges running on their PCBs… Using a scope to monitor the signal edges helps a lot! I’ve found that the 6N138 are more sensitive when being manipulated – I’ve destroyed a few. So I’m a 6N137 guy.

(source: http://mutable-instruments.net/forum/discussion/5276/midi-input-with-optocouplers/p1)

3 Likes

I almost looked over the 6n137. Re-reading the spec sheet the rise time is in Nano Seconds not Micro Seconds!
This will be the component we need :slight_smile:

1 Like

Cool!

Daily Update:

Decided to take it a bit easier this weekend. Working on this for over a month now, sustained effort can certainly wear you down a bit!

Bug Fixes:
Pattern and kit positions are now set explicitly before transmitting a pattern + kit. Previously we were relying on the md using the kit original position field, but it appears that this didn’t always work.
This has fixed the ‘sometimes a pattern didn’t write problem’ and another annoying bug whereby you couldn’t write to a blank pattern on startup. Pretty happy about this.

I won’t receive the 6n307 optocoupler until Monday so I will attempt to fix turbo-midi active sense in the meantime. Then hopefully we can connect at 8x turbo speed.

3 Likes

Just swapped out the optocoupler.

Everything working fine, still cannot connect above 4x.

However i’ve discovered that I can establish an 8x connection between turbo-midi interface and the minicommand.
Unfortunately I do not know if this was the case before.

So either the current coming from the MD is not enough and I need to modify the value of the pullup resistor or something else is at play here.

Just swapped out the pull up resistor for 1k and 10k. Both work fine for general midi, but no improvement on turbo
speed between MD and Minicommand.

Also just tested Minicommand and Analog 4. Cannot establish Turbo 8x either.

2 Likes

I got in touch with Elektron and they kindly provided me with a TurboMidi spec document.
Covers the details a little more clearly than the MD manual.

Some investigations last night lead me to discover that it’s the speed handshaking protocol with the MD that is the problem.

MIDI_SPEEDNEG (MASTER)

0xF0,0x00,0x20,0x3C,0x00,0x00,0x12,SPEED1,SPEED2,0xF7

SPEED1 is the speed used to test the connection.
SPEED2 is the speed used if the connection test is successful.

If SPEED2 is a certified speed SPEED1 may equal SPEED2, otherwise SPEED1 > SPEED2. If SPEED2 equals 1 no test is required, both devices select 1× MIDI speed.

I’ve been sending SPEED1= 7 (Turbo 8x) and SPEED2 = 7 (Turbo 8x) to the MD but I never receive an acknowledgement. If I send this to the Turbo Midi interface I do receive an acknowledgement.

The MD wants to run the first speed test at a higher speed and then drop down to speed2 (and set speed2 as the turbo speed).
But I can’t find a combination of speeds that work for 8x Turbo.

For example. If I send speed1 = 7 and speed2 = 6 to the MD. The first speed test will succeed at 8x then we will drop down in to 6.7x turbo speed. The 6.7x link will work for a few seconds but breaks because the minicommand is unstable at this baud rate.

I need to do some Midi packet sniffing between the Turbo Midi interface and the MD tonight to see what combination of speeds will get me to 8x. I tried a few logical combinations but I never receive an acknowledgement from the MD, even though the MD advertises that all the Turbo speeds are certified.

3 Likes

Here’s the SYSEX packet sniffing:
I’m using C6 app to force an 8x turbo midi connection through the tm-1 to the MD.

Tm1 -> MD

00 F0 00 20 3C 04 00 03 07 F7 (TM-1 MESSAGE UNSPECIFIED)
00 F0 00 20 3C 00 00 10 F7 (MIDI_SPEEDREQ)
00 F0 00 20 3C 00 00 12 08 07 F7 (MIDI_SPEEDNEG turbo 10x turbo 8x )
00 F0 00 20 3C 00 00 12 07 06 F7 (MIDI_SPEEDNEG turbo 8x turbo 6.7x )

MD -> Tm1

00 F0 00 20 3C 00 00 11 7F 01 0F 00 F7 (MIDI_SPEEDANSWER)
00 F0 00 20 3C 00 00 13 F7 (MIDI_SPEEDACK )

You can see that the TM-1 first tries to perform speed handshake at speed1=08 (turbo 10x) and speed2=07 (turbo 8x).
No acknowledgement is received so it tries a second time with speed1=07 (turbo 8x) and speed2=06 (turbo 6.7x)

When I send speed 07 (turbo 8x) and speed 06 (turbo 6.7x) to the MD the first test at 07 (turbo 8x) succeeds. Now I don’t know how to get the MD to stick to this speed. If we perform the second speed test the speed drops down to 6.7x as per specification.

There must be something i’ve missed. But I can’t observe the packets when the midi speed switches above 1x after the MIDI_SPEEDACK.

Any suggestions guys?

1 Like

Not really able to offer much other than basic sanity checks, so at risk of stating the bleedingly obvious… there’s nothing in your MD GLOBAL settings that might be causing the problems? Just re-reading some of the stuff in the MD manual about turbo midi…

CURRENT SPEED shows the current multiplier of the MIDI transfer rate. When not connected
to a device using Turbo protocol compatible software, the speed will therefore be
x1.0. Select which NEGOTIATE speed you want use. The Machinedrum defaults to x10,
but this value can be lowered should it be needed. Press the [ENTER/YES] button to
start to negotiate. The CURRENT SPEED value will display the change of the MIDI
transfer rate.

• If you link two Machinedrums together where one of them is a MKI model, you
might not be able to get a CURRENT SPEED value exceeding 6.7x.

1 Like

Looks like I got my initial testing wrong.

The link was not stable using a splitter and the TM-1 couldn’t establish the 8x link so it was dropping it down to 6.7

Re-testing everything. (i wrote a sysex packet sniffer for the minicommand)

Speed Negotiations that work:
9 7 ( 13.33x 8x)
8 7 (10x 8x)
7 6 ( 8x 6.77x)

Unfortunately speed tests fail for 8 7. Which leaves us only with 9 7.
With tuning the error rate at 13.33x is 3% So there’s a small chance this will work, but I have not been able to succeed yet.

1 Like

Not looking good for 8x turbo midi folks :cry:. I’ve attempted speed tests at 5x (with error rate of 1.5%) and they fail every time. This means we can’t perform the handshake necessary to get the machinedrum to set the turbo midi speed to 8x. Even though speed tests at 8x work flawlessly,

I’ve got a support ticket open with Elektron to see if they have any suggestions.

1 Like