OK, I figured it out, the problem was due to Adafruit's library strange decision to overwrite the channel field of the message in the send method by its own parameter.
So,
midi.send(SomeMessage(..., channel=X))
should always be used as
midi.send(SomeMessage(...), channel=X)
instead. Then everything works as intended.
OK, I figured it out, the problem was due to Adafruit's library strange decision to overwrite the channel field of the message in the send method by its own parameter.
So,
midi.send(SomeMessage(..., channel=X))
should always be used as
midi.send(SomeMessage(...), channel=X)
instead. Then everything works as intended.
I just got my hands on the M5 SAM2695 unit, which I think is super fun.
I've stumbled upon an issue which I'd hope the community could help me with.
Namely, I would expect the following sequence of MIDI events:
ProgramChange(patch=<instrument A>, channel=0)
ProgramChange(patch=<instrument B>, channel=1)
NoteOn(channel=0, note=60)
NoteOn(channel=1, note=64)
To play the first note using instrument A and the second using instrument B. Instead, however, it seems to play both notes using whatever instrument was used in the most recent call to ProgramChange, irrespectively of any channel numbers.
Am I misunderstanding the MIDI API, do I need to set some configuration setting for SAM2695 specifically, or is it a bug in the API implementation of the SAM2695?
I am using CircuitPython (on an AtomS3 Lite) with Adafruit's MIDI library (which seems to send the right commands). Here's an actual code example:
import board
import busio
import time
import adafruit_midi
from adafruit_midi.note_on import NoteOn
from adafruit_midi.note_off import NoteOff
from adafruit_midi.program_change import ProgramChange
from adafruit_midi.system_exclusive import SystemExclusive
uart = busio.UART(tx=board.D2, baudrate=31250, bits=8, parity=None, stop=1)
midi = adafruit_midi.MIDI(midi_out=uart, out_channel=0)
midi.send(SystemExclusive([0x7e, 0x7f], [0x09, 0x01])) # Reset
midi.send(SystemExclusive([0x7f, 0x7f, 0x04], [0x01, 0x00, 123 & 0x7f])) # Volume 123
midi.send(ProgramChange(patch=108, channel=0)) # Kalimba
midi.send(ProgramChange(patch=0, channel=1)) # Piano
# I'd expect to hear first Kalimba then Piano
# but both notes are played using Piano
midi.send(NoteOn(channel=0, note=60))
time.sleep(0.5)
midi.send(NoteOn(channel=1, note=64))
time.sleep(1)
# Same PC events, just in different order
midi.send(ProgramChange(patch=0, channel=1)) # Piano
midi.send(ProgramChange(patch=108, channel=0)) # Kalimba
# Now both are played using Kalimba
midi.send(NoteOn(channel=0, note=60))
time.sleep(0.5)
midi.send(NoteOn(channel=1, note=64))
I went through the datasheet as well as I could but did not find anything helpful yet.
Thanks for the answer! Could you point to some part number of other identifier to help find the connector?
What do you "damaged beyond repair"? did you rip the ribbon?
I'm not 100% sure. The thing that visibly broke at first was just the connector (it didn't hold the cable anymore), so I had to solder the contacts on. I made sure the right spots on the PCB beep through to the appropriate pads on the ribbon (and there are no shorts among them) but the screen shows no picture (while powering on the backlight) - as if the ribbon were only sending through the power, but not the data. There's no visible rip in the ribbon, but there's one reasonably strong bend right next to the connector. It was there originally (the ribbon is packed by sticking it to the back with some kapton tape) but I'm afraid the un-bending it backwards could have damaged one of the thinner lines inside it. In any case I have no idea how to fi it. I didn't bother checking the connectivity all the way to the screen, as the ribbon disappears into the body there and seems pretty fiddly to disassemble, at least at first glance.
I just received my Cardputer and an extra M5StampS3 1.27 along. From the photos it seemed that the device consists of a base module and an M5StampS3 plugged into it. This suggested that I could have several apps preprogrammed on the M5StampS3-s which I could plug into the base interchangeably rather than reflash it. I like this sort of modularity in my projects.
Although this concept is not fully wrong, there is a big caveat which was not obvious from the images and documents. Namely - besides the pins plugging into the base, the MCU is also connected to the screen on the base via a small ribbon cable. This means two things (worth being mentioned somewhere in the descriptions of the devices):
An accidental jerk during an attempt to take the M5StampS3 out of the base will easily damage it beyond repair. This is what happened to me now, as I was presuming the MCU was only being held by the pins and was not taking care to avoid the jerk when it came out.
The MCU has a dedicated connector soldered on the back, which is not present in the M5StampS3 that you can buy separately from the store. You would also need to find and solder the right connector.
Having gotten the warnings out of the way, I now have two questions, which, perhaps, someone here could answer: