AZSlow
AZ Controller plug-in for Cakewalk SONAR => Discussions => Topic started by: BJ Baylon on November 15, 2017, 07:29:56 AM
-
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.
-
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.
-
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!!!
-
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.
-
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]
-
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).
-
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.
-
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!
-
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!
-
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).
-
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)
-
"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.
-
I had realized my error just minutes after the post, sorry ::)!
8 track mode Ok! going to 24
-
24 track mode Ok! Awesome :D!
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
-
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.
-
Hi :)
Preset V202 installed. The initial tests didn´t show any problems. The updates are smooth and there aren´t unexpected changes in Sonar conditions during fast WAI changes. I Have not detected fader fighting yet. I will do many tests of normal use during this weekend to check for stability issues before adding new features. Thanks again and have a nice weekend!!!
-
just posting to say thanks to AZ,he spends much time helping others get their unsupported gear working :)
AZ you are a star! :)
-
Hi :)
Preset V202 installed. The initial tests didn´t show any problems. The updates are smooth and there aren´t unexpected changes in Sonar conditions during fast WAI changes. I Have not detected fader fighting yet. I will do many tests of normal use during this weekend to check for stability issues before adding new features. Thanks again and have a nice weekend!!!
I recommend to create a test project, with the first track volume all the way up, the second all the way down, the third up and so on. When you move WAI by one track, you will immediately see in case something has moved in Sonar and/or not moved on Roland.
just posting to say thanks to AZ,he spends much time helping others get their unsupported gear working :)
When something is obsolete, the community is the only way to keep it alive ;)
-
Hi again :)
After many tests (I used the alternating patern extensively) it seems that the V201 24 channel configurastion is stable. I did an alternate preset with 24 more channels assigned to the Ch Pan function state on the console. That was more that the console´s available bandwidth could handle. During a WAI change only channels 1 - 5 refreshed Volume data, and channels 4 - 24 actualized Pan. Individually every channel worked ok, both ways.
I Made this preset just for testing how far we can go. A more practical development would be to add buttons to the 24 ch versión and do tests on how it will affect available headroom. Because all the logic involved, i want to ask if you could give me instruccions for adding the button Mute to ch 1? The address bytes are 00 10 53 [00 1d] off [01 1c] on.
p.s. I can´t remember how many times I had read in posts saying that there was no way that the Roland VM-C7200 could be used to control Sonar because it wasn´t designed to do it. Thanks for everything!!!
-
At this stage I want to mention some ideas and consequences about using VMC as a Control Surface. It is the same for all Digital Mixers.
"Native" Control Surfaces are just physical controls which send a signal to the DAW when operated and sometime provide feedback (lit LEDs, move faders, show something on display). Important is that each control send exactly one signal. There is no "hardware modes" for controls, all "different layers" are programmed in software.
Digital Mixers (in native mode, some have "DAW controlling" mode where they behave as Control Surfaces) see things from another perspective. Hardware controls are not sending signals to outside, they somehow operated Mixer internal parameters. And these mixer parameters are exposed to the outside world. While that sounds almost the same as with Control Surfaces, the result is significantly different:
1) when controls are switched to another layer, they start to modify another set of parameters. The control is still the same, but the signal from it from the DAW perspective is different.
2) when DAW is changing some parameter, the mixer "broadcast" the change. Not only to the controls (if it happened they control these parameters in current layout), but also back to the DAW. This you have already observed and we had to implement a workaround.
Brute force approach can be as simple as mapping existing Mixer parameters with DAW parameters and keep them in sync. In that case it does not matter which parameters are currently exposed to hardware controls. Unfortunately, that does not work well, at least with Sonar:
a) to load all settings, mixers use some special bulk mode. In assumption that does not happened often, no problem it takes quite some time, the whole information is transfered every time. That does not match DAW controller schema: when you change WAI, select different plug-in, etc. you do want update a big part of the configuration. But not the whole configuration, as for example at the project loading. That can delay reaction on WAI movement, to transfer the whole set of parameters, even when physical controls at the moment are in different layout.
b) monitoring a huge number of parameters does not come for free inside Sonar. Surface plug-in (AZ Controller) pools 13 times per second for each such parameter.
And so general approach is try to LIMIT which parameters are monitored and synced with the mixer to the set of parameters currently assigned to the hardware controls. F.e. when faders control Volume, monitor and sync volume. When they control send volume, monitor and sync send volume (but no longer monitor/sync track volume!). There are 2 approaches to achieve that, the availability depends from the mixer and so you will have to decide:
1) Much simpler to program. Let hardware controls control always the same mixer parameters. F.e. let faders always bound to the (Mixer!) channel volumes. To still allow control something else in Sonar (send volumes, plug-in parameters, etc.), the software need ANY signal to switch the mode. So any button which does not switch what faders are controlling, but modify some (mixer) parameter and so inform the DAW it is pressed. F.e. HPF enable on channel 14... Really the parameter inside Mixer make absolutely no sense for the DAW. Unfortunately, that is not aways possible. F.e. there is no such buttons and/or selecting particular channel also select it inside the mixer, and so some knobs control different parameters (like in Yamaha mixer I have configured before). So the option number:
2) Much tricky then the first one... If Mixer report about control layout switch (Yamaha does), the DAW can detect hardware controls are going to send/react on different messages and adopt.
You have experience with your device, I think you can find what is possible in your case much faster then me (reading I must admit rather bad written documentation).
----------------
I will try to find some time tomorrow (I am not at home these weeks) to write an example with mute. But we will hit the same problem as with pan if I do that strait (simple). You can notice that volume and mute (and other parameters) for the same channel have similarities... I will have to compose the feedback for faders, mute, pan (?), etc. into one SysEx.
BTW. Are all "channel buttons" on the device have LEDs? I mean do we need the feedback for all of them? Also since you already know the answer: how you control pan? I do not see any per strip encoders on picture (I know that I can look into documentation... but)
-
Hi :)
From your last post:
"2) Much tricky then the first one... If Mixer report about control layout switch (Yamaha does), the DAW can detect hardware controls are going to send/react on different messages and adopt."
I did a check on this and no, the mixer didn´t transmit any messages when you change layout. So I think option 1 it´s more adecuate at this time.
"BTW. Are all "channel buttons" on the device have LEDs? I mean do we need the feedback for all of them? Also since you already know the answer: how you control pan? I do not see any per strip encoders on picture (I know that I can look into documentation... but)"
Each channel has 1 status Switch/Led combination. There are 4 Main Mode Select switches : Mute, Solo, Audio and Auto-mix. If you select Mute, for example, when you press the status Switch on a channel the Led turns Red (with Mute On). With the Solo function the color is Yellow and with Audio function the color is Green (each with it´s respective message transmited). Auto-mix have 2 colors : Green at first press, and Red the second (so it could be useful as an automation Read or Write or nothing selector). If could be usefull to have this functions asigned for each channel, but only if they not interfere with the faders bandwidth. Otherwise, we could use some of them to switch modes.
I choosed Ch Pan because it´s somewhat paired with Ch Level on the VM-C7200. It´s the same screen for both. For example, when you select Ch Level, you could use the 6 rotary encoders under the screen to change Pan in 6 channels groups. The same for Ch levels if you select Ch Pan.
-
Ok, I will check tomorrow what is in the same block with faders. I guess the mixer should be able to process traffic as long as the number of messages is the same.
The feedback needs timeouts in transmission otherwise, that will require quite some addition in AZ Controller MIDI processing engine. Till Sonar settings I have mentioned before also affect Surface manages. Using your Fader + Pan version, which does not update everything right, can you try to modify parameters in the INI file to see either that works ?
-
I am still in "strategic planing". Can you send me exact messages, let say fro Ch 1, for:
* pan
* solo
* "audio" mode button
* "auto-mix" mode button (in both its modes)
It seems like it will be impossible to aggregate all of them in one sysex and I will need to implement own "quantization on sending" in case INI trick is not working...
-
Hi :)
I did try the INI modifications (SysxDelayAfterF7=1, SysxSendDelayMsecs=80 and later with 120) but they seem to have no noticeable effect. Here are the values for Ch 1:
Input Ch 1 Mute Switch
<41> 11 00 1e 12 00 10 53 [00 1d] off [01 1c] on
Input Ch1 Solo Switch
<41> 11 00 1e 12 00 48 62 [00 56] off [01 55] on
Input Ch1 Audio Switch
<41> 11 00 1e 12 00 10 55 [00 1b] off [01 1a] 0n
Input Ch1 Auto-mix Switch do not transmit data (sad! it could have been a good controller!)
I am taking time to recheck the manual for posible layouts and doing some "normal work" (if there is something like "normal work"?).
Thanks for all your time and attentions!!!
-
Have you seen the sad news about Cakewalk? So, the end of Sonar...
-
I didn´t now, it´s very sad! :-X
-
Well.. I am really PO by this news... My project is almost "obsolete" now, and not by me.
But lets try to support obsolete device in obsolete DAW by obsolete plug-in :)
From the messages and the documentation, it is clear I need 2 build-in things in AZ Controller:
1) quantization/delay for SysEx (up to 20ms, specified in the documentation)
2) build-in MIDI echo cancellation (what we do now in the preset)
Can take some time.
-
Thanks AZ!
-
Could it be that the problem is not in the time between messages but in the number of messages transmitted over a certain period of time(Midi buffer overflow)?
Let me do some tests in bacward order (from 48ch to 47ch ... etc) before starting the coding
-
I am almost sure that is the "buffer overflow", on the device side.
I am going to implement configurable delay, so "Wait at least X ms after sending Y SysEx packets". Then you can test what works better, 1x20ms, 24x100ms, etc.
-
I did some tests today and it seems that 26 is the maximun number of channels that can be monitored successfully. I used 2 different Midi interfaces and the results were the same. Maybe this info helps
-
If by chance you have time near the device, can you check with your Fader+Pan preset the latest test build (380M)?
I am not completely ready, but if I guess it right, you should be able to use more then 26 channels (I mean unlimited).
Note that is "alpha" quality build ;)
-
Awesome! All Faders and Pans now working! :D
-
Good. That means I am not the right way with my modifications.
-
Hi AZ!
Doing some research, I have found an option for the controls that could be used as mode and state changers. In the mixer´s monitor section (p 97 on the manual) there are 24 selectors (Monitor Source Flex Bus and Monitor Source Input) that are mutually exclusive (radio buttons) and could be operated in groups of six using the buttons under the screen. These selectors transmit on the same address different values. For the Shift control the most viable option is the Monitor Dim control which is momentary using the Talkback/Slate Button, and could be locked using the Dim Button.
Yesterday in the afternoon I was trying to configure some buttons and found by accident that the console didn´t take the checksum value in consideration. It only needs a byte in the required posittion but the value was irrelevant. I did some tests in the AZ presets deleting the VM-C7200 checksum generating line, and putting 00 in the final line before F7 and the mixer responded fine. I did with the last test versión of AZ Controller (I tried to rollback to the previuos versión to confirm this but my presets didn´t open).
-
AZ Controller is not "forward compatible". Presets created in newer versions in general do not open in older versions.
Sorry for the delay. I hope to update the new version till the end of this week (configurable SysEx delay is already implemented, I am working with "echo cancellation" since it is too boring for buttons without it), but not 100% sure I find the time to finish it...
-
Don´t worry!
I am working on the layout. I modified the preset so it is now posible to select the faders functions between Track Level and Track Sends 1-5 on the first 6 buttons (B1- B6). Using Shift controls the respective Pans. The logic is raw and direct but it´s working and there is no need for feedback
-
With a delay... I have uploaded b381.
In the "Options" tab, it has "IO options..." button. Here you can:
* tune SysEx timing parameters (in the version you used before, that was hardcoded). Start conservative (up to 1 message per 100ms), then reduce till it stop working reliably and then increase a bit as a "safety". Since the documentation mention 1 per 20ms, may be that is the best setting.
* do not perform initial "timing tuning" with "suppression" set, since that will reduce the number of data actually send.
* note that for suppression work correctly, the checksum MUST be added. SysEx packets are compared verbatim. to check "suppress from" is working you need a button assigned to control with feedback, f.e. mute. How that works:
* Mute status checked -> sent to device (let say "Mute ON")
* Device echo "Mute ON", but it is suppressed by "from". (since that is the last message we have sent)
* You press the button, its internally set "Mute OFF" and send the message "Mute OFF"
* the message is processed, asking Sonar to unmute
* Mute status checked, so it is about to send "Mute OFF". But it will be suppressed by "to" (since the last message seen is exactly that)
* you change controlled WAI
* Mute status checked. Let say that another channel is also unmuted. Since the channel is changed, the system is about to send "Mute OFF", but it will be suppressed since the message to send is still exactly as we seen before.
Note that the whole MIDI engine has to be adopted for such operations, something can be buggy...
-
Thanks again AZ, you are amazing :D!
After many tests with the new preset everything seems to be working without bugs. The best setting for the I/O options is something like 80 ms of delay for every 6 to 8 Sys-Ex messages sended. Setting the delay for just one channel resulted in too slow redraw even with the minimun 10 ms delay setting.
I had to raise the delay value that Sonar uses after the refresh cicle in the feedback section from 1 to 2 seconds to ensure that the values remain unaltered while the faders reach new positions.
About the switches I am not shure how to translate the values back and forth. The switch transmit 0 or 1 while the function needs 0 and 127. Also, on the monitoring cicle we need back 0 and 1 for the checksum to be generated correctly. Could you explain me just the general scheme on how to do this?
-
If you attach your current preset, I can add let say "Mute 1" example, with correct translation and feedback.
In general, all "tricks" are simple. If "supression" flags work, we do not need any "3state per control" for buttons. In direct reaction, we can use the following to set parameter (after value 0-1 is extracted from SysEx):
Value:0 - Set Value absolute 0
Value:1 - Set Value absolute 1
Opposite in the monitor:
Value:0 - ... add 0 to sysex
Value:127 - ... add 1 to sysex
For correct checksum, the same special function as for faders should be used.
But as I wrote, I can make an example.
-
I got It!
Of the 3 main versions that I have for the preset this is the one that looks more promising. It has 24 faders that could be defined in the buttons in the Monitor edit screen as follows:
B1 -B6 define fader functions with Monitor Dim Switch as a Shift
B1 Volume
Shift B1 Pan
B2 Send 1 Level
Shift B2 Send 1 Pan
--- ----
B5 Send 4 Level
Shift B5 Send 4 Pan
B6 Selected Channel Pro Channel Functions
B7 - B12 are WAI definers
B7 Strip Type Track
B8 Strip Type Bus
B9 WAI -1
B10 WAI +1
B11 WAI - 12
B12 WAI +12
The preset works fine but sometimes the WAI position is changed when the Strip Type returns to Track after modifying the faders functions in the Strip Type Bus view. The B1 - B12 switches transmit the same message with different values so I choosed to have the value as part of the address portion to simplify things (I think it is not neccessary to have feedback in these Buttons because they are mutually exclusive but as I sayed earlier the logic is still in developement)
-
Buttons are working now!
Each strip now has working Mute, Solo and Audio Buttons with feedback. Because of switches´s Led colors I chosed to have Mute Switch (Red) asigned to Rec Arm; Solo Switch (Yellow) asigned to Mute and Audio Switch (Green) asigned to Solo-Select. When the Faders change from controlling Strip Volume to Strip Sends the Red Switches control Pre-Post Send and the Yellow Switches control Send Activation. In Pro Channel Mode the Red Switches take care of On-Off functions. Because of double function of Solo-Select I chosed not to change the Green Switches functions.
The WAI problem of not returning to the same position during Strip Type Changes changes was corrected. I am now in the procces of testing for bugs and defining the final layout. I am not shure about including an ACT Mode because of lack of displays for faders (and because I have the BCR-2000 too). A workaround coul be to use the Input Channel Short Name (3 char ASCII) wich is displayed on the Main Ch Level - Ch Pan display but is a little bit tricky to implement (you have to break the text in parts and send 3 different messages as seen on manual p 296)
The mixer has built in transport controls Stop, Play, Rec, Ffwd, Rew Return to 0 and a Joog Wheel. These controls use MMC protocol. Stop, Play and Rec are easy to configure but Ffwd, Rew, Return to 0 and the Joog Wheel all send the same message with Standard Time Specification with subframes defining bytes (ass seen in manual p 298-299). Each time you press Ffwd or Rew this bytes increment or decrement; on Return to 0 they are all set to 0. The Joog Wheel also increment/decrement these bytes, but you can choose wich byte to modify using the Time Cursor Modifiers (frames or seconds or minutes or hours). One easy solution is to send the time position back to the mixer but I don´t now if this could be done without loading too much the bandwidth
-
Nice progress.
Sorry, I am completely out of time at the moment. I have to play piano... Something natural for any normal musician, but I just play for myself (only). And this time there are going to be other listeners ;)
At location there is no real piano. In preparation of by MIDI "gear" I have found the interface crash when connected to my notebook way to often to trust that setup. I do not want kill all my colleagues by that crazy sound. So, new interface... On the way to the shop my auto wrote me "hm... time to visit garage". Complete mess.
-
Ups! :(
Sometimes unexpected things agreed to take you by surprise in a bad momento. I hope that your car gets well soon! If you play the piano with the same dedication that you put into programming, your presentation will be a memorable one, good luck and happy holidays!
-
Thanks!
The only problem is that I have stopped learning piano just before I have started programming... 30 years ago. So while the dedication is may be the same, the skills are by far different ;)
-
Hi AZ!
I hope you are having a nice holiday season! ("last action:failed > Undefined" ,I think maybe I am doing too much programming ;)) By the way, how was your presentation?
The preset is almost at its final (if there could be one!) versión. I managed to implement all of the wishlist ítems mentioned in an ealier post. The transport is working with feedback on Stop, Rec and Play. The joog Wheel works with some compromises and also the FF and Rew buttons.
Doing some experiments with text transmition I founded that the VM-C7200 have Dinamic Incremental Parameter Addresing (I don´t now if this its the correct term, but sounds nice!). If you assemble a sys-ex message with more than one data byte after the initial address, the console reacts in the same way as if you send each one with their respective incremented address. After discovering this, text feedback was very easy. In just one message per strip I can send the entire Long Text (12 char) and Short Text (3 char)
It its posible to assemble composed messages for some controls. By looking at the manual (Input Parameter List p 274-275) it seems that good candidates are Mute Button, Fader Level, Audio Button and Panner as they are next to each other. The Solo Button is in another category so it is better left alone.
The current almost complete versión is v211 (with individual addressing on controls). I did a test preset using v202 preset (to keep it simple) using compound messages. I revised the Yamaha 01v post for ideas, but the layout is different (the 01v uses one message for the same function on different strips and the VM-C7200 uses one message for different functions on the same strip). The preset works but its logic its no optimized. I did a complete versión (v214) and found that even without the optimized logic the refresh times are notably shorter and less prone to errors. The Echo Cancel Function does not work in this arrangement but the console works fine (even the buttons). Could you guide me on how to improve the logic? I am sending the test versión (v212), thanks again!
PS it seems that maybe there is a bug in the last AZController test versión (0.5r7b381). Everytime that I try to open the Display Configure Options Sonar Platinum (22.11.0 Build 111) crash
-
Hi!
I am fine and the presentation was good (at least from the computer, software and my performance perspective... we forgot to deselect "mute on mic in" button on our central mixer and by boss forgot to switch off own mic during 2 from 3 of my "performances", so the music level was so to say unstable... ::) ).
I have checked b381 and I guess I know from where the crash comes. Will fix that tomorrow, thanks for spotting.
Optimization of the preset needs some concentration and time. I guess not before the next year, sorry (fortunately the next year is around the corner).
-
b382 is uploaded. The bug with Display Configuration should be fixed now.
-
Happy New Year!
My best wishes for 2018!
-
Happy New Year! ;)
-
Hi Alexey :)!
After some research and experimentation I managed to implement optimized feedback on strip paramenters (Mute, Audio, Level and Pan). I am not shure if it is the best aproach but it works ;). I am sending the most recent preset (v214b) wich I think its very close to a final preset (with some room for expansión). I am now in the proccess of testing and refining some features and also on starting to write an instruction guide. Any suggestions are welcome!
-
Hi again Alexey :)!
With the addition of text feedback on the mixer display suddently Pro Channel and ACT modes became more practical because with so many controls available (24 faders, 24 "rotors" and 24 buttons) it´s easy to get lost without parameter information.
I have implemented ACT with 6 banks of controls. On the Pro Channel Mode I first started with a fixed paramenter assignation to the rotors and buttons (somewhat similar to Marko´s BCR-2000 preset). Later I founded that due to the mixer layout it´s more practical to distribute the modules in groups of controls of fixed size (including faders). Currently the layout is divided in 4 groups of 6 controls of each type. Group number 4 (Ch 19-24) is reserved for EQ because the faders are the closest to the 6 rotary knobs under the screen. On the 3 remaining groups it is possible to assign 3 Pro Channel modules. On the parameter selection I choosed to not define each module directly in the Filter action. Instead, I made module assigning subroutines which define a parameter position for each control. These states are dependent on a main PC Slot Number state set.
I could manually select the correct definition subroutine for each Pro Channel module loaded. My problem is how to detect which module it´s loaded on each Pro Channel Slot. Are there workarounds to Sonar limitations in that respect? I know that it´s possible to manually enter PC module definitions in AZ Controler. Could this info be used to autodetect modules? If it´s not possible to detect each module by position could all the modules loaded in the strip be detected?
In the VM-C7200 preset I can choose the type of parameter name displayed for the controls. When "Container" is selected, the text shows the correct PC module name, but I don´t know how to compare text strings (maybe by transforming the text into some arbitrary Sys Ex message and looping back?)
-
Hi!
I am fascinated that you still digging throw it ;)
Detecting which PC/FX is on each position is not possible. Well... we are in AZController world. It was not possible, till now 8)
Please download b383, its "Set state" action has "By text" option. !!! Do not forget save your current preset, better with export. b383 updated version of preset format, so older versions will
not work with what it saves. !!!
I attach an example how to use this new feature. It tries to monitor current track SECOND PC module name and change the state of corresponding set. Notes:
* example put the name in question into Text and then monitor this text (static monitor). In the feedback, it tries to match some state name by current text, setting some
"fall back" when not found.
* the monitor should have priority LOWER (in number) than monitors for PC parameters. So when the change happens, it change the state before you use it to select parameters.
But in case you make it "Strip" state dependent, it should work after strip type detection. Priorities fix the sequence in which monitoring happens.
* special name "<other>" is used for unknown modules. For not default modules, you can define them. Then add to the set it question. Then define corresponding processing. Tricky, I know.
PS. everything related to ProChannel in Sonar is extremely buggy. I mean the way CW has implemented it. Also PC is Sonar exclusive, you will be unable to move PC settings to other DAW.
Two bugs related to what you do now:
1) Sonar fail to return the name of PC modules. It returns it for FXes, Synth and even for "ACT mapping" module, but not for Filters. So names are "guessed" in AZ Controller (some are hardcoded, the rest can be user defined).
2) Sonar 8- filters had fixed positions, initial X1 PC also (0 - EQ, 1 - Comp, 2+ not used). CW attempted "backward compatibility" in API, but completely failed with that. As the result, not only old plug-ins are unable to work with EQ/Comp, AZ Controller has hard time to provide related functionality. Short description of the mess: "EQ" and "Comp" for NOT focused strips are ordered according to the focused strip, other modules are not accessible at all for not focused strips. So, what is PC Module number X for strip Y in API depends from which strip is in focus and only EQ/Comp can always be somehow found.
There are other, f.e. accessing Compressor type parameter name (so, which should always just return "Type") after several calls CRASH Sonar. The reason why Mackie (MCU/C4) owner should avoid "EQ" and "Dyn" buttons to prevent random crashes (AZ Controller and my Mackie mod have hard-coded workaround).
I am (not yet) discourage you to use ProChannel (and Sonar). I just want to inform you which "quality" that staff has, especially since we know that will never improve... :(
-
Thanks Alexey!
I apologize for not being able to respond earlier. I am not with the machine right now but I can do a review of the new Pro Channel mode with text recognition function in 3 words: It's like Magic! (maybe that was 4 ;))
-
I am glad in case it work and will try to fix in case you find some issues with it.
But please do not apologize for delayed responses, I am AZ SLOW ;)
-
Hi Alexey:)
Now that Sonar lives again:
I've tried to load the VM-C7200 Preset just to look how it works to send a row of Sysx, but I can't figure out.
It doesn't load:(
I have no Roland so perhaps it only works, if I have one...
Could you please send me just one command to send Sysx Commands to my mixer from the BCR2000 Preset??
I only do need 2-3 sends for it, all the rest I do in the DAW
Thank you very much;)
Heinz.
-
I guess VM-C7200 presets will not load into older AZ Controller, only into current test version.
To send SysEx, add an Action and select "SysEx/MIDI" as the type. You will get a field to enter the sequence itself, as hex numbers (like 01 45 a4 7d).
-
HI Alexey:)
Ich dachte ich hätte die Neueste installiert, aber ich teste das noch!
Geht das auch in beiden Richtungen? Als für einen Fader hab ich ja 2 verschiedene Befehle für Increment und Decrement....
Kucke mir das Preset etwas genauer an, wenn es denn geladen wird.
Danke dir;)
Heinz.
P.S. Ich finde keine Testversion zum downloaden, die letzte "stable Version ist "azctrl_0_5r6b380.exe"!
Mit der kann ich das Preset nicht laden....
P.P.S.S. ;) Hab's gefunden, manchmal ist man blind:(
-
Mit SysEx geht alles. Allerdings nicht so einfach wegen keinen vordefinierte Standard.
Beschrieb was genau willst du haben, dann mache ich ein Beispiel wie es geht.
-
Hi Alexey:)
Ich hab 4erlei Sysx:
F0 43 10 3D 00 00 2A 00 00 F7, wobei sich die Nullen vor der F7 ändern, ich glaube von 00 00 zu 07 F7, muss ich noch nachkucken!
Hier der komplette Eintrag:
S 10 {F0 43 10 3D 00 00 2A 00 00 F7}
M Y = X
M Y > 4
M Y & 15
F Y 7
M X & 15
F X 8
T 10
F0 43 10 3D 19 00 07 01 F7, das ist ein Schalter ON, Off wäre F0 43 10 3D 19 00 07 00 F7
Eintrag in der Software:
S 9 {F0 43 10 3D 19 00 07 01 F7}
FX 7
T 9
S 9 {F0 43 10 3D 19 00 07 00 F7}
FX 7
T 9
Dann hat es noch manche Fader oder Regler die mehr Bytes haben, also F0 43 10 3D 00 00 2A 00 00 00 00 F7, wobei Byte 8 und 10, 9 und 11 sich identisch bewegen.
Dann gibt es Regler mit Minus und Plus, hier mal der komplette Eintrag in meiner Software (Midipad)
M X -36
S 10 { F0 43 10 3D 00 06 48 00 00 F7 }
M Y = X
M Y > 4
MY & 15
F Y 7
M X & 15
F X 8
T 10
Ich bräuchte wahrscheinlich nur 1 Fader (10 und 12 Bytes), 1 Schalter und 1 Regler mit Minus und Plus.
Wäre super wenn ich das ins Preset miteinbauen und auf einen Midikanal ausgeben könnte. Ist immer ziemlich lästig auf die Software zu switchen und manchmal verstellt sich was, weil das Teil ab und zu spinnt und alle Fader neu ausgibt....
Mach dir nicht zuviel Arbeit! So wichtig ist es nicht!
Ich steig leider bei dem Roland Preset nicht dahinter wie das funktioniert, ich finde die Sysx Befehle nicht, die müssen doch irgendwo hinterlegt sein....
Vielen Dank vorab:)
Heinz.
-
Sorry, I have not understood what you want :(
I attach a preset. Theoretically it should change current track volume from the fader and toggle mute from the switch.
I hope that we can use as start. Check that there is some reaction and let me know what exactly you want when the fader/switch are operated.
-
Hi:)
Kein Problem, ich kann das erst am WE testen, mein Studioamp ist in Reperatur, der hat angefangen zu brummen.....
Melde mich alsbald!
Danke;)
Heinz.
-
Hi:)
Ich hab mich jetzt entschieden ein neues Pult zu kaufen, das 02r ist jetzt doch schon ziemlich altersschwach, war halt auch viel auswärts im Einsatz! Insofern hat sich das mit den Sysxbefehlen erübrigt, das neue Teil wird Editortsoftware haben....
Trotzdem vielen Dank Alexey:)
Mal kucken, ich hab mich jetzt in Studio One eingearbeitet, möchte mir noch Cubase ankucken und Reaper, das hat beeindruckende Funktionen an Bord....
Sonar macht halt wegen der BCR2000 am meisten Spass! In Studio One hab ich lediglich geschafft die Zoom Funktionen auf einen Regler zu legen, da kriegt man überhaupt keine Hilfe oder Referenz von PreSonus für die Surface Dateien.
Bis denne,
Heinz.
-
Hi!
Wie du vielleicht schon bemerkt, ich bin in der Richtung Reaper gerutscht. Eines Tages wird da AZ Controller funktionieren...
Studio One hat dafür kein API (die wohlen eigene Controllers verkaufen), Cubase ist von Yamaha nicht weit entfernt.
Reaper is der einziger DAW welcher wie Sonar CS API hat.
Falls ich korrekt erinnere, Varispeed kann für dich interessant sein. Und deine Sonar Projekte kannst du in Reaper einfach öffnen (dank bei mir geschriebene ReaCWP), mit andere DAWs geht das nicht.
Reaper ist viel mehr als man zuerst sieht. Klar, in ein paar Bereiche fehlt etwas. Aber geschrieben ausschließlich bei Top Programmers, in Stabilität, Geschwindigkeit, Erweiterungsfähigkeit und Lizenz Reaper ist unschlagbar.
Justin bezahlt für keine Werbung (Design, Management, ... so kann er die Kosten niedrig halten ohne dabei auf Qualität zu sparen) , aber ich mache viel Kostenlos ;)
-
Happy New Year Alexey!
It´s been almost a year since my last post, a busy one, fortunately!
I want to thank you for all your help and support. It´s been a joy working with the VMC7200 on many projects!
I want to add a more polished (finished?) version of the preset. Maybe I´ll do a translation to the Behringer/Midas X32
M32 mixers in a future time. Best wishes for 2019 and thanks again!
Julio