MTP isn’t working with my disable processing translators anymore.
I have “disable processing” on Ctrl + Alt + D. It won’t work anymore. I’ve checked all my shortcuts and MTP is just refusing to accept it. I changed it to Ctrl + Alt + Y and it works.
I tried using variables instead of preset switching.
I have two translators both triggered with Ctrl + Alt + Y. One disables MTP the other enables. Project starts with z1=2
Both have a gate:
Disable:
if z1=1 then exit rules, skip outgoing action
z1=1
Enable:
if z1=2 then exit rules, skip outgoing action
z1=2
MTP isn’t disabling when I hit Ctrl + Alt + Y with this. It’s not working.
I put this on another thread because it is a different subject. It is working for me, however remember that keystrokes might be ignored if MT Pro has focus.
Also, if any other application is using these shortcuts, it is not clear which application will process it and whether the shortcut gets passed on. Disable-Enable.bmtp (854 Bytes)
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Ok. Ctrl + Alt + Y works for me. I don’t know what is stealing the other one, but something is.
I have to reinstall Windows now because of a registry problem. That might be involved, I don’t know.
So apparently you aren’t supposed to indiscriminately sweep your registry with Ccleaner. I didn’t know that. My Windows is reinstalled.
But my interest in the second part of my question is in why my logic gate wasn’t working.
The project will disable, but won’t enable again. Enable Test.bmtp (1.3 KB)
I believe this is a bug in Ver 1.9.1, although also I think there is an issue with your logic because the first translator executes and then you set the global variable which allows the second translator to also execute.
Here is my version but again it doesn’t work on 1.9.1 but does on 1.9.0.
It looks like on 1.9.1 that rule processing and timer processing also gets suspended.
Ok thank you for the help.
Yours makes sense, and is what I use for other translators, but I still don’t understand why this alternative method doesn’t work. (I’m just curious, if nothing else).
If translator A exits the rules at that line, then the variable isn’t changed and the output didn’t execute. The B translator executes and changes the variable. But now the B translator won’t execute and won’t change the variable. A does. In theory it’s supposed to be the same as your method.
Like I said, I believe it a bug in 1.9.1 and have reported it. In the meantime, I think the only workaround would be to disable and re-enable a preset instead of using disable processing.
The other option would be to go back to 1.9.0 until this get sorted out. Again I tested with both 1.9.0 and 1.9.1 and their behavior is different.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Florian pointed out that this is not a bug in 1.9.1 but a fix from 1.9.0
Apparently, Project disable in 1.9.0 didn’t actually stop everything. As far as I can tell, rules still process in a disabled state but in 1.9.0 the second translator was still allowed to process. I think it has something to do with the parallel nature in handling some incoming trigger.
What I did is put a ‘stop processing after executing this translator’ flag in the first translator to ensure the second translator did not also trigger from the same keystroke if the first was successful.
So if the first translator is successful, the second one does not trigger, however if it is not successful then the second one is allow to trigger.
The first one will look at the value of z1 to determine whether to trigger or not
To be honest, the idea of ‘Stop Processing’ never made much sense to me because there always needs to be something running to tell it when to start again.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
I agree that the behavior is not really intuitive. The documentation, while correct, also does not explain all aspects. The key idea is (and has always been) that during ‘Disable Processing’, nothing works, except for Translators that have a Project Action as Outgoing type. The latter ensures that you can re-enable it again via a Translator.
Now currently, during Disabled Processing, it works in a way that just the Outgoing Actions are disabled. So the Incoming Actions are still evaluated, and the Rules are also executed if the Incoming Action was triggered. In my opinion, also Incoming Actions and Rules should be disabled. What do you guys think?
Anyway, here’s the refined text for the MIDI Translator user’s manual, for Outgoing Project Action:
The MIDI processing engine as a whole can be bypassed using the Disable Processing Outgoing Action, preventing any of the translators from being executed. All Timers are stopped, and incoming events will not trigger any Outgoing Actions. There is one exception to this rule: all Translators with an Outgoing Action of type Project are still executed.
During Disable Processing , the only way to re-enable it from the project is by executing the Enable Processing Outgoing Action defined in a different Translator. As said above, all such Translators with Outgoing Project Action remain enabled. You can also re-enable a disabled project by pressing the Panic button in the tool bar.
It really depends on what the user is trying to do. If it is to reduce CPU load then you are probably correct, however if it is just to disable all outgoing actions then it is kind of nice how it is currently implemented. The watchdog timer example that I posted would not work in the first case because without the timer running it would never trip. Of course if the objective is to reduce workload, then another way to suppress output might be better, like disabling presets or using dependencies on global variables to enable or disable outgoing actions in translator rules.
Oh I didn’t know about the stop flag. Actually I recently took mine off, (before reporting this) and from what you said, that might be what broke it.
Yes, suspending everything except for still listening for the “enable processing” translators is ideal.
My faders that re-enable at a value of 64 is also affected by how enable/disable works (Currently they are working fine, last time I checked). Value 127, or 0 disables MTP, 64 enables. 64 translator has a variable that ignores the output, unless the variable is ‘on’ from either the 0 or 127.
I have a “Suspend MTP” macro on my keyboard, so that it’s independent of my MIDI controllers. It has a right light toggle too, when MTP is disabled.
