Roland VM-C7200 preset

[BJ Baylon]

Many years ago, I founded a Roland VM-C7200 Mixer Controller without the processor unit at a very good price. I did a preset in the Cakewalk Generic Surface plugin that can control up to 48 tracks in Sonar with 4 sends and 16 ACT controllers. Obviously it had no feedback for the motorized faders.

 I am very interested in developing a preset for it in AZSlow. The VM-C7200 uses SYS Ex strings for all the parameters. The faders have 1024 steps of resolution. By trial and error I have found that this data is coded in 2 bytes MSB LSB after 7 bytes of adrressing data. I have correctly identified the 7 static bytes in the configuration page and have seen just the 2 data bytes changing inside the parenthesis in the hardware tab. But when I asigned the value to the fader configuration nothing happens. I made the same thing with a mute switch and it worked flaulessly, so I think that maybe is the data format. I don´t have the mixer at this moment but I can post the exact messages tomorrow.

[azslow3]

2 bytes values parsing from/to SysEx is currently not implemented in AZ Controller. There was no such need so far.
Can you check there will be no surprised with that? I mean with the format.
Effectively 2 things to check:
a) which exact values these 2 bytes have when the fader is in upper position?
b) when you move the fader, are there some numbers in the second (LSB) byte with lower 4 bits set?
I mean 2 bytes represent 7+7=14bit value, with 10bit precision (so 1024 steps) upper 10 bits are normally filled but lower 4 bits not. That was so far true for controllers I had to deal with, but please check before I start coding.

I can implement the change fast (that is less then an hour of coding). But you can just use upper (first) byte and that should work, with a bit lower resolution then possible.
If you have not found how to do this in AZController, let be know exact SysEx for one Fader and I will make an example (with feedback).

Note: SysEx Key length in the Options tab should be set correctly at the time of assignment (at other time that is not relevant, so you can have different key length for different controls). Otherwise there can be 2 effects, a separate control can be interpreted as some other control with variable parameter or some part of variable parameter can be interpreted as a part of the key.

PS so far the biggest challenge was supporting old Yamaha digital mixer, in different mixer hardware layouts (EQ, Comp, etc) it is sending different messages from faders. The device is lucking other "mode" buttons, so we had to adopt to use these switches.

[BJ Baylon]

Hi 

  Thanks for all the information and for the quick response. I have found the Midi Implementation Document for the VM-C7200. It apears that the faders resolution is 128 steps only, but the message includes a checksum after the data bytes and before the End of Exclusive flag. The message format is as follows:

Data Set (Dt1)

Status          Data byte                                                                              Status
F0H             41H, Dev, 00H, IEH, 12H, aaH, bbH, ccH, ddH, ..., eeH, Sum     F7H

Byte             Description
F0H              Status of System Exclusive Message
41H              Manufacturer ID (Roland)
Dev              Device ID
00H 1EH       Model ID (V-Mixer)
12H              Command ID (Dt1)
aaH              Address MSB
bbH              Address MID
ccH              Address LSB
ddH              Data
  :                   :
eeH              Data
Sum             Checksum
F7H              End of Exclusive

  There is a Parameter Address Block that list the starting address for the main blocks. There are sub-blocks that contain the offset address for each parameter from the starting address of the main block.
 
  For the channel 1 level fader it goes something like this:


Block:                                                 Start Address:                    Offset Address:           Data:
VM-7x00 Unit 1 Mixer Block                  00   10   00

       Input parameters -1 (ch1)                                                      00   00   30
       Input parameters -2 (ch2)                                                      00   01   20
         :                                                                                                 :
       Input parameters -24 (ch24)                                                  00   14   40

                   Input Mute Switch                                                      00   00   23                00 - 01 
                   Input Master Fader Level                                            00   00   24                00 - 7F
                   Input Main Send Pan                                                  00   00   26                00 - 7F

  On Roland system exclusive message (Dt1), a checksum is added at the end of transmitted data (in front of F7H) to check the message is received correctly. Value of checksum is defined by addres and data (or size) of the system exclusive message to be transmitted.

                          How to calculate checksum (Hexadecimal number is shown with H.)
  Checksum is a value which lower 7 bit of the sum of address, size and checksum itself turns to be 0. For example, if the address of the system exclusive message to be transmitted is aa bb ccH and data or size is dd ee ffH:

                                                 aa + bb + cc + dd + ee +ff  = sum
                                                 sum / 128 = quotient and odd
                                                 When odd is 0, 0 = Checksum
                                                 When odd is other than 0, 128 - odd = Checksum

  I don´t have Access to the mixer at this time, but let me check tomorrow for some real messages transmited to verify. I think that the checksum will be important in order to have propper feedback. Thanks!!!

[azslow3]

I have implemented 14bit values in SysEx (available in the latest test version)... but that is not required now 

Can you send me the link to the documentation? If you do not want to put it in public, please send me it in PM.

I will also need several correct packet examples, as received from the unit. To test check sum generator.

[BJ Baylon]

Hi 

I have just send you by PM the link for downloading the VM-C7200 manual. Here are some examples of messages received from the console:

Channel 1 Master Level Fader

SysEx<41>11 0 1e 12 0 10 54 [ 0 1c ]
                                             [ 1 1b ]
                                             [ 2 1a ]
                                             [ 3 19 ]
                                             [ 4 18 ]
                                             [ 5 17 ]
                                                 :
                                             [ 1c 0 ]
                                             [ 1d 7f ]
                                             [ 1e 7e ]
                                             [ 1f 7d ]
                                             [ 20 7c ]
                                                 :
                                             [ 7e 1e ]
                                             [ 7f 1d ]

Channel 2 Master Fader Level

SysEx<41>11 0 1e 12 0 11 44 [ 0 2b ]
                                              [ 1 2a ]
                                                  :
                                              [ 2b 0 ]
                                              [ 2c 7f ]

Channel 3 Master Fader Level

SysEx<41>11 0 1e 12 0 12 34 [ 0 3a ]
                                              [ 1 39 ]
                                                   :
                                              [ 3a 0 ]
                                              [ 3b 7f ]

Channel 1 Main Send Pan

SysEx<41>11 0 1e 12 0 10 56 [ 0 1a ]
                                              [ 1 19 ]
                                                  :
                                              [ 1a 0 ]
                                              [ 1b 7f]

[azslow3]

Thanks, I will try to implement the checksum tomorrow.
I guess it make no sense to try the feedback without. I attach a test preset, still uni-directional and for 3 faders only, far from what it should be even in this case (will explain once we get to the feedback), but you can see how that is going to work. Please install b379 (test build) of AZ Controller.
Some details:
Inject control is just the placeholder to send some test SysExes back to AZ Controller ("loop" flag). It is not used for normal operations.

Init. Set WAI to 3 tracks, on preset loading time

Fader X. React on incoming message from the fader, parse the value (fail if for some reason it can not). Then select required parameter (WAI track + X, Volume) and set it (from extracted value).

[azslow3]

In case previous test was successful (and only in that case, also you should understand what it is doing, all future things are way more complicated...),
there is b380 in the download section, with checksum calculator support. I attach the first attempt to move faders from Sonar side.

This time the example preset is closer to what it should be:
* there are 3 "functions" defined, to be called from particular fader processing. That way it is easy to change the logic of all faders since it is in one place. One function is to select parameter the fader is going to control, the second is to set it from received fader value, the third is what to do in so called "value monitoring" (that is complicated topic, as any feedback).
* to distinguish the fader, "_Ch" is defined (options tab). Each fader set it explicitly at the beginning, so all future functions (and monitors) know it
* value monitors are checking that selected parameter (in the example track volume) are changed or not. That can be the result of adding/moving tracks, switching projects, moving WAI. I mean it covers all cases, not just explicit moving corresponding fader by mouse.
* when you move the fader by finger, you do not want the device "fight" with you. So, when you change Sonar parameter with the fader you do not want Sonar update the fader. But you want Sonar update the fader in all other situations. For that, I have defined "FaderMoved(_Ch)" (channel dependent). When the fader is moved, it is set and also corresponding timer is armed for ~2sec. So when the fader is not moved for 2 sec, the timer reset the flag and reset value monitor, which in turn re-send actual Sonar value to the device.
That "trick" is only required for not touch sensitive motor faders. Touch sensitive faders know when they are touched and devices handle that. All other control types do not "fight" with fingers.

But there is potentially big problem with the feedback for C7200. In the documentation, they mention that SysExes should not be sent continuously,  the device needs 20ms in between. You can test how good 3 faders are working, with 24 it can be only worse. One possibility is try to adjust relevant parameters in Sonar ini file: https://www.cakewalk.com/Documentation?product=SONAR&help=INI_Files.5.html (SysxSendDelayMsecs) But I worry the setting influence SysEx banks only, not something transfered from Control Surface plug-ins. CS plug-ins are called once per 75ms, so "too slow" to send  one SysEx every cycle. We have to find some solution in case you hit that problem.

[BJ Baylon]

Hi 

 I downloaded the test versión 0 and it worked excellent. I did some editions adding more controllers (pan) and there were no problems. Unfortunatelly my network connection failed just before I sended the post back. I´ll try the new preset at incremental steps and see what happens. Thanks again!

[BJ Baylon]

Hi 

  I am testing the new preset v1, it´s doing everything it´s supossed to do, great! The mixer is responding to changes in Sonar and the faders trasmit levels too.

  There is a feedback situation related in how the mixer respond to incoming Midi. I have noticed that before in my early (and not very successfull!) attemps of automation. It seems that every time the mixer receives a message (Fader level actualization or something else) it  inmediatelly retransmits that message. Even if the fader isn´t moved there are messages back and forth so, in some instances, there is fighting with the fader .
 
  I deactivated and reactivated Midi input and when I move and release fader 1, there are messages for just that fader. If I move fader 2 later then the messages alternate between fader 1 and fader 2. Same when I add fader 3. I have tried that in different order to see if maybe its a problem with a particular fader, but its the same in all cases. Same if I do all the changes from Sonar. If I deactivate and reactivate Midi input then the flow stops until I move a fader again (I can verify that in the input and output meters on my Motu Microlite Interfase)

  I am thinking that maybe adding a logical subroutine that compares the incoming message with the actualization message and ignore the former if they are the same could help. Or maybe there´s another form. Thanks again and grettings!
 
   

[azslow3]

  I am thinking that maybe adding a logical subroutine that compares the incoming message with the actualization message and ignore the former if they are the same could help. Or maybe there´s another form. Thanks again and grettings!

Lets try that... I have uploaded v2 in my previous post (to not leave old not working presets, I normally edit one existing attachment).

[BJ Baylon]

  Preset V2 installed, traffic problem solved! In some minor instances I get some small fighting with the fader but is minimall. I think that in some positions the fader still transmit the same value before changing to new numbers, but the effect is negligible.

  I am in the process of expanding to 8 channels. I understand almost all the logic involved. My dude in in the "Inject" section in Logic. Is this the section that calculates the checksum for the outgoing messages? It shows the following 3 definitions for the faders:

Fader 1  41 11 00 1e 12 00 10 54 40
Fader 2  41 11 00 1e 12 00 11 44 40
Fader 3  41 11 00 1e 12 00 12 34 00

  I have 2 questions: How do I set for the next faders and why fader 1 and fader 2 definitions end in 40 and fader 3 in 00 (I would espect them to be different all 3 or be the same, but that´s beyond my understanding right now)

[azslow3]

"Inject" has nothing to do with the preset (I have explained that for my first test preset...) 

To extend:
1) go to the Options tab, select "Fader 3" and press "Dup" several times. That will create "Fader 4", "Fader 5", etc.
2) in the Logic tab, visit each new fader and change "Set Ch -> X" to correct number. Also change "Reset monitor" to correct one
3) in the _fFaderMon, select "Ch:3 SysEx append: xxxx ", press "Copy" and "Paste" required number of times. Change "Ch:3" condition to correct one and edit numbers
4) in the Feedback Tab, edit new "Timer"s, select correct monitors to reset (btw. you can try to remove one reset, "small fighting" should disappear, but fader without strip in Sonar will no longer return to zero position after manually moving it on device)
5) in the Hardware Tab, MIDI learn new faders (move real fader, select corresponding control, Assign MIDI).
May be I forgot something... I can extend for you in case you find all that boring.

[BJ Baylon]

I had realized my error just minutes after the post, sorry !

8 track mode Ok! going to 24

[BJ Baylon]

24 track mode Ok! Awesome  !
 
  I had to add more states, but finded the way to do it. The faders can track very well. Sometimes when changing WAI positions fast, they transmit values before reaching their final state. This can modify the mix so a timer could be considered for blocking the inputs during WAI changes. Here is the 24 track preset, so far 

[azslow3]

Good!
But I have uploaded v202, where I try to solve mentioned by your problems:
1) value transmission during moving. I have "three stated" faders, changing "FaderMove(_Ch)" to "FaderOp(_Ch)", with "Idle", "Finger" and "Sonar". I have left "Finger" transition time 2 sec and added "Sonar" transition time 1 sec. If 1 second is still low, adjust it in (all) Value Monitors.
2) "micro fights". I am now tracking last sent from fader values in "FaderVal(_Ch)" and re-trigger after "Finger" transition only in case of values mismatch. On one side, in case fader fingered position is not possible for parameter (f.e. track does not exist), update will be triggered (there will be value mismatch). But when everything is "normal", the value is not sent.

Note that with each modification, the preset is more and more complex. Since I can not really test, there can be some bugs.