Patch Request Formatting Toolkit

General discussion
1

I’ve just successfully added Patch Request rules to my Yamaha TX81Z preset. It was very time consuming to add it, but it really doubles the usefulness of the Electra One and sets it above other hardware controllers. What’s on the Electra One screen is now in sync with the synthesiser, giving full bi-directional control.

I’ve written an ExtendScript program that runs in Photoshop to format the code that can be pasted into the preset file. I know that’s an unusual use for Photoshop, but it’s a dev environment I frequently work in as a graphic designer, and it’s a way of easily accessing the computer file system. Perhaps another developer can adapt it to something more universal like a browser or Node.js for those who don’t have a copy of Photoshop.

The first step was to receive bulk data messages from the synth to test if the SysEx voice bulk dump request was correct. I added a pad to an Electra one preset with the following:

["43", "22", "7E", "4C", "4D", "20", "20", "38", "39", "37", "36", "41", "45"]

This instructs the synth to return the VCED and ACED (Yamaha’s groupings of parameters, short for VoiCe EDit buffer and Additional voiCe EDit buffer) on Midi channel 3. On my MacBook I used SysEx Librarian to record the response.

The TX81Z returns 2 responses to this request, one for the VCED and another for the ACED. The ACED header is:

["43", "02", "7E", "00", "21", "4C", "4D", "20", "20", "38", "39", "37", "36", "41", "45"]

I then took all the HEX codes in the response and pasted them onto a spreadsheet, and labelled the parameters, being sure to include the bit size of each, and the parameter IDs I’d used in my Electra One template.

ACED spread
ACED spread1390×1578 286 KB

I discovered that the original manual has many errors which added a lot of confusion! I found a helpful tip on another forum that the manual for the Yamaha V50, a descendent of the DX and TX synths, has more accurate documentation of the TX81Z. I was able to confirm this after recording more tests in SysEx Librarian.

Once the spreadsheet was complete, I exported it as a CSV file, and ran ‘ElectraPatchRequestFormat.jsx’ from Photoshop. This exports JSON files of the response rules in the same location, which looks like this:

"rules": [
	{
		"bPos": 0,
		"byte": 18,
		"id": 18,
		"msg": "sysex",
		"pPos": 0,
		"size": 3
	},
	{
		"bPos": 0,
		"byte": 8,
		"id": 19,
		"msg": "sysex",
		"pPos": 0,
		"size": 3
	},

Next is to assemble all the pieces in the preset file in a text editor. In the preset file look for the “devices” node, and paste in the request, response header and rules data:

"devices": [ { "patch": [ {
	"request": [-->paste SysEx request here<--],
	"responses": [ {
		"header" : [-->paste SysEx response header here<--],
		"rules": [
				{-->paste rule 1 here<--},
				{-->paste rule 2 here<--},
				{-->paste rule 3 here<--},
				{-->paste rule 4 here<--}
		]
	} ]
} ] } ]

Here’s what some of the TX81Z preset file looks like:

{
  "request": ["43", "22", "7E", "4C", "4D", "20", "20", "38", "39", "37", "36", "41", "45"], 
  "responses": [
	{
	  "header": ["43", "02", "7E", "00", "21", "4C", "4D", "20", "20", "38", "39", "37", "36", "41", "45"], 
		"rules": [
			{"bPos": 0,"byte": 18,"id": 18,"msg": "sysex","pPos": 0,"size": 3},
			{"bPos": 0,"byte": 8,"id": 19,"msg": "sysex","pPos": 0,"size": 3}

I’ve included the TX81Z spreadsheets and JSX script in this file:

https://www.urbanspaceman.net/shared/ElectraPatchRequestFormat.zip

Other users can use my spreadsheets and JSX file to help with the data wrangling.

4 Likes
2

That looks fantastic!
Any guess if this might a good start for a FS1R template?

3

The FS1R came out 12 years later, so it’s much more complex. I’ve laid out the workflow here, but there’s many more parameters to list. Looks like page 37 of this is where you’d have to start.

4

@urbanspaceman
I am so happy to see this. Thanks!

Not everybody has the Photoshop, but still, they are users who do. This is very encouraging for developers around. And also, it is a real-world validation of the Preset file format idea.

5

@martin Perhaps some more capable developers can update it to use node.js or something similar, if they find it useful. I work a lot with ExtendScript in Adobe software, so that’s just my go to platform for manipulating the file system, as I’m familiar with it.

6

yes. We will definitely do that. Btw, I used your image toolkit when working on the algorithm images for TX7. It is just brilliant!

7

@martin Glad it was useful! Did you fit 6 operators in there? :astonished: :smile: There’s certainly an art to drawing 48 x 18 graphics without any aliasing.

8

I was, in a way, but it was very small. It brought us to thinking how to implement support for more or variable sizes iof images.

9

Really nice job.
I wonder if this would be fully or semi automatable?
Imagine you feed the script an “INIT PATCH”, then add a parameter one by one by feeding a sysex of an “INIT PATCH” with the adjusted parameter ( min, max or negative, 0 and the positive value), its range and let the script decode the sysex.

Well I have still lots to learn about sysex, nrpn and midi in general. But your jsx script looks very usefull.

10

There is indeed some use to be made when having larger images. Not only for operators, but for instance when parameters control the way effects are connected to sound sources, or when filters may be connected in series or parallel to oscillators. What would be nice is to have images with the following capabilities:

  • The images could occupy the space of 4 controls permanently.
  • But a temporary mode would be useful as well. This would mean the larger picture is squeezed back into the place for one control, but you should be able to open it up, just like is done with EG’s.