MegaCommand // MiniCommand Resurrection // MCLive

The Lounge Other Gear
#22

Yep, that was the reason given by Wesen way back when as to why its not possible in the current design… i’m no electrical engineer but yep it would seem that either more flash would be needed or smaller SD card libraries (if that’s even possible?). Food for thought anyway…

Hehe, yes I know exactly what you mean… So many times I have gotten to a point with firmwares where I’ve gone too far with overloads and combo button presses in order to be able to shoehorn in additional functionality, it gets impossible to remember what button/knob etc does what!

Nice, looks like you are smashing through those the framework bugs… :thumbsup:

1 Like
#23

Luckily I have some engineering degrees under my belt.

Regarding the hardware diy/redesign. We have a few choices.

1) Try and get a 3rd party dev board with the original atmega64 processor working.
Code should work without problem as it is the same processor Wesen used for the MC

2) Try and get a 3rd party dev board with the atmega128 processor working (pin for pin compatible but with double flash storage for firmwares). Boot loader code might need to be modified as there is a small memory change as noted by atmega.

3) Try and get a dev board with atMega2560 Arduino Mega2560 working. (256kb of flash.)

The benefit of option 3 is that there is already an external SRAM shield being sold.
Which means no soldering.
LCD shields are also sold
SD card shields are sold.

If we went with option 1 or 2 I would have to design an SRAM circuit (not difficult, it’s in the microprocessor manual) but it would require somewhere in the order of 40+ solder points.

I’m leaning towards trying to get the Arduino Mega2560 working because of the available shields.

Any thoughts here would be great.

If the DIY project is to work then the build will need to be as easy as possible, with easily acquirable parts.

3 Likes
#24

Mega would also be great for adding more encoders etc. It could also support a ‘classic’ version as well as a ‘Mark 2’ version with the appropriate enclosure and parts changes.

This would be so tempting if it went DIY, gnash teeth, rend garments. Always wanted to Command the MD.:rage:

At least I managed to dodge the Nava build. Which was hard because I wanted to see how the sampling part worked. Would love to build my own sampler.

2 Likes
#25

Oh and by the way, for the new people, JV has some great liveset videos up on YouTube (or at least he did).

1 Like
#26

Just put an order on ArduinoMega. Should arrive tomorrow. I’ll start hacking on the weekend.

2 Likes
#27

Cool. I got one for a project a while back and it was like, yeah now we got some power.

#28

Daily Update:

Trying to make MCL behaviour consistant, reliable and repeatable.

Bug fixes:
Imported MidiCtrl 0018 MidiUart.cpp as Wesen fixed some bugs relating to Midi send buffer and interrupts.
The previous code was causing turbo midi to die after sysex data was transmitted in certain situations.

Pattern read and write behaviour is now working correctly in scenarios:
MD -> MC sync (turbo on or off)
External -> MC SYNC (turbo on off)

Empty tracks are no longer written to the MD causing corrupt kit/patten data and md to lockup. Bad MCL v1.0 bug.

Issues:

Midi Machines cannot be detected as Trigger events.
Not sure how to work around this one, they transmit on their own channel. The velocity is different but it’s going to be difficult to differentiate between sequencer event and a user event.

1 Like
#29

Daily Update:

Big Progress this weekend.

Write operations can now be quantised to the MidiClock at 2,4,8,16,32,64,128 step intervals.
Simply select the tracks you want to write to the MD by pressing down the corresponding trigger keys.
The MC will then attempt to write the tracks on the next quantisation as specified. The tracks to be replaced are automatically muted and then unmated on beat to create a seamless transition.
Furthermore, if you’re not sure you want to have the written tracks playing without hearing them first you can choose to have the written track’s audio automatically routed to the audio CUE output.

Tracks that are cued can be UN-CUED at 2,4,8,16,32,64,128 step intervals. Cueing intelligently mutes and unmutes tracks before routing to remove audible popping or clicking. Cueing can be used as alternative to the MD mutes. Cue toggle works the same way as track read/write. Simply engage the cue menu then press the trigger buttons on the MD corresponding to the tracks you want to cue/uncue.

Audio from the CUE can be listened to on a pair of headphones whilst your set is playing through the main PA, much like a DJ mixer.

I’ve automated the MD setup required to use the trigger exploit, and in turn automated the setup of MCL completely. Global control of the MD is now assumed by the MC. Any changes to SYNC or routing are automatically applied by the MiniCommand given the circumstance. For example, if you are syncing to an external clock the MC will automatically configure the correct MD GLOBAL SYNC settings.

–
To Do:

Change the Project data structure to incorporate versioning.
Allow MASTER FX settings to be stored on each row of the Grid.
Provide redundant space in project data structure to allow for future features such as custom naming of tracks.

Mixer Menu: Much like the cue menu, this will allow you to adjust the volume of multiple tracks simultaneously.
Simply select the tracks to fade up using the triggers, then use an encoder to raise or lower the volume of the selected tracks simultaneously.

Code Cleanup: Big job here, but must be done for sanity. I’ll probably start this after the first BETA is released.

1 Like
#30

Regarding the MC Hardware Resurrection:

I have preliminary parts list gathered.
Almost all the hardware components exist in Arduino Shield form meaning soldering will be fairly limited.
The hardest part will be compatibility between the ATmega64 and ATmega2560 chips.
From my research the ATmega2560 is a replacement of the ATmega1280 which was an upgraded version of the ATmega128 which was an upgraded version of the ATmega64.
This means the chips are pin for pin compatible.
Platform Migration guidelines are provided by ATmel from moving between the 64 and 128, the 128 and 1280. and the 1280 and 2560.
Changes between these appear minimal.

Questions remains. Do we try to use Wesen’s boot loader, or work off the one provided by Arduino. Flashing Wesen’s boot loader will require an additional tool. no garuntee that it will work without tinkering.

1 Like
#31

pleasantly astonished that this can be done at all, let alone so conveniently. i remember the ram record machines have a cue functionality (that i never used or figured out) … out of idle curiosity, does this mc feature make use of the same part of the md os?

tbh i’d get use out of a mc firmware that permitted cuing of a md pattern’s tracks through headphones, even if said firmware did nothing else.

#32

So CUEing in MCLive is simply changing the routing of a track from Master Output, to Output F.

In an ideal setup. You’d have the Machinedrum headphone output + Cue output heading in to a mixer. You’d be listening to this submix on your headphones. The master output of the Machinedrum would be going to the PA.

When you’re satisfied with the sound coming through the headphones, you can schedule the cued tracks to be switched over to Master either instantaneously or at a specified quantisation.

Regarding the RAM machine cuing.

If you have a ram machine on track 16. The CUE1 parameter will route the Master output through the Track16 output.
Without conferring the MD this will cause the sound to be doubled as track 16 is routed to the master outs.
For it to function correctly you need to have the routing of track 16 to be sent to one of the external outs other than the master.

I guess this is not particularly useful for the Master tracks, but CUE2 can be used to preview the sound of the external inputs, if for example you were sampling vinyl or some other source.

3 Likes
#33

Daily update.

Mixer page is done. When the mixer page is open, a bar graph of the individual level values for each track is shown. 1 bar graph, per character on the display. Hold down any combination of the machinedrum triggers and you can adjust the level values of the corresponding tracks simultaneously by rotating encoder 1.

This works for other parameters as well, i.e.: filter. But values other than level break the trigger exploit after the parameter is changed (actually any update of the display breaks the exploit), so I may not include them as a feature.

I’ve rewritten the Project Data structure. Projects now include a version check on load. Each track now stores the master fx settings as well as original kit position and name. This means i’ll be able to code the ‘write as original feature’ which will restore patterns and kits similar to a standard sysex pat+kit dump.
I’ve also optimized some redundant space in the Track objects which means total project size will be smaller and SD Card read/write times should effectively halved.

On a side note. The MCLive firmware is currently sitting just under 58kB of space. We have 61kB usable.
I’m trying to leave space for enhancements, bug fixes etc… Version 1.0 used the entire 61kB.

4 Likes
#34

Discovered last night that the original MCL code was only storing 16 parameter locks per pattern.

Traced it down to a bug in my code, which was a fix for a read/write bug in the SDCard library that I couldn’t trace until now.

Turns out wesen’s SDCard wrapper was unnecessarily limiting read/write lengths to 256 bytes due to a uint8_t type declaration.

I’ve fixed this and in turn should be able to clean up a good chunk of read/write code that was originally written to circumvent this anomaly.

4 Likes
#35

Weekly update:

Stuck in a hold up whilst I debug parameter locks. Currently not working correctly and I’m attempting to isolate the fault to either my code or the midi ctrl framework. Painfully slow.

1 Like
#36

I have faith in you man ! Keep up the good work !
And know that there are people reading your progression with some appetite :yum:

3 Likes
#37

Looks like I found the bugs (finally).

MD was sending more locks than actually visible on the step sequencer in pattern dump so my arrays were running out of space. This would cause only a portion of the total locks to be stored. I now check to see that there is a trigger for each lock, and discard the ones that don’t have active triggers.

Also some small mistakes on my part have been corrected.

Now I need to re-assemble this mess and get back to where we were 3 days ago.

2 Likes
#38

Code is back together again.

We now have complete pattern/kit restore working. For example. You can choose to write a pattern+kit in original form with master fx settings, track length + scale, accent amount and swing amount etc.

4 Likes
#39

very nice work Justin updating your progress can’t wait

1 Like
#40

Daily Update:

Parameter locks are now stored dynamically with a potential of 512 locks per track.
Tracks with lower lock count get rewarded with faster sd card read/write speed.

New projects are named in incremental format: projectXXX.mcl where XXX is an integer count of total projects created.
Projects have versioning information and also store environment variables such as MIDI settings and current grid position.

–

The feature set of MCL 2.0 is complete. I’m now in an iterative process of verifying functionality, coding the GUI and fixing bugs along the way.

I don’t expect too many hold ups here as the bulk of the work is done. underlying functionality is stable and working well (that includes midi sync, sd card, track storage, parameter locks etc.)

Once everything is at a user functional state i’ll record some demonstration videos, and then distribute the beta firmware.

Also I think the Mixer Page looks exceptionally cool:

IMG_0654.JPG1632×1224 294 KB

7 Likes
#41

Very cool. Love it when old projects die hard! :slight_smile: Good luck Justin!

Also I would be interested in backing a diy neo minicommand

3 Likes