There are some pretty significant differences in the behaviour of 1.8.4 and 1.9.0.
For instance, In 1.8.4, I would have 5 translators that were ‘on activation of this preset’ and when the Preset was activated they would all fire off fine.
In 1.9.0, I am finding that I need to delay one or more of them in order for them to fire off. In some cases I am needing to put a 1sec delay as 50ms is not enough.
Also, I am finding that Presets that are meant to activate in consecutive order seem to be skipping through. So I have to again put small delays on the outgoing action to avoid this.
Is there a way to maybe create a ‘natural delay’ giving BMTP time enough to discern the difference between actions carried out in one Preset and actions carried out in another Preset without the user having to manually add 10-50ms delays all throughout their project?.
Hi,
Thanks for your feedback! We will check into it and I know you provided one example before and we did and update. Perhaps another example or two would help us uncover more potential issues.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Hi Jesse,
thank you for this report. Backwards compatibility is very important to us and we have not (knowingly) changed any behavior for processing the Preset actions. Processing of the MT Pro translators is deterministic and in order. In particular, MT Pro will never miss an incoming action! That would be a very serious bug.
The only exception: what might change from release to release (and from computer to computer) is the behavior on race conditions, due to the parallel processing in the MT Pro engine. But one single incoming event will always process all (enabled) presets and all (enabled) translators.
Having said that, we’d like to find out why and what you’re seeing. Can you please post your project file (or a simplified one), and the output of the Log Window showing the problems you’re seeing? I appreciate your help very much.
Thanks you!