SDDrive seems broken?
jmamma opened this issue · comments
Tried dropping midi speed to 1x.
Get SYSEX error code 1. Globals are all messed up.
Some patterns completely erased ?
Just tested a complete rec/dump using C6 and the TM-1. No problems. So problem is not on the MD side.
MD.setSysexRecPos()
implementation doesnt look correct.
edit: looks okay.
Just checked 2.70 . No problems with X.03
commit b923b202d187df5bd879bd0a49a38c268e9f412b
Author: Yatao Li <yatli@microsoft.com>
Date: Wed Sep 2 20:43:14 2020 +0800
super-charged refactor: unify ElektronDevice implementations
I'm guessing this broke sysex transmission ^ @yatli
Kit and Global transmission is okay. It's the pattern transmission that is broken.
MD SYSEX verify is not showing any transmission errors. so length + checksum calc must be okay, but payload is bad.
91 MDPattern() : ElektronPattern() {
92 maxSteps = 64;
93 maxParams = 24;
94 maxTracks = 16;
95 maxLocks = 64;
96
97 isExtraPattern = false;
98 init();
99 }
100
101 /* XXX TODO extra pattern 64 */
102
^^ @yatli TODO ??
uint8_t i = 0;
MD.getBlockingPattern(i);
MD.setSysexRecPos(8, i + 1);
delay(20);
MD.pattern.toSysex();
This is test routine is working ^ so encode /decode must be okay.
Problem must be SD storage? templates perhaps?
21 template <class T> bool read_data_v(T *data, FatFile *filep) {
22 auto ret = read_data(data, sizeof(T), filep);
25 ::new(data)T;
26 return ret;
27 }
::new calls the constructor.
i.e isExtraPattern = false;
Called by the constructor!
43 /** Clear the pattern. */
44 void init() {
45 clearPattern();
46 }
What happened today 0.0
more 🐛 🐞
dev branch? I'll take a look
no, master.
the problem is the constructor call.. in
21 template bool read_data_v(T *data, FatFile *filep) {
22 auto ret = read_data(data, sizeof(T), filep);
25 ::new(data)T;
26 return ret;
27 }
it indirectly calls clearPattern();
Only happens for MDPattern?
yes
Was there a vtable in previous versions of MDPattern.. if not, the schema has changed and old .snp's won't be compatible
clearPattern is called even twice 0.0
I just checked 2.70 -- the inheritance tree is intact -- MDPattern -> ElektronPattern
And the same init sequence: MDPattern ctor calls ElektronPattern ctor calls clearPattern, then MDPattern ctor calls init()
The twist is... in 2.70, MDPattern::clearPattern is not explicitly called, and MDPattern::clearPattern is not declared as virtual, and thus base instead calls the base implementation clearPattern() {}, so the pattern isn't cleared at all 😱
TL;DR
I fixed a bug where the derived class doesn't properly declare virtual methods, and then it backfired (