Hello. My name is Josie Hill and I've been involved in MIDI since the mid 1980s when I wondered what those sockets were on the back of of my Roland JX3P. Roland Japan would not supply me the format of the MIDI memory map dump from a Roland TR707 drum machine because they opined it would be too hard for me to understand! However, I managed to reverse engineer it.
Now, 30 years on, I have a similar problem with the first version 1.1 Fender Cyber Twin PS-393. Can anyone please supply me with the format of the 55 byte data block per preset?
Now, 30 years on, I have a similar problem with the first version 1.1 Fender Cyber Twin PS-393. Can anyone please supply me with the format of the 55 byte data block per preset?
Yes, it probably WAS too difficult for you to understand. Probably too difficult for ANYONE to understand, unless you were a computer scientist working for Roland! They are better now, they're discovered the value of a few examples of real world use of SYSEX, although sometimes they aren't perfect.
If you have the manual for your whatsit, this OUGHT to have the midi map, so if you have a spare weekend you might try to make sense of it. I have enough of my own whatsits, so I've not bothered with your Fender thingie, which may well be even more complicated than the midi map. Otherwise I'll have to try and find the midi manual on the web, and try and make sense of it via html,
But hopefully, someone here might have such a device, with the manual, and be able to quote you the details
But, being a nosey blighter, I just might check the web abyway.
Geoff
If you have the manual for your whatsit, this OUGHT to have the midi map, so if you have a spare weekend you might try to make sense of it. I have enough of my own whatsits, so I've not bothered with your Fender thingie, which may well be even more complicated than the midi map. Otherwise I'll have to try and find the midi manual on the web, and try and make sense of it via html,
But hopefully, someone here might have such a device, with the manual, and be able to quote you the details
But, being a nosey blighter, I just might check the web abyway.
Geoff
Well, can't find any mention of a CyberTwin PS-393.
I do find a CyberTwin PR-393, this is a Guitar Amplifier, and yes, it does have some midi functions, incl a data dump There are details in the manual for the format of the Preset, although while you say this is 55 bytes, the detail I see shows 12 bytes only, although the doc I've seen has the full details for those 12 bytes, namely what each of the items is, and what all the options for each are, and there is a clear example of the SYSEX command to implement the settings.
So, there's some sort of mix up somewhere. Are there other varieties of CyberTwin, is the PS-393 something quite different?
Oh, the device I was looking at is specifically a CyberTwin SE. The 'PR-393' is not mentioned. I just happened to see on the pic of the rean panel hat it said PR-393.
Geoff
I do find a CyberTwin PR-393, this is a Guitar Amplifier, and yes, it does have some midi functions, incl a data dump There are details in the manual for the format of the Preset, although while you say this is 55 bytes, the detail I see shows 12 bytes only, although the doc I've seen has the full details for those 12 bytes, namely what each of the items is, and what all the options for each are, and there is a clear example of the SYSEX command to implement the settings.
So, there's some sort of mix up somewhere. Are there other varieties of CyberTwin, is the PS-393 something quite different?
Oh, the device I was looking at is specifically a CyberTwin SE. The 'PR-393' is not mentioned. I just happened to see on the pic of the rean panel hat it said PR-393.
Geoff
Thank you Geoff
But, the point is, I did eventually understand the Roland TR707 and I thought they were being a bit cocky, as did the person I spoke to so often at Roland UK. Things were completely different way back then. A much smaller community and we all knew each other and shared a lot of stuff between each other.
I'm a fair way through this now but I have been hindered by a complete failure of the system drive in my PC.
I seemed to have more tools way then also and I only had a Commodore 64.
I was also only about 40 then too. Haha haha
Josie
But, the point is, I did eventually understand the Roland TR707 and I thought they were being a bit cocky, as did the person I spoke to so often at Roland UK. Things were completely different way back then. A much smaller community and we all knew each other and shared a lot of stuff between each other.
I'm a fair way through this now but I have been hindered by a complete failure of the system drive in my PC.
I seemed to have more tools way then also and I only had a Commodore 64.
I was also only about 40 then too. Haha haha
Josie
Thank you again Geoff,
You aren't the Geoff who worked for Roland UK way back then?
Yes. It was a complete memory failure on my part and it is PR 393.
All the Fender Cyber Twin manuals I have or have ever viewed on line don't contain the formatting of the data itself but only with the data packet is wrapped to be dumped.
The total number of bytes delivered is 68, but includes a SYSEX file start marker and file end marker. The total packet size of the data file is 55 bytes but includes a SYSEX header and SYSEX end of file duo, the checksum and 0xF7.
That leaves 47 bytes of raw real preset dump data.
That data is bit 7 compressed which, after the preset number, is presented as 1 7-bit byte containing the bit 7 flags of the subsequent 7 data bytes.
When all is unpacked, that yields 40 true 8- bytes of actual data.
Many things, like the knobs and numeric values within the reverb, noise gate and effects settings, are simply numbers in the range of 0 to 255, although some may yet reveal their ranges as larger than 255.
Of the other bytes, they contain bit packed information on items that a described by text. E.g. reverb type, timbre, tone stack type, tone stack position, drive circuitry etc. The first example is the 2 bytes immediately following the 16 character name. These bytes are best seen as a 2 byte 16 bit WORD. So far, I only have meaning for the first 14 bits.
Now that I have rebuilt my PC, well almost, I can get on identifying what the remaining bits and bytes are.
Regards
Josie
You aren't the Geoff who worked for Roland UK way back then?
Yes. It was a complete memory failure on my part and it is PR 393.
All the Fender Cyber Twin manuals I have or have ever viewed on line don't contain the formatting of the data itself but only with the data packet is wrapped to be dumped.
The total number of bytes delivered is 68, but includes a SYSEX file start marker and file end marker. The total packet size of the data file is 55 bytes but includes a SYSEX header and SYSEX end of file duo, the checksum and 0xF7.
That leaves 47 bytes of raw real preset dump data.
That data is bit 7 compressed which, after the preset number, is presented as 1 7-bit byte containing the bit 7 flags of the subsequent 7 data bytes.
When all is unpacked, that yields 40 true 8- bytes of actual data.
Many things, like the knobs and numeric values within the reverb, noise gate and effects settings, are simply numbers in the range of 0 to 255, although some may yet reveal their ranges as larger than 255.
Of the other bytes, they contain bit packed information on items that a described by text. E.g. reverb type, timbre, tone stack type, tone stack position, drive circuitry etc. The first example is the 2 bytes immediately following the 16 character name. These bytes are best seen as a 2 byte 16 bit WORD. So far, I only have meaning for the first 14 bits.
Now that I have rebuilt my PC, well almost, I can get on identifying what the remaining bits and bytes are.
Regards
Josie
Hello,
I'm calculating the numbers, and guessing you're about the same age as me. I was messing with midi by the time I was 40, purely hobby (I've never been anything to do with Roland, or anything like).
I've never seen anything that messes with the SYSEX data as you describe. I don't see the point. And I don't see how the manipulation of bits you describe will actually 'compress' the data (as in make it smaller).
Just out of interest, could you send a copy of a dumped file. Interesting to see how it compares with what's detailed in the manual.
Geoff
I'm calculating the numbers, and guessing you're about the same age as me. I was messing with midi by the time I was 40, purely hobby (I've never been anything to do with Roland, or anything like).
I've never seen anything that messes with the SYSEX data as you describe. I don't see the point. And I don't see how the manipulation of bits you describe will actually 'compress' the data (as in make it smaller).
Just out of interest, could you send a copy of a dumped file. Interesting to see how it compares with what's detailed in the manual.
Geoff
0
Undo
Votes
When the internal data is organized as 8-bit bytes, some encoding (not compression) must be used to transport it using 7-bit bytes (as used in the SysEx data section). Moving the most significant bits of 7 bytes into a separate bytes is one common mechanism; another one is to transmit one nibble per SysEx byte.
Hello Geoff,
Using MIDI-OX, this is the data dumped by pressing UTITLIES -> MIDI Dump Preset C00 -> TAP on my Fender Cyber Twin:
All data numbers are hexadecimal!
000438CB 1 -- F0 Buffer: 6 Bytes System Exclusive
SYSX: F0 08 21 11 02 F7
000439A6 1 -- F0 Buffer: 55 Bytes System Exclusive
SYSX: F0 08 21 11 02 00 00 00 00 53 74 61 64 69 75 6D 00 20
SYSX: 52 6F 63 6B 20 20 07 20 20 50 6E 61 6A 54 2F 07 61 6E
SYSX: 6E 03 36 03 00 00 20 7F 00 7F 7F 7F 00 7F 7F 7F 7F 45
SYSX: F7
00043A04 1 -- F0 Buffer: 7 Bytes System Exclusive
SYSX: F0 08 21 11 02 7B F7
The first SYSEX byte stream. of length 6 bytes, signifies the start of a MIDI Dump File
{F0 08 21 11 02 F7}
1. F0: SYSEX start
2. 08: Manufacturer ID. 08 = Fender
3. 21: Device ID: 21 = generic ID covering many Fender MIDI amplifiers
4. 11: Version ID: 11 = Version 1.1 of a Fender Cyber Twin
5. 02: Function ID. 01 = Utilities, 02 = Single preset and 03 = Total dump of all presets (there are 205)
6. F7: SYSEX end
NB All SYSEX data blocks will start the same first 5 bytes
The second SYSEX byte stream, of length 55 bytes is the data itself
1. {F0 08 21 11 02}: the usual start to all SYSEX data blocks
6. 00: The packet number. Always 00 for a single preset and utilities dump and a 7 but counter for each of the single presets within a total preset dump
7 to 53 : Fender Cyber Twin Single Preset Data
54.45: Checksum byte used for error checking*/b]
55. F7: SYSEX end
The third SYSEX byte stream. of length 7 bytes, signifies the end a MIDI Dump File
1. {F0 08 21 11 02}: the usual start to all SYSEX data blocks
6. 7B: End of System Exclusive File Byte
7. F7: SYSEX end
This is all totally consistent with the formats laid out in Appendix 3 of the Fender Cyber Twin Manual.
What the Fender Cyber Twin Manual doesn't tell you are the meanings of the 47 byte group labelled above as: Fender Cyber Twin Sing Preset Data actually are.
* The Checksum byte isn't very clear as to which bytes it is the Checksum of? I have tried many options and none of it is consistent the Checksum given in the data. Maybe I have a faulty MIDI <> USB converter or I have made a trivial mistake?
However, using the data I have and applying the bit 7 reconstruction rule, the true 8 bit byte data becomes
00 00
53 74 61 64 69 75 6D 20 52 6F 63 6B 20 20 20 20
50 6E E1 EA D4 07 E1 6E EE 83 B6 83 00 20 7F 00
7F 7F 7F 7F 7F 7F 7F
The first 2 bytes {00, 00} are the MSB and LSB of the preset number in 7 bit format, i.e. the preset number is MSB * 128 + LSB
C00 to C84 are the numbers 0 to 85
P00 to P84 are the numbers 85 to 169
A00 to A34 are the numbers 170 to 204
I.e. 205 presets in all.
The next 16 bytes:
{53 74 61 64 69 75 6D 20 52 6F 63 6B 20 20 20 20} are the preset name, in this case "Stadium Rock" followed by spaces
The next 2 bytes { 50, 6E } are best treated as a 16 bit WORD 50BE = [0101000001101110] in binary
I have so far managed to interpret these bits as
{ unknown, unknown,
ReverbType bit 4, ReverbType bit 3, ReverbType bit 2, ReverbType bit 1,
Timbre bit 3, Timbre bit 2, Timbre bit 1
ToneStackPosition bit 1,
DriveCircuitry bit 4, DriveCircuitry bit 3, DriveCircuitry bit 2, DriveCircuitry bit 1,
ToneStackType bit 2, ToneStackType bit 1}
Revealing, for this preset:
Preset Number: C00
Preset Name: "Stadium Rock "
Tone Stack Type: British
Tone Stack Position: Post-Distortion
Drive Circuitry: HMB Tube3
Reverb Type: Arena
Timbre: None
The next 7 bytes are, converted to dial readings:
Volume**: 4.3
Gain**: 9.3
Treble: 5.1
Middle: 7.1
Bass: 5.1
Presence: 0.0
Reverb: 1.3
** Volume and Gain don't follow the same order as the panel knobs.
That's as far as I got before my PC died. Busy resurrecting it now
This has given me an interlude to think
Why can't I preview this? Why does text formating only work on my tablet?
Regards Josie
Using MIDI-OX, this is the data dumped by pressing UTITLIES -> MIDI Dump Preset C00 -> TAP on my Fender Cyber Twin:
All data numbers are hexadecimal!
000438CB 1 -- F0 Buffer: 6 Bytes System Exclusive
SYSX: F0 08 21 11 02 F7
000439A6 1 -- F0 Buffer: 55 Bytes System Exclusive
SYSX: F0 08 21 11 02 00 00 00 00 53 74 61 64 69 75 6D 00 20
SYSX: 52 6F 63 6B 20 20 07 20 20 50 6E 61 6A 54 2F 07 61 6E
SYSX: 6E 03 36 03 00 00 20 7F 00 7F 7F 7F 00 7F 7F 7F 7F 45
SYSX: F7
00043A04 1 -- F0 Buffer: 7 Bytes System Exclusive
SYSX: F0 08 21 11 02 7B F7
The first SYSEX byte stream. of length 6 bytes, signifies the start of a MIDI Dump File
{F0 08 21 11 02 F7}
1. F0: SYSEX start
2. 08: Manufacturer ID. 08 = Fender
3. 21: Device ID: 21 = generic ID covering many Fender MIDI amplifiers
4. 11: Version ID: 11 = Version 1.1 of a Fender Cyber Twin
5. 02: Function ID. 01 = Utilities, 02 = Single preset and 03 = Total dump of all presets (there are 205)
6. F7: SYSEX end
NB All SYSEX data blocks will start the same first 5 bytes
The second SYSEX byte stream, of length 55 bytes is the data itself
1. {F0 08 21 11 02}: the usual start to all SYSEX data blocks
6. 00: The packet number. Always 00 for a single preset and utilities dump and a 7 but counter for each of the single presets within a total preset dump
7 to 53 : Fender Cyber Twin Single Preset Data
54.45: Checksum byte used for error checking*/b]
55. F7: SYSEX end
The third SYSEX byte stream. of length 7 bytes, signifies the end a MIDI Dump File
1. {F0 08 21 11 02}: the usual start to all SYSEX data blocks
6. 7B: End of System Exclusive File Byte
7. F7: SYSEX end
This is all totally consistent with the formats laid out in Appendix 3 of the Fender Cyber Twin Manual.
What the Fender Cyber Twin Manual doesn't tell you are the meanings of the 47 byte group labelled above as: Fender Cyber Twin Sing Preset Data actually are.
* The Checksum byte isn't very clear as to which bytes it is the Checksum of? I have tried many options and none of it is consistent the Checksum given in the data. Maybe I have a faulty MIDI <> USB converter or I have made a trivial mistake?
However, using the data I have and applying the bit 7 reconstruction rule, the true 8 bit byte data becomes
00 00
53 74 61 64 69 75 6D 20 52 6F 63 6B 20 20 20 20
50 6E E1 EA D4 07 E1 6E EE 83 B6 83 00 20 7F 00
7F 7F 7F 7F 7F 7F 7F
The first 2 bytes {00, 00} are the MSB and LSB of the preset number in 7 bit format, i.e. the preset number is MSB * 128 + LSB
C00 to C84 are the numbers 0 to 85
P00 to P84 are the numbers 85 to 169
A00 to A34 are the numbers 170 to 204
I.e. 205 presets in all.
The next 16 bytes:
{53 74 61 64 69 75 6D 20 52 6F 63 6B 20 20 20 20} are the preset name, in this case "Stadium Rock" followed by spaces
The next 2 bytes { 50, 6E } are best treated as a 16 bit WORD 50BE = [0101000001101110] in binary
I have so far managed to interpret these bits as
{ unknown, unknown,
ReverbType bit 4, ReverbType bit 3, ReverbType bit 2, ReverbType bit 1,
Timbre bit 3, Timbre bit 2, Timbre bit 1
ToneStackPosition bit 1,
DriveCircuitry bit 4, DriveCircuitry bit 3, DriveCircuitry bit 2, DriveCircuitry bit 1,
ToneStackType bit 2, ToneStackType bit 1}
Revealing, for this preset:
Preset Number: C00
Preset Name: "Stadium Rock "
Tone Stack Type: British
Tone Stack Position: Post-Distortion
Drive Circuitry: HMB Tube3
Reverb Type: Arena
Timbre: None
The next 7 bytes are, converted to dial readings:
Volume**: 4.3
Gain**: 9.3
Treble: 5.1
Middle: 7.1
Bass: 5.1
Presence: 0.0
Reverb: 1.3
** Volume and Gain don't follow the same order as the panel knobs.
That's as far as I got before my PC died. Busy resurrecting it now
This has given me an interlude to think
Why can't I preview this? Why does text formating only work on my tablet?
Regards Josie
Thank you Geoff,
There were some typos in the tech description I gave and I have corrected them. Just spelling and missing words. No technical details involved as far as I can see and hope.
Unfortunately, I have sinusitis, cattarrh and a chest infection. My head feels like it is full of cotton wool leaving me a bit befuddled and well below my best. Or is it old age? Haha.
Could I post my detailed technical writings as a zipped PDF file? I don't like the text formatter on here and it doesn't seem to work on my PC.
Regards
Josie.
There were some typos in the tech description I gave and I have corrected them. Just spelling and missing words. No technical details involved as far as I can see and hope.
Unfortunately, I have sinusitis, cattarrh and a chest infection. My head feels like it is full of cotton wool leaving me a bit befuddled and well below my best. Or is it old age? Haha.
Could I post my detailed technical writings as a zipped PDF file? I don't like the text formatter on here and it doesn't seem to work on my PC.
Regards
Josie.
Hello Josie,
I can do something with a zipped .PDF, no problem.
The main thing is to print it out so that I can refer to it alongside other docs. The format doesn't matter THAT much.
Not sure what you mean by 'the text formatter on here'. There's just the editor which is a fairly simple affair, so yes, it messes up columns etc due to character widths. I never have that problem with the DOS text editors I prefer to use!
I was looking further through your data, and the appendices, and I noted one interesting thing. Appendix 2 details the various things set via Control Changes, i.e. normal midi, NOT SYSEX, However, the 'Parameter ID and Value' table seems to include some of the same values? Why the duplication? I'd assume that the values being set via CC are the ones that might need to be changed most during a performance - not that I know THAT much about using amps!!
I hope your ailments ARE ailments. They've not yet found a cure for old age! Well, just the age old cure, 100% effective, 0% useful.
Best wishes,
Geoff
I can do something with a zipped .PDF, no problem.
The main thing is to print it out so that I can refer to it alongside other docs. The format doesn't matter THAT much.
Not sure what you mean by 'the text formatter on here'. There's just the editor which is a fairly simple affair, so yes, it messes up columns etc due to character widths. I never have that problem with the DOS text editors I prefer to use!
I was looking further through your data, and the appendices, and I noted one interesting thing. Appendix 2 details the various things set via Control Changes, i.e. normal midi, NOT SYSEX, However, the 'Parameter ID and Value' table seems to include some of the same values? Why the duplication? I'd assume that the values being set via CC are the ones that might need to be changed most during a performance - not that I know THAT much about using amps!!
I hope your ailments ARE ailments. They've not yet found a cure for old age! Well, just the age old cure, 100% effective, 0% useful.
Best wishes,
Geoff
Hello Clemens.
Thank you. I understand all that you said. This data is definitely 7-bit deconstructed data EXCEPT for the first 2 bytes, which is the Preset Number expressed in the standard MSB LSB 7-bit format.
I have reconstructed the 8-bit data and my problem is to decipher it. I have made a start and the results are CTformat.pdf which is wrapped in the CTformat.zip that I attached in my previous response.
I am intrigued by the the checksum byte!
I have a small VB program that allows me to select any range of the raw data dump bytes and calculate the checksum based on addition "+".
No matter what range I take, I can't find a range that yields a checksum in any way related to the checksum provided in the raw data eith by equality of total sum = 00!
Nomally, the total 7-bit sum of the dump data, including the checksum byte, should add to 7-bit zero.
regards
Josie
Thank you. I understand all that you said. This data is definitely 7-bit deconstructed data EXCEPT for the first 2 bytes, which is the Preset Number expressed in the standard MSB LSB 7-bit format.
I have reconstructed the 8-bit data and my problem is to decipher it. I have made a start and the results are CTformat.pdf which is wrapped in the CTformat.zip that I attached in my previous response.
I am intrigued by the the checksum byte!
I have a small VB program that allows me to select any range of the raw data dump bytes and calculate the checksum based on addition "+".
No matter what range I take, I can't find a range that yields a checksum in any way related to the checksum provided in the raw data eith by equality of total sum = 00!
Nomally, the total 7-bit sum of the dump data, including the checksum byte, should add to 7-bit zero.
regards
Josie
Hello Clemens,
This is a screen dump of my VB Data Dump Analyser
Left Panel: Raw data from MIDI-OX for preset A00 Champ '49
Centre panel: Checksum analysis on selected data range in the left panel
Right Panel: Interpretation of ALL data in the left panel. Ignore Checksum
regards
Josie
This is a screen dump of my VB Data Dump Analyser
Left Panel: Raw data from MIDI-OX for preset A00 Champ '49
Centre panel: Checksum analysis on selected data range in the left panel
Right Panel: Interpretation of ALL data in the left panel. Ignore Checksum
regards
Josie
Hello Josie,
Have you ever seen a program called 'Cyber Commander', written I understand by Johnny Stecchino - this system may well answer a lot of your queries, IF you can find a copy of it.
But, it seems to have vanished, and the writer (and the company behind it ?) seems to have vanished. There is some speculation on the web as to why. However, the program allowed one to dump, edit, store and load data for the CT, and I'd guess that the instructions gave a lot of useful information, plus study of the stored data in conjunction with the screen processes within the software would have shed a lot of light on the data and the components.
There are people on the web who have the program, and use it. There is speculation that the software may now be 'abandonware', and may be downloadable, although there is also reference to a 'key' being required.
Oh, beware. 'Johnny Stecchino' seems also to be the name of a movie, which appears to be totally NOT related in any way to any Fender product!!
Somewhere, I have the code for a program that generates a SYSEX package from the actual data. I believe (as I remember it) that this program generated the CHK, I used this program, and it was working fine, although I think it related to Roland (specifically for the MT32, or in my case the MT32 on a card LAPC-I). I'll try and find this. Or are you suggesting that the Fender device does NOT follow the usual rule/method for generating the CHK?
Geoff
Have you ever seen a program called 'Cyber Commander', written I understand by Johnny Stecchino - this system may well answer a lot of your queries, IF you can find a copy of it.
But, it seems to have vanished, and the writer (and the company behind it ?) seems to have vanished. There is some speculation on the web as to why. However, the program allowed one to dump, edit, store and load data for the CT, and I'd guess that the instructions gave a lot of useful information, plus study of the stored data in conjunction with the screen processes within the software would have shed a lot of light on the data and the components.
There are people on the web who have the program, and use it. There is speculation that the software may now be 'abandonware', and may be downloadable, although there is also reference to a 'key' being required.
Oh, beware. 'Johnny Stecchino' seems also to be the name of a movie, which appears to be totally NOT related in any way to any Fender product!!
Somewhere, I have the code for a program that generates a SYSEX package from the actual data. I believe (as I remember it) that this program generated the CHK, I used this program, and it was working fine, although I think it related to Roland (specifically for the MT32, or in my case the MT32 on a card LAPC-I). I'll try and find this. Or are you suggesting that the Fender device does NOT follow the usual rule/method for generating the CHK?
Geoff
Hello Geoff,
I have heard of Commander but it seems a bit mythological because it is nowhere to be found. I use a thing called Cyber2Editor. It is Japanese but can still be downloaded if you sort of squint at the Japanese text. Lol.
I am suspect of CHK simply because I can't find anything to sum that is correlated with its value!
The interpretation of the SYSEX was just, initially, to get the names of the PRESETS. However, if I am to build a foot controller and Cyber Twin end box to control the Cyber Twin, if thought it would be good to know what the amp settings were before I changed them.
However, they do not matter in the initial stages of my project, which I will describe in my next postings.
Regards
Josie
I have heard of Commander but it seems a bit mythological because it is nowhere to be found. I use a thing called Cyber2Editor. It is Japanese but can still be downloaded if you sort of squint at the Japanese text. Lol.
I am suspect of CHK simply because I can't find anything to sum that is correlated with its value!
The interpretation of the SYSEX was just, initially, to get the names of the PRESETS. However, if I am to build a foot controller and Cyber Twin end box to control the Cyber Twin, if thought it would be good to know what the amp settings were before I changed them.
However, they do not matter in the initial stages of my project, which I will describe in my next postings.
Regards
Josie
Project Definition #1
Why? Because I have neurological problems in my feet, i need a stage area free of cables. Also, the floorboard switch controller must have a small vertical height and must be laid out very simply. Standard floorboards just have too many switches in too many rows for me to able to use them without falling over!
So the system will consist of an Android eye level high visible screen connected by Bluetooth to a 9 switch, with a footpedal floorboard, with and a second Bluetooth unit at the Cyber Twin end to control the Cyber Twin and up to 2 modified guitar stomp boxes, in my case a BOSS compressor and an Ibanez TS9 Tube Screamer. The floorboard and the rig end box will be equipped with Arduino microboards and Bluetooth boards.
The floor board will look like this, with or without the detailed information contained in the 8 digit 7 segment display.
Why? Because I have neurological problems in my feet, i need a stage area free of cables. Also, the floorboard switch controller must have a small vertical height and must be laid out very simply. Standard floorboards just have too many switches in too many rows for me to able to use them without falling over!
So the system will consist of an Android eye level high visible screen connected by Bluetooth to a 9 switch, with a footpedal floorboard, with and a second Bluetooth unit at the Cyber Twin end to control the Cyber Twin and up to 2 modified guitar stomp boxes, in my case a BOSS compressor and an Ibanez TS9 Tube Screamer. The floorboard and the rig end box will be equipped with Arduino microboards and Bluetooth boards.
The floor board will look like this, with or without the detailed information contained in the 8 digit 7 segment display.
Project Definition #2
The Android tablet will communicate with floor board and attach a meaning to the switches. I will maintain a list of such meanings. I see these are being linked to whichever particular track is to be played.
The Android tablet will then issue commands to the rig end box depending on what switch is pressed and which set of switch settings are currently selected on the Arduino. So the Cyber Twin and the 2 stomp boxes will respond accordingly.
There is no reason that the Android could not also act as Cyber Twin preset editor and SYSEX DUMP file manager. However, that requires that I correctly understand the data of a single preset MIDI DUMP file. The notorious 55 bytes.
The Android tablet will communicate with floor board and attach a meaning to the switches. I will maintain a list of such meanings. I see these are being linked to whichever particular track is to be played.
The Android tablet will then issue commands to the rig end box depending on what switch is pressed and which set of switch settings are currently selected on the Arduino. So the Cyber Twin and the 2 stomp boxes will respond accordingly.
There is no reason that the Android could not also act as Cyber Twin preset editor and SYSEX DUMP file manager. However, that requires that I correctly understand the data of a single preset MIDI DUMP file. The notorious 55 bytes.
0
Undo
Votes
Nomally, the total 7-bit sum of the dump data, including the checksum byte, should add to 7-bit zero.
That's what the GS and XG standards use, but the MIDI Tuning standard uses XOR instead of addition.
Anyway, for both messages (in the screenshot and in the PDF), if I ignore the checksum byte completely, the other bytes add up to 0x7F.
Why did you say 'ignore the checksum byte completely'?
I meant it in 2 ways
1. The checksum calculation in the right hand pane is just incorrect
2. Just assume all is OK and carry on with my interpration
However:
Many thanks Clemens and Geoff
Xor and not arithmetic summation was the key. I should have known better. I am shamed and humbled.
I have found that the checksum operation must be performed over ALL the inner 53 bytes of the 55 byte data "file". i.e. excluding 0xF0 at start and 0xF7 at the end.
This consistent with this pdf about instructions for the Fender G-DEC (see pages 22 et seq)
G-DEC MIDI Guide
In it the author says:
"Checksum byte - The checksum is the sum of all of the bytes from the Fender ID(08) to just before this byte which is then masked by 0x7F"
Not quite how I would have expressed and just a tiny bit wrong.
However, I am now clear tp proceed with the interpretation with the assurance of the checksum showing me that MIDI <> USB converter is OK. I have a box full of ones which aren't!
Thank you guys
Regards
Josie
I meant it in 2 ways
1. The checksum calculation in the right hand pane is just incorrect
2. Just assume all is OK and carry on with my interpration
However:
Many thanks Clemens and Geoff
Xor and not arithmetic summation was the key. I should have known better. I am shamed and humbled.
I have found that the checksum operation must be performed over ALL the inner 53 bytes of the 55 byte data "file". i.e. excluding 0xF0 at start and 0xF7 at the end.
This consistent with this pdf about instructions for the Fender G-DEC (see pages 22 et seq)
G-DEC MIDI Guide
In it the author says:
"Checksum byte - The checksum is the sum of all of the bytes from the Fender ID(08) to just before this byte which is then masked by 0x7F"
Not quite how I would have expressed and just a tiny bit wrong.
However, I am now clear tp proceed with the interpretation with the assurance of the checksum showing me that MIDI <> USB converter is OK. I have a box full of ones which aren't!
Thank you guys
Regards
Josie
- Page :
- 1
- 2
There are no replies made for this post yet.