jmamma / mcl Goto Github PK

I'm working on a metal chassis design

Basically, I'd like to make it low-cost, durable and mountable. The current design consists of two parts, each can be produced with sheetmetal (304, 6061 etc.)

Potential problems:

1. The screw tap hole "ears" are less than optimal. May consider bend the whole edge instead of cutting those 6 ears.
2. Screen height?
3. No power switch hole...

Visually the step sequencer should be drawn using drawrect commands (similar to mixer and cue pages)

Functionally we may be able to improve on encoder+ button layout.

Sysex buffers are currently defined in main.cpp

281 uint8_t sysexBuf[5500];
282 MidiClass Midi(&MidiUart, sysexBuf, sizeof(sysexBuf));
283 uint8_t sysexBuf2[2800];
284 MidiClass Midi2(&MidiUart2, sysexBuf2, sizeof(sysexBuf2));

These are not large enough to contain pattern dumps from Analog4 and other machines.

Suggest defining memory regions in "memory.h" for sysex and then creating put_byte and get_byte functions to shift data in and out.

The memory reclaimed in bank0 can be used for the internal sequencer.

MD does not provide the facility to see the current mute state of the MD.

Proposed solution.

Iterate through each track
Change track type to MID16.
Set MidiNote on listener for channel 16.
Trigger track.
If MIDI message received then track is not muted.
Revert track back to original.

Need to watch out for track groups.

Changing track to MID, will not disrupt last sound played on track. This will work in our favour.

• Pattern dumps
• Sample dumps (MIDI SDS)
• Interfacing with sample name query facility
• Automated macros for entering dump receive mode

Hi @jamma!

I've been watching your repos for quite a while, and your work is both awesome and uplifting!
I'm considering to make a small batch of megacommands for my elektron boxes (or Propellerheads Reason if I've got time to figure out the Remote protocol).

I surfed the repo a bit and found that most of the core code is refactored to cpp, and getting it up and running is as simple as creating a new arduino sketch and call MCL.run().
My question is, should this be compatible with the MiniCommand sketches? Those are more like bare-metal logic running on the midi library.
Can I think of MCL as a mega sketch (hardened to c++)?
Does MegaCommand provide extension point where I can drop my own code snippets?

The original idea was to have a file browser class that could be easily extended for use amongst different pages. Having a common base class would save on program size and memory requirements.

The difficulty here is that the FileBrowser often requires additional GUI functionality depending on its context.
For example the SoundBrowser page and LoadProject page both require reading the SD card file system. But have different functional requirements.

The current FileBrowser class allows additional GUI elements to be activated, through the use of boolean flags. The ability to traverse parent directories, to Save or Create new files are accessible by appending faux menu items before the list of files of the cwd.

There might be a better way to do this. Dynamic menu items? Function callbacks?

This is on DEV branch.

prior to sysex_refactor.

Consider the following situation:

 MC1 <--- MC2
 | |      |
MD A4     MNM

For MC1, I'd like to use A4 keys in step editing.
For MC2, I'd like to use A4 keys in step editing.

We'll have to make the pages actively acquire and release the A4 keyboard as a resource, and route the messages accordingly.

LoadProjectPage should be ported to use the FileBrowser code.

__attribute__((always_inline))
in function declaration works.

../../../../tools/avr/bin/avr-objdump -S main.elf | less

Need to eliminate subroutine calls from:

_ZN6MCLSeq3seqEv

Some classes like MD, MNM, A4 currently have MidiUart hardcoded.

Need to change this to midi->uart

This will allow these classes to function on any port.

Write mode is obsolete, and buggy, it has been superseded by chain mode.
It adds extra complexity to the documentation and understanding of the firmware.

I'm proposing removing write mode completely when the sequencer is running.

• FXPages

• RAMPages

• Route Page

• SavePage

• WritePage

The clock on MD itself seems stable, but MC measures a huge tempo, and A4 reports 300 which seems to be the upper limit.

What did I break 😱

In CommonTools/helpers.h

We have the following macros.

/** 64-bit macros. **/
#define SET_BIT64(port, bit)   ((port) |= (uint64_t)(1ULL << (bit)))
#define CLEAR_BIT64(port, bit) ((port) &= (uint64_t)~(1ULL << (bit)))
#define TOGGLE_BIT64(port, bit) ((port) ^= (uint64_t)(1ULL << (bit)))
#define IS_BIT_SET64(port, bit) (((port) & (uint64_t)(1ULL << (bit))) ? 1 : 0)
#define IS_BIT_CLEAR64(port, bit) (((port) & (uint64_t)(1ULL << (bit))) == 0 ? 1 : 0)

IS_BIT_SET64 is used heavily in the sequencer ISR routines.

According to avr forum, the 32bit variant is extremely inefficient.

https://www.avrfreaks.net/forum/fast-nth-bit-set-long-code

@yatli how are your bit manipulation skills?

We can use https://godbolt.org/ to compare instruction length of various implementations

I thought MidiClock on port 2 was not working correctly. But I think it may be the Analog4 no longer transmitting reliable clock.

MD clock signal looks tight when plugged in to either port 1 or port 2.

@jmamma do you think it's a good idea to add graphics to the UI? I'm thinking about making a few icons, and improve the UI controls (possibly extract some common bits and build our own UI toolkit).

Currently when pressing SHIFT1, the quick select page pops up, and we can use ENC1 to select pages.
I'm thinking of making SHIFT1 more like alt-tab, that is, when entering the quick select page, auto advance to the next entry.
We can still use the rotary to scroll through the pages.

https://github.com/paulkaplan/HexUploader

^ This wrapper for avrdude works nice on MacOs.
Just need to have Arduino IDE installed for avrdude

--

Just need a similar windows version. Suggestions?

Currently MCL is using:

Sketch uses 203550 bytes (80%) of program storage space. Maximum is 253952 bytes.

Might want to start thinking of ways to cut this down.

A lot of the low level code is inlined. All the SYSEX Encoder/Decoder is inlined. Not sure what the space saving will be vs performance hit.

A general rule I've been following is to inline in ISR.

@yatli (might want to think about this)

A word on the TX Buffers:

The TX ring buffers are currently sized at 3KB. This seems sufficient for the largest dumps I have been transmitting in MCL (MDPattern). TX buffer transmission happens on ISR, when the TX queue for the UART is clean another byte from the buffer is read, and transmitted. The rate at which the TX buffer gets consumed is limited by the port speed.

These might need to be bumped up for handing A4Pattern MNMPattern sizes to prevent buffer overflow.

Alternatively, the data encoder code, could be modified to "wait for the UART queue to be empty' before sending more encoded bytes.

Completed the second MC!
Boot it up, greeted with a nice splash page animation, peering, and...
A black stripe is drawn in the center of the screen, and it freezes.
It's actually in the new page dialog but it didn't display correctly.
Move the cursor around and the page will show itself.

there's some kind of feedback loop in the clock. the reading on MC jitters between two integral values (e.g. 127 & 128), while MD says 126.5; in some conditions, hitting play will bump the tempo on MD to 127 -- which in turn bumps MC clock to jitter between 128 & 129.

go downstairs for a smoke, come back and get some DnB :p

Pages for controller Delay + Reverb.

Also need an intuitive +musical way of loading delay + reverb + compressor + eq settings from the current row/slot

Infinium (Behringer) X1 Optical Fader: Same fader as in the Octatrack.

45mm travel length.

The fader has a single (female) connector with 3 pins. The connector pins have 2mm spacing (slightly narrower than Arduino connecter)

Red = GND
Centre = TX
Black = 3.3V

TX transmits serial at MIDI Baud 31250. Each byte received is a value between 0-127.

When stationary the fader will transmit its current position every ~ 500ms
When the fader is moving the new position is transmitted immediately on change.

https://github.com/jmamma/MIDICtrl20_MegaCommand/files/3031779/infinium.x1.pdf

We can move the MIDI RX/TX Ring buffers to HIGH memory bank.

This will gain us another (3000 + 128 + 3000 + 128) bytes.

Will require another (less intensive) refactor.

Each slot should store data structure containing scenes.

A scene should be an array of ( parameter , value ) pairs.

Encoder or Midi Fader should be used to fade between scene values.

This is useful musically when creating builds and drops.

Popup menu for micro timing? conditional trigs?

Draw step sequencer.

MCLGUI::draw_trigger(width, button_state, led_state) {

drawLed()
drawRect()
etc
. . .
[ ] [ ] [ ]

}

@yatli just noticed these warnings. can you look in to this?

 #define BANK1_MD_TRACKS_START BANK1_SYSEX2_DATA_START + SYSEX2_DATA_LEN
                                                       ^
/Applications/Arduino.app/Contents/Java/hardware/valence/avr/cores/megacommand/MCL/MDTrack.h:51:58: note: in expansion of macro 'BANK1_MD_TRACKS_START'
                      public Bank1Object<MDTrackLight, 0, BANK1_MD_TRACKS_START> {
                                                          ^
In file included from /Applications/Arduino.app/Contents/Java/hardware/valence/avr/cores/megacommand/MCL/A4Track.h:8:0,
                 from /Applications/Arduino.app/Contents/Java/hardware/valence/avr/cores/megacommand/MCL/Grid.h:7,
                 from /Applications/Arduino.app/Contents/Java/hardware/valence/avr/cores/megacommand/MCL/MCL.h:25,
                 from /Applications/Arduino.app/Contents/Java/hardware/valence/avr/cores/megacommand/MCL/GridWritePage.cpp:2:
/Applications/Arduino.app/Contents/Java/hardware/valence/avr/cores/megacommand/MCL/MDTrack.h:51:79: warning: overflow in constant expression [-fpermissive]
                      public Bank1Object<MDTrackLight, 0, BANK1_MD_TRACKS_START> {
                                                                               ^
/Applications/Arduino.app/Contents/Java/hardware/valence/avr/cores/megacommand/MCL/MDTrack.h:51:79: note: in template argument for type 'long unsigned int' ```

Design fonts in: https://www.pentacom.jp/pentacom/bitfontmaker2/

Export adafruit font converter to convert to byte array.
./fontconvert ~/Downloads/mdlightlarger.ttf 8

Size 8pt gives 1 to 1 mapping from pixel to screen.

Use https://tchapi.github.io/Adafruit-GFX-Font-Customiser/ to preview font before adding to core.

Thinking about best way to implement these.

From MD manual:

"SPEED sets the update speed relative to the tempo in 1/128 note steps."

Range of LFO is [0-127]

128 bytes array/wavtable then playback speed controlled by tempo ?

At sequencer resolution we have 12 * 4 = 48 possible values per beat.

It's a little bit confusing, not all tracks progress together in chain mode. I'm applying loop=4,row=(cur+1),apply=(1-20) to a row, and after 4 bars only some tracks progress to the next row:

  md_exploit.off();
  note_interface.state = true;
  md_exploit.on();

Need to set note_interface.state = true;
Otherwise no delay is needed between operations.

We can leverage RAM machine to implement sample chains, similar to OctaTrack.
The idea is to have MC upload chained WAV to RAM machine, and load the metadata about slice positions & pitches.

Then we will have a few more interesting modes:

• Pre-sliced loops
• One-machine sample packs
• PCM synth!

Original MIDICtrl code was incorrectly naming div64th_counter as div96th_counter.

Below:

MidiClock sends 24 ppm

1 measure = 4 x 16th notes.

Therefore.

6 pulses per 16th note.

--

div16th_counter 6 pulses
div32th_counter 3 pulses
div64th_counter 1 pulse (div96th_counter)
div128th_counter 0.5 pulse (div192th_counter)

--

I've been through this a few times..
Trying to compose something in the internal sequencer -> accidentally cleared it with a chain write -> no pattern, no kit, no nothing :(

LEN should be value encoder, not knob.

redisplay = false appears to be persistent. GUI does not refresh unless encoder is rotated.

After a few writes (chained looping), some tracks start to drop out.

I've recorded a video:
https://yadli.net/index.php/s/4eWm6nNypANqmgt

• 1. Should verify if MD.connected = true before starting save.
• 2. Should verify return of getBlocking() and fail if false.
• 3. Should display Confirmation Popup on Load so that MD contents isn't accidentally overwritten.

When transmitting Pattern from MD -> MC , the internal sequencer drops out.

If you want to save current Pattern in to the grid during a live performance, the sequencer will drop out unpredictably whilst the MD pattern is being transferred.

Solution would be to prevent MD Patterns from being transferred when sequencer is running. Though this may cause confusion to users who expected their MD trigs to be merged.

In step editing page, sometimes if I quickly press-n-release a trig, it does not register a note. The display loop recognizes that the trig button is pressed, but then the event handler does not. This feels very strange.

We may move note interface event detection to a background task.
This will allow more timely detection of the events. For example we can schedule a scan where we scan the buttons, or once every a few timer interrupt.

We can also make the display() loop calculate and latch the events. Simpler but a bit of a hack.

MIDI machines break the trigger interface because they transmit on the MIDI channel specified by the machine type and the pitch + velocity specified by the machine parameters.

We could convert MIDI machines in to sequencer tracks when saved and have the MC do the sequencing.

Would need to come up with a way of converting MIDI track sequencer data in to A4/Ext sequencer data. Or write a specialised sequencer routine for MD sequencer tracks.
A4/Ext sequencer is Note on + Note Off sequencer where as MD sequencer works on Note length .