Roland/Boss RC-50 Loopstation PATCH.RC5 File Analysis

Greetings once again readers, it's been a while..

Tonight I want to talk about the Roland RC-50 Loopstation.  It is a really nice, yet-not-quite-perfect-yet, looping pedalboard that lets one record up to three different tracks on a patch.  It's 24minutes of 16-bit stereo 44.1kHz memory is, in this day and age, a bit paltry, so one has to heavily utilize the USB file-sharing capability of the unit.

(future project:  RC-50 RAM upgrade?)

For now, I just want to easily transfer #1 my files, and #2 certain patch settings, such as tempo, time signature, guide rhythm selection, volumes, etc..  Sadly, Roland/Boss has not offered any kind of host-side patch-editor for the RC-50.  Will they?  I don't know.  The RC-300 is the new baby, and sounds like it has better file-handling capabilities, so we'll see.

Now, for either Loopstation... Since I'm a Cakewalk user, the dream would be to have an RC-50 Cakewalk add-in that would just convert the RC-50 patch values, such as tempo, time-signature, etc. to the appropriate project and channel track settings on Cakewalk   One could offer an interface to instantiate a copy of the RC-50 guide rhythm as a new channel strip.  It could be a GREAT melding of technologies and would really expand the RC-50 as a compositional tool.  And now that Cakewalk is under the Roland roof, maybe we'll see something pop up.   (Hint hint)...


Speaking of that, Roland/Boss, (the legal team in particular), if you're reading this : What I'm doing here is posting my own comparison of the PATCH.RC5 file generated by twiddling knobs and settings on the RC-50...  and then seeing what changes on the PATCH.RC5 file.  These are visual observations whose results, I don't think, violate any kind of applicable license-agreement, NDA, etc.  I am publishing these findings in the hopes of helping proud RC-50 users get more out of their equipment.  I do this in the spirit of goodwill - that more people will feel good about using your products and will recommend them to others.   (I urge you to publish file and interface specifications a bit and let those in your user community contribute to your own product's growth - maybe even saving you some of the heavy-lifting along the way).  So I do humbly ask that you allow me to post my research here without legal hassle.    Thanks.  I hope my work improves your bottom line.  You've make some truly excellent gear over the years, and I don't mind giving back.


Allright on to the good-stuff:  So here's what I've found so far...
(Note: this is an ongoing project, specs will be added as found.  Also, please comment with any corrections or your own findings)

(DISCLAIMER - Blogspot's text handling doesn't work well for this mostly tabular data, but I think it's still readable.  And I've worked on it long enough.  I'll figure out how to better format it or see if there's a code-box feature that's hiding from me. Hope it helps!)

PATCH.RC5 analysis

Notes & todo:
-------------
Done:  All options under the NAME/PATCH menu figured out - still a gap at 0x15-0x1c
ToDo:  many patch-level bytes, phrase-level bytes remain


File Summary:

File Header size = 64 bytes
Patch len        = 87 bytes * 100


// NOTE: Byte offsets are from file-zero in this section:
  
Range (0x = hex)        Patch Offset  Field Name                      Values, notes, etc.
---------------------   ------------  -----------------------------   ------------------------------------
   0 0x00 -> 63 0x4e                  PATCH.RC5 File-level Header     BOSS RC5 FORMAT TYPE 1.00 V1.00 B0171 2006/05/06
  64 0x40 -> 79 0x4f    (0x00-0x0f)   Patch 001: Name                 
  80 0x50               (0x10)        Patch 001: Patch Volume Level   (0 - 100)
  81 0x51               (0x11)        Patch 001: Phrase Change        (0 = IMMEDIATE, 1 = LOOP END)
  82 0x52               (0x12)        Patch 001: Fade Out             (0 - 100)
  83 0x53               (0x13)        Patch 001: Fade In              (0 - 100)
  84 0x54               (0x14)        Patch 001: MIDI Sync            (0 = AUTO, 1 = INTERNAL, 2 = REMOTE)
  93 0x5d -> 0x5e       (0x1d-0x1e)   Patch 001: Tempo                (400 - 2500 (40.0 - 250.0 bpm))
  95 0x5f               (0x1f)        Patch 001: Patch:Input Out      (0 = MAIN, 1 = SUB , 2 = MAIN+SUB)
  97 0x61               (0x21)        Patch 001: Guide Level          (see notes below for values, etc)
  98 0x62               (0x22)        Patch 001: Guide Rhytm          (see notes)
  99 0x63               (0x23)        Patch 001: Time Signature       (see notes)             
 118 0x76               (0x36)        Patch 001: PHRASE1 BLOCK START           
 123 0x7b               (0x3b)        Patch 001: Phrase1 Level        (see notes)
 128 0x80               (0x40)        Patch 001: Phrase1 Simulstart   (0 or 1)
 129 0x81               (0x41)        Patch 001: PHRASE2 BLOCK START           
 134 0x86               (0x46)        Patch 001: Phrase2 Level        (see notes)
 139 0x8b               (0x4b)        Patch 001: Phrase2 Simulstart   (0 or 1)
 140 0x8c               (0x4c)        Patch 001: PHRASE3 BLOCK START          
 145 0x91               (0x51)        Patch 001: Phrase3 Level        (see notes)
 150 0x96               (0x56)        Patch 001: Phrase3 Simulstart   (0 or 1)
 151 0x97 -> 237 0xed                 Patch 002: (full patch)        
  .                                          .
 238 0x98 -> 324 0x144                Patch 003: (full patch)        
  .                                          .
  .                                          .
8590 0x218e -> 8676 0x21e4            Patch 100: (full patch)


// More specific notes about certain patch settings are found here...
// NOTE: Byte offsets are from each patch-start in this section:

Tempo Patch offset       = 29 0x1d (msb), 30 0x1e (lsb)
-------------------------------------------------------
Tempo value 2-bytes, in tenths of bpm
Tempo value range min 0x0190 400   (40.0 bpm)
Tempo value range max 0x09c4 2500 (250.0 bpm)

Guide level offset       = 33 0x21
----------------------------------
Guide level min = 0   0x00  (screen value = 0)
Guide level mid = 50  0x32  (screen value = 100)
Guide level max = 100 0x64  (screen value = 200)

Guide rhythm offset      = 34 0x22
----------------------------------
Guide rythm start value  = 0  0x00
Guide rythm max value    = 55 0x37

Time Sig offset          = 35 0x23
----------------------------------
Time Sig Values:
00 = 2/4
01 = 3/4
02 = 4/4
03 = 5/4
04 = 6/4
05 = 7/4
06 = 5/8
07 = 6/8
08 = 7/8
09 = 8/8
0a = 9/8
0b = 10/8
0c = 11/8
0d = 12/8
0e = 13/8
0f = 14/8
10 = 15/8

First Phrase1 Level Field= 123 0x7b
First Phrase2 Level Field= 134 0x86
First Phrase3 Level Field= 145 0x91
-----------------------------------
Phrase level min = 0   0x00  (screen value = 0)
Phrase level mid = 50  0x32  (screen value = 100)
Phrase level max = 100 0x64  (screen value = 200)

Mass Airflow Sensor find and fix in 1997 Nissan Pathfinder

Posted the core of this to FixYa and thought I'd add more detail and post it here as well, in case someone searching can benefit from this random part failure:

One day, out of the blue, my Pathfinder engine cut out as I started to drive.  It then cut out randomly.  The way it was failing 'felt' electrical in nature, like a connection was going bad.

So, I'd start the car and quickly run out and start tapping on all things electrical.  The MAF, or Mass-Airflow Sensor (not to be confused with MAP, the manifold air pressure), is located on the front airbox-airtube assembly and was a natural to tap on.  I got lucky.  The first think I tapped on killed the engine.
Did it again... and again, and again.  The Mass Airflow Sensor was definitely to blame.

I realized that it was caused by vibration, and that I could "reset" the car while driving as long as I didn't get above about 2700 RPM's.  I was in "safe mode".  Riiiight.

Got home, looked at the prices of these buggers, and they were in the $300-$800 range.  Eep!

For that price, I'm going in!
(I also verified the MAF sensor code with my newly built USB to OBDII converter found here.  It was the P0100 "MAFS" error)
I removed the MAF sensor by unscrewing the 4 screws and gently lifting it out of the air passage.

With the screws off, I was able to gently pry the cover off.  What I found was a little controller board encased in a jelly, presumably to isolate the board from the elements, and three little thin wires leading to the external connector.  Without even having to break out the multimeter, I could tell that one of the wires had broken due to vibration fatigue or some other manufacturing defect.  I recall I had to break all three wires to get the thing to open fully.

Soldering this was very difficult due to the presumably silicone jelly.  It made the metal very resistant to bonding with solder.   Without digging too much into the jelly, I exposed all wires and eventually, with scraping, fire, and flux, managed to get solder to stick decently to the various wires, adding my own jumper wires to make it easier to bridge the gap and close the case.

I needed to make this fix road-worthy, so I folded their wires around an insulating piece of clear plastic I cut from some plastic packaging material.  The wires folded nicely around it into place and the case closed.

Several years later, the fix is holding strong, or so it's continued functioning would lead me to believe!

I hope someone out there found this useful, please comment if you do.

Coop Door Code Update Success!

Firstly, a thank-you to Brian, who commented on my last post.  I had a very detailed reply, but commenting on Blogspot seems to be borked for me.  I'll try to answer some of your questions at some point in time if I get commenting fixed.

Now, on to the progress...    I finally implemented sunrise/sunset time-offsetting for the door.  If I enable either sunrise or sunset offsetting, the door-open time becomes a base time, and then the controller checks the day-of-year, and does a table-lookup to obtain the offset in minutes.  It adds the offset to the door-open time, and subtracts the offset from the door-close time.  Now the Winter Solstice has passed, the days are starting to get longer again, so I got this in place just in time.

I also gutted the code that checks to see if it's time to open or close the door and made it a lot simpler.

Lastly, and this was probably the biggest "bugfix", I added some "keepalive" code to the WiFi connection.  Before, if the connection dropped, the BlackWidow board wouldn't do anything to reconnect.  I would have to go out and reboot the controller in order to get it talking to the network again.   To fix this, I added a method to the WiShield object that returns the WiFi connection status.  The webserver checks this periodically and re-inits the WiFi connection if it is down.