MegaCommand // MiniCommand Resurrection // MCLive

Well never say, never.

Thanks to Anders and Olle, Frederick from Elektron for helping out with this one.
It turns out you can force the Elektron devices to communicate at a specified speed using the following SYSEX message:
MIDI_SPEEDPUSH

0xF0,0x00,0x20,0x3C,0x00,0x00,0x20,SPEED,0xF7

No celebrations just yet. Long SYSEX messages such as Kit and Pattern dumps are not being received correctly and I had to re-enable Active Sense to get this hack to work (so all those bugs are back). MIDIClock and short SYSEX is working though, surprisingly.

3 Likes

From preliminary investigation it looks as though the interrupts are not fast enough to service the Midi data at 8x Turbo (250kbit baud) for the 16Mhz processor…

I wrote a quick workaround using a while loop to read in an entire sysex message by detecting new bytes on the UART (rather than wait for interrupts to trigger the ingestion of each new byte of the message) and this has fixed the pattern and kit reception errors. So the 16Mhz processor is definitely capable of reading in data at this speed.

However it looks like other midi data is choking up the link and some standard midi messages are not being received when the traffic is heavy. My interpretation is that the processor is performing too much context switching, because it has to constantly service interrupts for incoming MIDI data. At lower baud rate this was less of the problem.

I will keep playing around with this for a little while as I feel the extra speed is worth the effort. If not, I will save Turbo 8x for Mcv2 and proceed with releasing the beta.

2 Likes

Okay (here i go again) I just came up with a more elegant solution, keep the interrupt running as long as there are bytes available on the UART port. This will prevent interrupts from being missed, in the event that the current service routine did not end before the next Byte was received.

This seems to be very stable so far :slight_smile:

4 Likes

Guys, I did it.

We’re stable at 8x Turbo MIDI.

I had to re-optimize the interrupt service routines to handle reading data at 8x Turbo from input1 and 1x midi from input 2. This means we can run at 8x Turbo speed and also sync to the external clock on the 2nd input without any stability issues.

I also fixed the active sensing bugs.

6 Likes

\o/

So there was a small regression in my code and I spent a day working out why we were still getting SYSEX 1 errors.
Turns out my transmit buffer was too small (counter-intuitvely I assumed that a faster connection speed would negate the need for a larger buffer).

Correcting this, I haven’t seen a SYSEX error in over 12 hours of testing, which means we are truly stable at all 3 MIDI speeds (1x, 4x and 8x). Infact, there is no performance degradation as you increase turbo speed or sync to the external clock, which is the big win here.

With the work done on Turbo Midi and interrupts i’ve managed to shave off 3KB of program size.
So we’re sitting at 57,350KB with 4.65KB to spare.
That’s a significant amount of headroom for bug fixes and possible more features later on :slight_smile:

I’m really satisfied where things are at right now. I feel it’s robust enough for a live performance.

I now need to finish the demo patterns and work on the long-ago promised demonstration /instructional videos.

6 Likes

:golfer::bug:

[whack those bugs]

nice!

:+1::+1::smiley:

1 Like

Some more thoughts today.

Looking at the code it should be relatively easy to switch from FAT file system to -> SDCard raw.
I’d need to create a light weight filesystem plus a mechanism for transferring files over Midi.

I won’t include this in the first release, but I’d imagine this would save us a huge amount of program flash. and potentially make it possible to boot different firmwares from the bootloader.

3 Likes

:mind_blown:

:slight_smile:

…that would be unreal if it works out… yeah I remember removing the sdcard libraries from some of my old firmwares just to shoehorn in more of my own code and it did free up a good chunk of flash. IIRC there’s a couple of other minor things that are read from the SD at boot time, I think maybe the merge settings? but those are trivial to workaround

2 Likes

Well, if I write a simple filesystem that is compatible with wesen’s SDCard wrapper, all your original functionality will still work, it just wont be fat16/32 compatible.

1 Like

Question for the MiniCommand heads as it’s been a while for me…

Anyone coded anything for Midi Clock Interrupt to handle stopping, loading, resyncing for slave devices?

I’ve got a need for this scenario, so might give it a go, just thought I’d check first with you cats.

Examples:

Mungo Sync2: http://mungo.com.au/sync2.html

TouchProOne: http://www.ebay.com/itm/Touchprone-Interrupt-Inline-Synced-MIDI-Start-Stop-/162014222558

1 Like

Yeah, MCLive uses the MidiClock heavily for synchronised tasks.

Here’s what you need to do to resync on the next bar (i.e. 16 x 16th notes).

void wait_then_sync() {
int offset = 0;
//Do nothing (greedily occupy the processor) until we reach the next 16th step.
while (((MidiClock.div32th_counter + offset) % (16 * 2)) != 0);

//Instruct the slave to stop and restart the sequencer.
MidiUart.putc_immediate(MIDI_STOP);
MidiUart.putc_immediate(MIDI_START);
}

Use the offset value to shift the phase back or forward if things are not syncing correctly.

You can also use the div96th counter which will provide you with the highest resolution for the clock.
The formula should be: (MidiClock.div96th_counter + offset) % (16 * 6) != 0

3 Likes

I owe you one :cookie:

Might have to bust out one of my MiniCommands and give that a go on on the weekend.

1 Like

I’ll probably start on a new boot loader soon for the MC with ability to load firmwares off the SD Card. That broken MC could come in handy :-).

1 Like

I’ve written a draft for a SimpleFS.

If it works as planned, you’ll be able to store up to 10,000 files.

Some trade offs:

No support for directories, but path names are 16 characters.
No support for file resize.

Space is allocated linearly and contiguous (block aligned). I’ve written it this way as a trade off between code size + complexity and disk space usage. Basically SDCard space is cheap and we have a lot of it. We don’t really need to worry about fragmentation and other issues that a complex filesystem would handle. That is overkill for our application.

We just need a way of opening/closing/creating/reading/writing and deleting files, all of which my code will perform simply.

3 Likes

Well… thats a pickle isn’t it…

Win7: Doesn’t recognise midi ports.
OSX: Does recognise midi ports, doesn’t send to I/O board.

Ah well, best figure this one out.

I’m running midi-ctrl0017 with TM-1 no problems on El Captain.

1 Like

Just nabbed midi-ctrl0017 off your site… guess I owe you :cookie::cookie:

1 Like

Demo videos are recorded and encoded. I’ll upload them tomorrow when I have access to high speed internet (yes I live in Australia).

Stay tuned.

3 Likes


Annotations included in the video above to explain what’s going on.

Video below is an extended performance. Quite rough but should give you a good idea of what the firmware is capable of.

7 Likes