Pioneer AS1 - help in getting bidirectional communication using a sysex dump

Instruments
1

Hi I just got a AS1 Pioneer synth and see there is an editor that works fine but is not bi-directional.

There is a free editor (LE version) which works fine.
When I send F0 00 40 05 00 00 01 08 10 06 F7 I get the patch data including the parameters.

How would I find out where each parameter resides in the sysex data the AS1 returns?

The AS1 is not a very complicated synth.
If its needed I can try to modify the individual parameters one by one to spot the location and their size/range.
Can someone give some hints on howto do this?
Would I need to modify each parameter on the synth 3 times to spot at what byte it starts and what its range is? Are there tools/scripts that can help with this?

http://docs.pioneerdj.com/Manuals/TORAIZ_AS_1_DRI1434A_manual/

image_2021-09-22_195818
image_2021-09-22_1958181164Ă—493 86.1 KB

1 Like
2

Here I compared the sysex of 2 dumps of 2 init patches 1 with the resonance set to 0 and the other set to 64

resonance has a range from 0 - 165

image_2021-09-22_220843
image_2021-09-22_2208432298Ă—866 111 KB

How long would the header be? what symbol marks the end of the header?
or doesn’t it matter how long exactly as long the bytes are static?

Is 00 40 05 00 00 01 08 the header?

I found this tutorial: Guide/tutorial for patch request button? - #16 by martin

this topic should be moved to templates.

1 Like
3

Hi,

I took a look at the AS1 manual. The Edit buffer dump has following structure:

image
image1514Ă—758 68 KB

The header ends at position 9 (as shown in your tool), ie. with byte 03h. It is an identifier of the Edit Buffer Data. The following 1024 bytes are the actual parameters. The parameter data is packed with the MS bit algorithm. It converts 8-bits values to 7-bit values (that can be transmitted with MIDI). I did not find the description of the MS bit format in the AS1 manual. I do believe, however, that sequential synths are using it too and it is described in their user guides.

1 Like
4

Thanks Martin,
will study and try, I am looking in the Prophet 6 manual and it looks the same as the AS-1.

This is from the Prophet 6

Data is packed in 8 byte “packets”, with the MS bit stripped from 7 parameter bytes, and packed into an eighth byte, which is sent at the start of the 8
byte packet.

This explains why it takes 1171 MIDI bytes to transmit 1024 Program data bytes

1 Like
5

yup, this is it. It means that you will have to compose the each parameter value by combining the 7-bit part (from one sysex byte) with the 1-bit from another sysex byte. It is definitely doable.

6

Ok its getting spicy :slight_smile: :grinning:

In my case the NRPN parameter order do not seem to match the sysex data.
But i will investigate this further.
I think the parameters might follow after globals, patchname etc.
But also it needs to be unpacked I guess.
How would the ONE handle the unpacking? I checked but cannot find how to do this.

Here a javascript that Converts 8 bytes of “packed MS bit” sysex into the original 7 bytes.
Honestly I do not understand it fully but might come in handy.

[https://cycling74-web-uploads.s3.amazonaws.com/531ee78c4db05f8762373b5f/2019-12-19T09:45:56Z/packedMS.js]

Was hoping to find a DSI synth template that have “PATCH REQUEST” but there are none. There are several DSI synth templates but none parse the sysex patch response. I found yours here: [Electra One App]

I found some additional info, this is from the DSI evolver.

converting packed data formatted sysex data - MaxMSP Forum | Cycling '74

you have to process each slice of 8 bytes with bitshift operators to get the original 7 source parameters

the parameters are ordered according to their NRPN parameter number

Parameter: V_OSC_1_FREQ
NRPN: 0
Value: 0-60

Parameter: V_LOWPASS_FREQ
NRPN: 49
Value: 0-164

Parameter: V_LOWPASS_FREQ
NRPN: 50
Value: 0-255

Patch request “00 40 05 00 00 01 08 10 06”
Header “00 40 05 00 00 01 08 10 03”

Since the AS1 does not send SYSEX per parameter is the example below correct?
Do I extract all parameter in the rules section like this?
Only referring to “request”, “header” and and example of 2 bogus parameters extracted from the response.

  "patch": [
    {
      "request": ["00", "40", "05", "00", "00", "01", "08", "10", "06"],
      "responses": [
        {
          "header": ["00", "40", "05", "00", "00", "01", "08", "10", "03"],
          "rules": [
            {
              "type": "sysex",
              "paramterNumber": 1,
              "parameterBitPosition": 0,
              "byte": 1,
              "byteBitPosition": 0,
              "bitWidth": 7
            },
            {
              "type": "sysex",
              "paramterNumber": 49,
              "parameterBitPosition": 0,
              "byte": 1,
              "byteBitPosition": 0,
              "bitWidth": 7
            },
          ]
        }
      ]
    },
1 Like
7

I am about to run to meetings and they will keep me pretty much busy will Saturday. So just a few quick hints. If it does not help, I will send you an example at the weekend.

This describes the parameter where the value (or its part) will land. If AS1 uses NRPN parameters in the preset. You need to set the type to nrpn.

            {
              "type": "nrpn",
              "parameterNumber": 1,
              "parameterBitPosition": 7,
              "byte": 1,
              "byteBitPosition": 0,
              "bitWidth": 1
            },
            {
              "type": "nrpn",
              "parameterNumber": 1,
              "parameterBitPosition": 0,
              "byte": 2,
              "byteBitPosition": 0,
              "bitWidth": 7
            },

This is an example of rules that will set value of NRPN parameter 1 by taking one bit of the byte 1 from the patch dump (placed at MSB) and combining it with 7 bits out of byte 2. I hope it will help. This will form full 8 bit value in the NRPN parameter.

I hope you catch my drift :slight_smile:

1 Like
8

Thanks, I will study further and try.

Here is a DSI Mopho CTRL panel with [PATCH SEND] and [PATCH GET] implemented.

[https://ctrlr.org/?ddownload=50275]

9

I found 2 useful command line tools working on Linux, Windows and MAC

[GitHub - gbevin/SendMIDI: Multi-platform command-line tool to send out MIDI messages]
[GitHub - gbevin/ReceiveMIDI: Multi-platform command-line tool to monitor and receive MIDI messages]

examples on windows powershell:

  1. get the midiport:
.\sendmidi list
Toraiz AS-1
  1. get the edit buffer from the AS-1
.\sendmidi.exe dev "Toraiz AS-1" hex syx 00 40 05 00 00 01 08 10 06
  1. catch the sysex in a file and stdout
.\receivemidi.exe dev "Toraiz AS-1" | tee BASICPROGRAM-OSC1-C0-LOWEST.txt
2 Likes
10

Parameter: V_OSC_1_FREQ
NRPN: 0
Value: 0-60

On the right the value is set to 0 and on the left to 60 (C5 note)

00-3C = 0-60, So if I use the header as below then the position of the nrpn parameter is at byte 0 in the sysex. 0 is also the nrpn number.

Capture
Capture2973Ă—698 92.6 KB

But below does not work.

  "patch": [
    {
      "request": ["00", "40", "05", "00", "00", "01", "08", "10", "06"],
      "responses": [
        {
          "header": ["00", "40", "05", "00", "00", "01", "08", "10", "03", "00"],
          "rules": [
            {
              "type": "nrpn",
              "parameterNumber": 1,
              "parameterBitPosition": 0,
              "byte": 0,
              "byteBitPosition": 0,
              "bitWidth": 7
            }        
          ]
        }
      ]
    }
  ]
}

Here is the full instrument file.
I tried to add a patch request button. But the OSC1 Freq, parameterId 1 is not getting updated after i fire a patch request.

It would be great if you could provide some examples.
Also we discussed earlier that the bytes might be packed but I see now the whole parameter for osc frequency is just in the 1st byte. Are bytes only packed if 8 bits are needed?

toraiz-3.epr (56.6 KB)

1 Like
11

Took a quick look at the preset. I can see that OSC1 FREQ has actually parameterNumber set 0. The parsing rule points to the parameterNumber 1. That could cause the mismatch in assigning the value. Can you try to change it?

Also, if you provide with the SysEx message (as a file) that AS1 sends as a patch dump, I will be able to dive into it more efficiently. An output of readmidi would be just perfect.

12

Hi Martin, sure here are the dumps:

AS1-Toraiz.zip (2.5 KB)

The zip contains an Init Patch (Basic Program) and a dump file for the following parameters:

Parameter: V_OSC_1_FREQ
NRPN: 0
Value: 0-60
Hex: 00-3C
byteBitPosition: 0
Byte 1

Parameter: V_OSC_1_SYNC
NRPN: 1
Value: 0-1
byteBitPosition:
Byte 14
Hex 00-01

Parameter: V_OSC_1_LEVEL
NRPN: 2
Value: 0-127
byteBitPosition: 0
Byte 10
Hex 00-7F

V_OSC_1_SHAPE
NRPN: 3
Value: 0-254

V_OSC_1_PULSE_WIDTH
NRPN: 4
Value: 0-255

At V_OSC_1_SHAPE I get completely lost, I see byte 0, 6 and another one gets changed ???
I expected 1 byte from 0-127 and the second from 128-254

V_OSC_1_Pulse_width set to 0, I see Byte 7 getting changed from 7F to 00
Set to 255 byte 0 gets updated… So my simple logic does not suffice.
Do the hex files have to be unpacked somehow?
How do I apply bit-shift operations to each slice of 8 bytes as mentioned earlier?
Totally guessing here. :slight_smile:

Meanwhile I was reading [GitHub - francoisgeorgy/BS2-SysEx: Reverse engineering of the Novation Bass Station II SysEx format.] putting it here as a reference.

13

haven’t tried to change it.

so in the template osc freq parameterNumber set 0
but I set it 1…
ok will try. yeah i was using the id which is one.
good to know the parameterNumber needs to be used.

“controls”: [
{
“id”: 1,
“type”: “list”,
“name”: “OSC1 FREQ”,
“color”: “F45C51”,
“bounds”: [
0,
40,
146,
56
],
“pageId”: 1,
“controlSetId”: 1,
“inputs”: [
{
“potId”: 1,
“valueId”: “value”
}
],
“values”: [
{
“message”: {
“type”: “nrpn”,
“parameterNumber”: 0,
“deviceId”: 1
},
“overlayId”: 1,
“id”: “value”
}

14

Hi Martin,

I checked and at least my patch request button is working. I see request and reply.
However the V_OSC1_FREQ does not get update if I press the patch request button.

Also if I turn the knobs on the synth should de Electra One also get updated?

An example and some hints will be very welcome.

Cheers

Tim

This is from the patch dump where the last value is the V_OSC1_FREQ parameter set to 60 = C5:
F0 00 40 05 00 00 01 08 10 03 00 3C
So as header I tried 00 40 05 00 00 01 08 10 03
Or with one byte more

then tried with “byte”: 1, “byte”: 0, or “byte”: 2,
But no update,

    "patch": [
    {
      "request": ["00", "40", "05", "00", "00", "01", "08", "10", "06"],
      "responses": [
        {
          "header": ["00", "40", "05", "00", "00", "01", "08", "10", "03"],
          "rules": [
            {
              "type": "nrpn",
              "parameterNumber": 0,
              "parameterBitPosition": 0,
              "byte": 1,
              "byteBitPosition": 0,
              "bitWidth": 7
               }        
             ]
           }
         ]
       }
    ] 
  }
 ]
}
15

$ ./hair.sh BASICPROGRAM-OSC1-C0.hex BASICPROGRAM-OSC1-C5.hex
system-exclusive hex 00 40 05 00 00 01 08 10 03 00 003C 18 7F 00

Here 003C is byte 1 after the header where 00-3C is a range of 00-60 dec.
Which is exactly the OSC1 range from note C0 to C5.

I checked in the Electra Console app and when I click the “PATCH REQUEST” button I do se the request message and get the patch dump.

The toraiz is set on midi channel 3 as well that is set in the template.
Connected via USB host and midi cable. When I press the “PATCH REQUEST” button the “usb midi”, “midi1 out” and later the “midi1 in” and “usb midi” lits up.
But no values change…

{
“id”: 91,
“type”: “pad”,
“mode”: “toggle”,
“visible”: true,
“name”: “GET PATCH”,
“color”: “529DEC”,
“bounds”: [680,40,146,56],

  "pageId": 1,
  "controlSetId": 1,
  "inputs": [
    {
      "potId": 7,
      "valueId": "value"
    }
  ],
  "values": [
    {
      "id": "value",
      "message": {
        "type": "sysex",
        "deviceId": 1,
        "data": [
          "F0",
          "00",
          "40",
          "05",
          "00",
          "00",
          "01",
          "08",
          "10",
          "06",
          "F7"
        ],
        "onValue": 1,
        "offValue": 0
      },
      "defaultValue": "off"
    }
  ],

“patch”: [
{
“request”: [“00”, “40”, “05”, “00”, “00”, “01”, “08”, “10”, “06”],
“responses”: [
{
“header”: [“00”, “40”, “05”, “00”, “00”, “01”, “08”, “10”, “03”],
“rules”: [
{
“type”: “nrpn”,
“parameterNumber”: 0,
“parameterBitPosition”: 0,
“byte”: 1,
“byteBitPosition”: 0,
“bitWidth”: 7
}

16

{“version”:2,“name”:“Toraiz 1control”,“projectId”:“Hr2hrw3aMvySzGootosu”,
“pages”:[{“id”:1,“name”:“Page 1”}],
“groups”:,
“devices”:[{“id”:3,“name”:“Generic MIDI”,“port”:1,“channel”:3}],
“overlays”:,
“controls”:
[{“id”:1,“type”:“fader”,“visible”:true,“name”:“NRPN”,“color”:“FFFFFF”,“bounds”:[0,40,146,56],“pageId”:1,“controlSetId”:1,“inputs”:[{“potId”:1,“valueId”:“value”}],“values”:[{“message”:{“type”:“nrpn”,“deviceId”:3,“lsbFirst”:false,“parameterNumber”:0,“min”:0,“max”:60},“min”:0,“max”:60,“defaultValue”:24,“id”:“value”}]},
{“id”:2,“type”:“pad”,“mode”:“toggle”,“visible”:true,“name”:“GET PATCH”,“color”:“529DEC”,“bounds”:[170,40,146,56],“pageId”:1,“controlSetId”:1,“inputs”:[{“potId”:2,“valueId”:“value”}],“values”:[{“id”:“value”,“message”:{“type”:“sysex”,“deviceId”:3,“data”:[“F0”,“00”,“40”,“05”,“00”,“00”,“01”,“08”,“10”,“06”,“F7”],“onValue”:1,“offValue”:0},“defaultValue”:“off”}]}],
“patch”: [{
“request”: [“00”, “40”, “05”, “00”, “00”, “01”, “08”, “10”, “06”],
“responses”: [
{
“header”: [“00”, “40”, “05”, “00”, “00”, “01”, “08”, “10”, “03”],
“rules”: [
{
“type”: “nrpn”,
“parameterNumber”: 0,
“parameterBitPosition”: 0,
“byte”: 0,
“byteBitPosition”: 0,
“bitWidth”: 7
}
]
}
]
}
]
}

Here the simplest config with 1 control and a patch request button. NRPN works bidirectional. When I press the “patch request” data flows but no pot update

17

Hi @Flyweight,

I finally had a moment to dive deep into that. This is an adjusted version of the preset that reads the OSC1 FREQ and OSC1 PW parameters.

The patch object is in the device definition. there are three rules. One for OSC1 FREQ and two rules for the OSC1 PW. OSC1 PW requires two rules as the extra packed bit needs to be used in order to support the range of values 0 - 250. OSC1 FREQ, on contrary does not need to have the rule for getting the packed bit as the value never goes above 127. I hope you catch my drift.

The OSC1 PW

                        {
                           "type":"nrpn",
                           "parameterNumber":0,
                           "parameterBitPosition":0,
                           "byte":1,
                           "byteBitPosition":0,
                           "bitWidth":7
                        }

The OSC1 PW

                        {
                           "type":"nrpn",
                           "parameterNumber":4,
                           "parameterBitPosition":0,
                           "byte":7,
                           "byteBitPosition":0,
                           "bitWidth":7
                        },
                        {
                           "type":"nrpn",
                           "parameterNumber":4,
                           "parameterBitPosition":7,
                           "byte":0,
                           "byteBitPosition":6,
                           "bitWidth":1
                        }

Unfortunately, as you mentioned, the sysex bytes do not reflect order of NRPN parameters. So the most difficult part on this preset is to figure out positions of the parameters in the sysex message. I knid of do not like the idea of taking the info ot of the CTRL panel :slight_smile: Too bad that the patch dump documentation is not the User Guide.

Please review my version of the preset. I am sure you will get what I have done. Then we can discuss how to go further with that.

toraiz-with-patch-parsing.epr (68.8 KB)

1 Like
18

thanks a lot Martin, will try it out soon.

19

I tested that with the sysex files you sent to me. It seems to work fine. So, as long as the Edit buffer dump request is fine, it should work with the hardware synth too.

20

ok we will see.
later I would like to do the same for my Mirage template.
if it works I will try to add some other parameters.

anyhow thanks a lot to get me started.