MD Monster Software for Minicommand

[Frico]

Hello folks,

a few days ago i bought a used minicommand (very cheap;-)). I have installed the midi ctrl app for osx and checked some firmwares it comes with. But i cant find the original monster firmware which includes the MDNotes Patch for the polyphonic aspect. There are only Monster firmwares without the MD Notes patch(MD Notes New is only for recording stuff).

Question: Have anybody the oringinal Monster firmware(came with the minicommand) including the MDNotes Patch or any hint for modifying the written patch in the oldcruft directory (that didnt work or my skills are to low;-)

Thanks for help

[fmw]

hmm, no I only remember the mono mdnotes, which might be part of one of the mdmonster patches. Maybe this is it: https://github.com/wesen/mididuino/tree/master/minicommand-sketches/oldCruft/MDNotes

[Frico]

Thx for your reply! Your are right this link is doing fine. The Md Monster from Oldcruft is right too but if I want to compline it there is an error appearing. Maybe some old code. Do you know how to fix it or someone who can do that?

[fmw]

ah not off the top of my head: what is the error? I could take a look tomorrow. For your reference, I’ve got MIDIctrl/MIDIduino version: October 2009 (I believe this was release 18) on OSX 10.11 - this might be significant for the underlying frameworks that Wesen was using (including his own). What version / platform are you using?

[Frico]

I’ve got the same version (MIDIcrtl/MIDIduino release 18…but its an alpha version). Also working on OSX 10.11.

I have made a screenshot, i hope the quality is good enough;)

Here is the whole text of the error message:

Adding library Midi
Adding library GUI
Adding library CommonTools
Adding library Elektron
Adding library MD
Adding library Sequencer
Adding library MidiTools
Adding library SDCard

In function ‘void MDNotes::handleGuiSysex()’:
21: error: ‘class MDSysexListenerClass’ has no member named ‘getCurrentKit’ In function ‘void MDNotes::onNoteOnCallbackMD(uint8_t*)’:
In function ‘void MDNotes::setupMidi()’:
In member function ‘virtual void MDNotes::ChannelConfigPage::display(bool)’:
In function ‘void MDNotes::handleGuiPages()’:
In function ‘void MDNotes::handleConfigChannelSelectNote(uint8_t*)’:
In function ‘void MDNotes::handleConfigChannelNote(uint8_t*)’:
In function ‘bool MDNotes::isConfigPageActive()’:
In member function ‘virtual void MDNotes::MDNotesSketch::loop()’:
In member function ‘virtual void MDNotes::MDNotesSketch::destroy()’:
In member function ‘virtual void MDWesenLivePatch::BreakPage::display(bool)’:
In member function ‘virtual void MDWesenLivePatch::MDWesenLivePatchSketch::setup()’:
In member function ‘virtual void MDWesenLivePatch::MDWesenLivePatchSketch::loop()’:
In member function ‘virtual void MDWesenLivePatch::MDWesenLivePatchSketch::handleGui()’:
In member function ‘virtual void MDWesenLivePatch::MDWesenLivePatchSketch::destroy()’:
In function ‘void MDRandomize::onControlChangeCallback(uint8_t*)’:
In member function ‘void MDRandomize::RandomizePage::trackHandle()’:
In member function ‘void MDRandomize::RandomizePage::randomize()’:
In member function ‘void MDRandomize::RandomizePage::undo()’:
In member function ‘virtual void MDRandomize::MDRandomizeSketch::setup()’:
In member function ‘virtual void MDRandomize::MDRandomizeSketch::loop()’:
In member function ‘virtual void MDRandomize::MDRandomizeSketch::handleGui()’:
In member function ‘virtual void MDRandomize::MDRandomizeSketch::destroy()’:
In member function ‘virtual void MDPitchEuclid::MDPitchEuclidSketch::setup()’:
In member function ‘virtual void MDPitchEuclid::MDPitchEuclidSketch::loop()’:
In member function ‘virtual void MDPitchEuclid::MDPitchEuclidSketch::handleGui()’:
In member function ‘virtual void MDPitchEuclid::MDPitchEuclidSketch::destroy()’:
In function ‘void MDMelodyHelper::handleGuiSysex()’:
In function ‘void MDMelodyHelper::setupMidi()’:
In function ‘void MDMelodyHelper::onControlChangeCallback(uint8_t*)’:
In member function ‘virtual void MDMelodyHelper::MDMelodyHelperSketch::loop()’:
In member function ‘virtual void MDMelodyHelper::MDMelodyHelperSketch::destroy()’:
In member function ‘virtual void MDSnareNotes::MDSnareNotesSketch::setup()’:
In member function ‘virtual void MDSnareNotes::MDSnareNotesSketch::handleGui()’:
In function ‘bool MidiController::writeSettings()’:
In function ‘bool MidiController::loadSettings()’:
In member function ‘virtual void MidiController::ConfigPage::display(bool)’:
In member function ‘virtual void MidiController::EncoderConfigPage::display(bool)’:
In member function ‘virtual void MidiController::MidiControllerSketch::setup()’:
In member function ‘virtual void MidiController::MidiControllerSketch::loop()’:
In member function ‘virtual void MidiController::MidiControllerSketch::handleGui()’:
In member function ‘virtual void MidiController::MidiControllerSketch::destroy()’:
At global scope:
In member function ‘virtual void InitSketch::loop()’:
In function ‘void handleGui()’:

Thx for your time;-)

[fmw]

ah, I don’t think I can help out but makes a bit more sense - I fixated on the wrong ‘cruft’ firmware (mdnotes) - I just looked at mdmonster (original version I guess). Basically, I don’t think there’s a quick fix.

You probably already know this - it’s my take: Wesen increasingly packed his firmware code into libraries as he went along, deepening the levels of code calling code. It was also in perpetual development: he also removed, modified, renamed functions or moved them between his base libraries prior to the codebase we got with Midictrl final (v. 0018).

So when I import the github version of MDMonster (original) into my working midictrl app - it’s going to try & build against the later version libraries that are packaged with the release version. It’s gonna fail on function calls or signatures. Mine borked on:

class ‘MidiClass’ has no member named ‘setOnNoteOnCallback’

You could experiment with replacing the released libraries with the older github ones (messy) … or tracking down the object & function names from errors & refactoring to call the updated ones (a classier approach) - it gets a bit rabbithole.

Having said this I’ve worked with dudes who can fix a zillion rando broken library calls in half an hour… anyone?

Was the firmware that had a youtube demo - Wesen playing MD notes from a MIDI keyboard?

[JustinValer]

On a side note. We should probably try and backport

jmamma/MIDICtrl20_MegaCommand

It would theoretically be possible to run a slimmed down version of the MCL firmware on the original MC hardware. I still have support for the HD44780 display in the firmware.

FYI: MIDICtrl20 was my original fork of MIDICtrl17 for the Minicommand. It’s since been modified to run on the MegaCommand hardware, which has small differences to the original.

[Frico]

Yes i know there is no fast fix. But i am really glad that someone can give me some answers of my nooby questions;-)

I spend hours digging the libaries and fooling around with different combinations. I have no experiance with Java or C++, so this kind of work ins’t very productiv. Rabbithole…blue or red pill.
So there was a firmware from wesen, i think it was MdMonsterRandom and this firmware was to big for the MC, so i shorten it up and voila it works;-) Success…wup wup.

Yes it is the firmware that wesen was demonstrating in one his vidoes.

[Frico]

Hey Justin, that would be great. But slimming down your firmware that’s a bit to much for me, because coding ins’t one of my best skills. But i will download all of your nice work and check it out;-)

Maybe you can give me some assistance of doing that. The poly mode for the MD would be nice to have. But if nothing works i am glad with wesens MDpitcheuclid; MDRandom, MDArp;-)

Thx

[JustinValer]

Add support for the Minicommand hardware

I’ve created a pull request for this.
I’ve listed the known changes that need to be done for this to work.
You can track my progress above.

[Frico]

Thank you very much. I see there is a lot of work to do…I feel a little ashamed that I cant help in anyway. I will follow the progress and be excited of the result.

Only the best.

[JustinValer]

I’ve made some progress here. I’ve refactored the MIDICtrl20 core to work with the Minicommand hardware (needs to be tested).

I also just got the Makefile working for the Minicommand

By disabling the OLED display and WavDesigner functionality of MCL we’re only 20KB over the program size limit.

That’s way better than I was expecting.

Unless i’ve made an error somewhere, we just need to selectively turn off firmware features until we fit in the 64KB limit.

Update:

Disabling a few more non-key firmware features (Loudness Page and SoundBrowser) and we’re down to 7KB. That’s without having to modify any code.

[Frico]

Nice!!! I have followed your progress for the last days. It sounds great what your’re doing. On github i don’t understand everything but a few points i have checked;-)

Should i test the MIDICtrl20 core? Cool, reducing the size by only erasing some features…the easy way;)

[JustinValer]

Bad news. The linker wasn’t reporting the size correctly.

I got the firmware compiling and linking and we’re at 129KB. which is 193% of the Minicommand memory capacity.

[Frico]

Hello, good Job! The reducing moves on. I still believe its a mammut project. Thanks for keeping your brain on fire;)

Greetz

[Frico]

Hey Justin,

any good news about the minicommand transfer?

Greetz