Boss RC 600 Midi-Sync Probleme

[Aynsley]

Eines meiner Settings ist z.B., dass die Clock vom IPad (also von außen zum RC 500) kommt und ich mit dem RC 500 starte, nur starte!
Da laufen dann nur die Apps an, eine div App Konstellation, die vermutlich Deinem Synthesizer-Park entspricht. Ein Sequencer spielt u.U. sogar die im RC 500 „eingebauten“ Sounds …. Dazu spiele ich live und loope bei Bedarf (unterschiedliche Quellen) mit dem RC 500, alles in Time.
Und Du merkst, es ist keine reine Master-Slave Geschichte …

Bringt ja nichts da die Augen zuzumachen bei der Fehlersuche.

Guter Ansatz, Dein Problem kann überall liegen, nicht nur in der Firmware eines Gerätes.

 

[Cysign]

Die Rythm-Sounds musste ich beim RC-600 auch erstmal deaktivieren... damit das Ding nicht (wie im letzten Video) die Drumsequencerspur wiedergibt.

Ich war überrascht, dass man den als Drum-Voice missbrauchen kann - brauch ich aber (wie 95% aller Funktionen von dem Teil) nicht.
Kann der auch andere Voices? (Synth-Bass oder so) Da bin ich noch nicht drüber gestolpert

 

[Aynsley]

Soweit ich weiß, nicht. Würde m.E. auch wenig Sinn machen. Fugue Maschine (ne App) dagegen zaubert aber schon aus den simplen Rhythmus-Instrumenten des RC 500 polyrhythmisches.

Ich hab zur Steuerung mein IPad, vom dem via OnSong die Clock und PC Befehle (für alle Geräte und Apps!) kommen. Der RC 500 startet dann per Fußschalter. Beim Looper hab ich dann ggfs. auf den Speicherplätzen auf einzelnen Spuren schon vorher eingespielte Sachen, die (oh, Wunder ) alle in Time ablaufen. Wenn ich allerdings die Clock zwischendurch/nachträglich auf dem iPad ändere, dann glitscht es natürlich.

 

[Cysign]

Ja, auch nen Bug vom RC-600.
Denn bei meinen ganzen Tests die letzten Tage konnte ich in >einem< Fall nen Loop (aus 2 oder 3 Tracks) problemlos und ohne Jitter/Glitches mit der externen Clock vom LoFi-12 XT steuern und in Echtzeit verändern. Vermutlich stand da gerade der Mond richtig

Auch sowas sollte reproduzierbar gehen - oder reproduzierbar nicht gehen.

Polyrythmik könnte ich dem über den LoFi auch einimpfen...aber mir fehlt bei dem Rythm-Part die Klangverformungsmöglichkeit, weshalb ich da lieber auf echte Synthesizer mit Direktzugriffen setze.

 

[Cysign]

Boss/Roland ist nach wie vor sehr uneinsichtig und nicht hilfsbereit und schätzt auch gar nicht meine Arbeitszeit, die ich bisher in das Problem gesteckt habe.

Klar, gesteht man sich nen Bug ein, müssen da gegen Geld Entwickler ans Werk (und die haben scheinbar nicht genug Ahnung, um die eigenen Geräte sauber zu programmieren - zumindest ist das der Eindruck, der über die letzten Jahre mit den Firmwarebugs beim Roland JD Xi und beim Boss RC-600 entsteht).

Ich hab jetzt mal angefangen die Firmware durch binwalk zu jagen und schaue mir an, ob ich da dann mit z.B. Ghidra weiter was eingrenzen kann.

Gemini sagt:
"Die Einträge ab Adresse 0x32A24 (Certificate in DER format) sind absolut real. Boss nutzt hier standardisierte kryptografische Signaturen (x509 v3 und PKCS)."

Also wäre es theoretisch möglich, den Speicher per jTag in Echtzeit auszuwerten und Manipulationen vorzunehmen, aber einfach ne saubere, gebugfixte Firmwre aufzuspielen ist schwer, da man die passende Signatur braucht.

Es wäre deutlich einfacher die ganzen Fehler einzugrenzen und zu beheben, wenn Boss/Roland da kooperativ wäre und mich dafür einstellt - aber das wollen die nicht, hatte ich denen angeboten.

Da fängts dann an, dass man mit Voltage-Glitching den Prozessor überlisten muss um da was einzuschleußen...das hab ich noch nie gemacht, hatte keinen Anwendungsfall dafür - aber bereits viel darüber gelesen in der Vergangenheit.

Wenn also alle Stricke reißen (sprich: Hersteller bessert nicht nach, Händler wandelt das nachweislich defekte Gerät nicht zurück in den Kaufpreis), bring ich mir das eben beim RC-600 bei

Wenn der RC-600 sauber funktioniert, habe ich den perfekten Looper für mich (da 2 Stereo-Inputs und Outputs).
Wenn ich das Geld zurück bekomme, gibt es zwei Optionen:

Mooer GL200 - wobei ich bei Mooer (weil oft baugleich mit den billigen Rowin-Aliexpress-Effekten und somit vermutlich auch deren Fehler) nen schlechtes Gefühl habe und das Gerät auf 24bit limitiert ist.
Vorteil: nur 190€ - davon könnte ich 2,5 Stück kaufen für das gelt vom roten RC-600 Schrottklotz.

Und dann gibts noch den Singular Sound Aeros - 100€ teurer als Boss, soll problemlos funktionieren und bei Bugs wird wohl sehr zeitnah nachgebessert. Dder arbeitet ebenfalls mit 32bit.
Nachteil: Der hat nur einen Stereo-input...also bräuchte ich da langfristig 2 Stück von.

Beitrag automatisch zusammengefügt: 13.07.26

Das ist für viele jetzt vllt. unlesbares Kauderwelsch, aber zumindest n bisschen Output von ner ersten Analyse:

developer@portabledev:~/Desktop/RC-600 firmware analyse$ grep -i "midi" stringsRC600.txt
UMIDI RX:
usb midi task
%!"$&,1660:07>?@42,-.:AEC9:+5*639>>>=<5/0/39?@@?D@E@D=A7;5:5@FBC><6<=CCIEA=GFKLMIDIDIEA@5@;A===761154?@IGGH9=,1()(-45?IOJJ?93(("&%*,3..)#"!

developer@portabledev:~/Desktop/RC-600 firmware analyse$ grep -i -E "v1\.|cortex|arm|boss|roland" stringsRC600.txt
BOSS RC Series MSC 0001]
armb\H)
ARM>
XaRm
Arm:
.armD
:QaRMMB!
@armP8
pzXArM
1armK3
#ARM@#
ARMN9('
ARmm(
&ARM>(
*ARMF)
4ARM5
"4FM_uiWAARmsn]Q@O\soiXL+
&+6ARM=,"(/:4$
!.ZL`Z^A99:3,HO5FCW'V1.
"',5*:?9I_arm~p{kv{p
,DD>=<E@J>>878@]d]LAARhg_]W\hx}m[OdfvfTHBXhbPT_ZU;1ARMLJ?PKE1=IO@D940<;;?>-1-889024$
UglgaRMCMKaiw}t`!
3OQd`MA>ZVlaRMA;@HJ2
developer@portabledev:~/Desktop/RC-600 firmware analyse$

Ab jetzt geht das Hinweise-Sammeln los

Der Hinweis auf den String "UMIDI RX" soll wohl ein Indikator dafür sein, dass die Firmware nicht verschlüsselt ist. Und durch den Hinweis auf nen ARM-Chip kann man Ghidra mit den Settings "ARM (Little Endian)" mal ausprobieren.

Ein Hoch auf die NSA, die mit Ghidra ein echt mächtiges Tool frei zugänglich gemacht hat

Und shame on Boss/Roland - ein konstruktives, kooperierendes Verhalten wäre sehr wünschenswert, statt immer diese 1st-Level-Laienaussagen. Jedem 1st-level-Mitarbeiter sollte bei dem Sachverhalt klar sein, dass es langsam ernst wird.

PS: Ddamit alle User hier rechtlich unantastbar bleiben: Bitte keine einzige Zeile Originalquellcode (auch nicht dekompiliert mit Ghidra) veröffentlichen.
Solange hier nur Anweisungen zur Fehlerbeseitigung gegeben werden, kann Boss/Roland gegen keine User vorgehen.

 

[Cysign]

Das geht ja einfacher voran, als ich dachte.

Projekt anlegen, Datei importieren, dann Doppelklick auf das Symbol vor der Datei und schwupps kann man die Plattofrm auswählen:
ARM v7
little big endian
default

Dann wird noch nach den Analysis Options gefragt und da sollte man ARM Agressive Instruction Finder mit anwählen.

Übrigens: Keine Bange wegen der EULA von Boss/Roland:

Egal, was bei denen beim Download der Firmware steht:
Zur reinen Fehlerkorrektur gilt die in Deutschland eh nicht. Wir wollen ja nichts verändern, sondern lediglich einen zuverlässigen Betrieb unseres eigenen Geräts herstellen. Das ist rechtlich abgedeckt ("Recht auf Fehlerbeseitigung nach § 69d UrhG").

Und EULAs sind ja in der EU eh son typisches Rest-der-Welt-Problem:
Da wurde ja vor dem Kauf des Produkts nicht drauf hingewiesen - daher ungültig.

Ich hetz dann jetzt mal 16 Kerne / 32 threads auf das Dekompilieren und schau mal was passiert. Aber schon vor der Analyse sieht man die ersten Zeilen Sourcecode (da übersetzt aus Maschinensprache leider ohne sinnvolle Bezeichnungen - das wird noch n langer Weg bis da was Sinnvolles rauskommt)

 

[Aynsley]

Ich verabschiede mich nun auch mal hier; ich kann nicht ganz nachvollziehen, für wen und warum Du jetzt diese Details deiner Fehlersuche beschreibst. Hab den Eindruck, Du hast Dich echt verbissen in Deine anfängliche Vermutung. Viel Erfolg bei der weiteren Fehlersuche!

 

[Cysign]

Ich geb mich eben nicht mit der fehlerhaften Firmware ab - egal wie oft du dir erlaubst die Sinnhaftigkeit einer ernsthaften Fehlersuche anzuzweifeln.
Dafür war mir der Klotz zu teuer.

Dein unterschwelliges Runterputzen (alla 'Vermutung' - ich habe mehrere Fehlverhalten sauber dokumentiert!) ist langsam anstrengend.

Sinnvoller wäre es die Moral von Boss/Roland anzuzweifeln, sowas ohne Einschränkung als midi-kompatibel zu verkaufen.

Jede genaue Erkenntnis über die Bugs in der Firmware oder über die Architektur helfen potentiell grob geschätzt 50.000 Käufern weltweit, auch wenn ein Großteil evtl. schon kapituliert hat. Muss ja nur ein Einziger User dabei sein, der die Lösung findet, die der Hersteller nicht hinbekommen hat

 

[Cysign]

Wenn die Firmware keinen Jitter beim Auswerten der Clock (0xF8) hat, gibt es zwei theoretische Ansätze für die Lösung das Problem:

Erstens:
Entweder einen Average-Wert für die BPM-Synchronisation nutzen (statt den Abstand zwischen 2-3 Midi 0xF8-Commands (das ist die Midi-Clock) berechnet man hieraus einen Durchschnitt, bevor das ungefiltert an die Audioengine weitergeleitet wird. Sprich: Desto länger die Clock anliegt, desto genauer wird der Wert. Also nach 10 Millisekunden hätte man einen sehr genauen Wert - falls ne Clock schwankt, bzw. die Firmware vom RC-600 die Clock intern falsch verarbeitet.
Das kann man dann zwischen die BPM-Auswertung und die Audioengine als Patch simpel einfügen.

Gemini sagt dazu:
"Die unsaubere Division: Um aus den 24 MIDI-Clock-Bytes (0xF8) pro Viertelnote die BPM zu berechnen, misst der Prozessor die Mikrosekunden zwischen den Bytes. Bei 120 BPM liegt der Abstand bei exakt 20,8333... Millisekunden. Wenn die Boss-Firmware intern mit Ganzzahlen (Integers) rechnet oder beim Runden die Nachkommastellen einfach abschneidet (Truncation), wird aus 120,0 im internen Register blitzschnell 119,92 – und das Display rundet es dann stur ab."

Zweitens:
Ne BPM-Quantisierung. Statt 0,1bpm-Steps einfach ne Option im Menü bereitstellen, dass nur noch Steps von mindestens 0,5bpm zu einer Tempo-Änderung führen.
Das dürfte für 99% alles User den Fehler total einfach beheben, solange man nicht in Echtzeit den Loop stretchen will (und wer will das schon bei dem Geglitche? ).

Wenn es an sowas läge, wäre das total einfach in der Firmware nachzubessern (wenn man den Sourcecode und das Zertifikat zum installieren des Updates hat).

Ich verstehe nur noch nicht, warum 0xFA hier das 0xF8 aus dem Konzept bringt.
Klar, für den ersten 96tel-Takt und vielleicht auch noch den zweiten 96tel-Takt mag das dann zutreffen. Aber dann sollte sofort ne grobe Zeit berechnet werden können, bevor dann spätestens nach der ersten Viertelnote ein sauberer Durschschnitt aus 24 0xF8-Impulsen gebildet werden kann.

//Edit: Ich komm dem Problem langsam näher. Die relevante Midi-Geschichte ist knapp 140 Zeilen Code lang (von insgesamt gut 46400 Zeilen Code der dekompilierten Firmware) - und man findet sie, wenn man einfach nach 0xFA und 0xF8 sucht

Das dicke Vorteil ist, dass es hier ausschließlich ums Timing geht und man da keine Audio-Hexereien oder Effekte betrachten muss (das läuft ja sauber - wie man mit der internen Clock sieht)

 

[Cysign]

Since this topic is now gaining more and more international interest, I will continue to write in English from now on.

I'm still in contact with the seller, which is in contact with Boss/Roland now (finally!) and they offered my full refund or sending me a new RC-600.
So I'm pretty sure, I can verify either a solution or a confirmation of this bug within the next days.

Also I've read about the CME H4MIDI WC - which might be able to filter out the midi start-command, when using the RC-600 with an external clock.

Also if using the RC-600 as midi master-clock it might keep the clock, even when the RC-600 stops (you don't wanna have your synthesizers stopped, when you stop your guitar loop...:

View: https://www.youtube.com/watch?v=NwzwB2rkztY

Beside this Im still analyzing the midi-part on the firmware, as well as I'm working on my own ESP32 midi-filter to address this issue.

 

[Cysign]

Meanwhile, I decompiled the firmware code for my Boss RC-5 - and it looks like the midi-part is 100% identical to my RC-600 code.
So every MIDI timing bug from the RC-600 also inevitably occurs on the RC-5.
Since I bought the RC-5 as used device, I only can sell it (or use it for voltage glitch code injections to correct the firmware).

To be honest, I never noticed this in practice before because I never actually tested my RC-5 with external MIDI clock (since I don't like the 3.5mm connector on a pedal-device). For my live rig, I always planned to use the RC-600 solely because of its robust, road-ready 5-pin DIN connectors.

Under EU Law (Computer Programs Directive 2009/24/EC), every European customer has the legal right to reverse engineer and decompile software they rightfully own for the purpose of error correction and interoperability—regardless of what the EULA says.

Furthermore, since this software flaw was present from day one, it qualifies as a hidden defect (verdeckter Sachmangel). Depending on local national laws, discovering a proven, hardcoded hidden defect can heavily extend your consumer rights for a return or refund, even if the standard 2-year warranty period has already passed, as some retailers will settle rather than face legal escalation over a proven systematic software flaw.

After analyzing the architecture, it is clear that Boss completely swapped their platform around 2019, moving away from the old custom ESC2 DSPs to a modern ARMv7-based control architecture.
I'm pretty sure this specific time-stretching MIDI bug belongs to every current-gen Boss RC-looper using this new ARM platform, which includes (but by law I'm only allowed to decompile the firmware of the broken devices I personally own):

• Boss RC-10R (Released 2019)
• Boss RC-5 (Released 2020)
• Boss RC-500 (Released 2020)
• Boss RC-505 MKII (Released 2021)
• Boss RC-600 (Released 2021)

The MIDI source code and the underlying integer-division math loop for the sample buffer estimation on those specific devices will pretty sure be identical – even if I didn't compare every single firmware file yet.

(Note: Older legacy loopers like the RC-50 (2006), RC-300 (2011), RC-505 MKI (2013), or the RC-202 (2016) run on completely different legacy DSP hardware, so while they have their own MIDI flaws, they don't share this exact decompiled codebase).

 

[Cysign]

For now I stopped working on this issue, since the seller took the RC-600 back (after 3.5 years - casual warranty has been over, but I insisted on the hidden defect) for full refund.

I'll get an used Singular Sound Aeros Gold, very soon

Also I sold my RC-5 for the moment (I'll be back on this issue when they become cheaper on the used market - so I won't waste so much money if I brick it during the voltage glitch to flash my modified firmware).

Since the raspberry Pi 3 also is based on an similar ARM v7 technology, one would be able to test the decompiled midi implementation on a cheap and open source platform. Just be sure to take a realtime kernel for this and bind the task with high priority to one core. You'd just need an low-latency I2S DAC and DAC for the Raspberry. There are some projects available to get things started: https://github.com/ryankurte/rpi-i2s-stereo/blob/master/instructions.md

That's way more easy than voltage glitching a bugfix into the Boss RC-devices for testing.

 

[Cysign]

Oh wow, deep-diving into voltage glitching I found this hardware/software tools:

Voltage Glitching with the Pico Glitcher and Findus

Fault injection attacks against microcontrollers can be very rewarding for attackers, if they are successful. In this article, a new hardware device for performing voltage glitching attacks, the Pico Glitcher, and its fault injection software library findus are demonstrated.

blog.syss.com

The whole setup is able to find the voltage glitching time frame within a reproducible nanosecond range.
And the best thing: it is cheap!

So injecting a custom firmware should be possible

In the best-case scenario, hardware glitching is only required once - to flash a custom firmware. If you implement a button shortcut into that initial build, you permanently unlock the update restrictions, allowing all future custom firmware updates to be installed directly without any glitching gear.

So maybe repairing broken firmwares in current Boss RC loopers might become a business model


So if someone wants to donate one of the following loopers (even broken devices would be interesting), I'd like to buy the hardware for voltage glitching and play around with:
Boss RC-10R, Boss RC-5, Boss RC-500, RC-505 MKII , RC-600

Sonce I sent my RC-600 back and sold my RC-5 for buying an Singular Sound Aeros Gold edition, I need free test hardware to go on.

 

[Cysign]

Finally I got two flawless working loopers which are able to properly sync to an external midi-clock.

Besides the RC-600 0xFA issues, the Launchpad Pro MK3 indeed has midi clock jitter.
So whilst testing my new Zoom* MS90LP+, I added a midi-merger to my setup - so I can merge my TR-8s clock with my Deepmind 12 midi keyboard (it's configured to be not used internal, but send midi to my Launchpad Pro MK3), which then is able to control 4 sequencer tracks.

Using the TR-8s midi-clock running through the Launchpad Pro and the Singular Sound Aeros and/or my Zoom* MS90LP+ I finally can use my setup as wanted. I'm so happy I got the full money back from the RC-600 and finally got two working solutions