Could you please provide more details and possibly a practical example for the implementation of this.
Moreover, I am also trying to implement a more ‘expanded’ version of this for which I need some additional help.
This is what I would like to do:
I need first to capture the current numeric field value (Center X) form the destination software into a variable (local or global?).
Then I have to increase or decrease the captured variable value.
a) To do this, I can add/subtract a value unit to the previous variable.
b) The increase/decrease of the variable unit value to be set to ‘continuous’ and will the depend by the fact that I keep or not pressed the relative midi key.
c) The ‘speed’ of the continuous value increase/decrease to be controlled by an additional midi button or slider.
Then I have to output/write every time the increased/decreased updated value into the field of the destination software.
Would you please suggest an efficient way to achieve all of the above and possibly/ideally provide some practical examples. The solution to this case would also apply to many other similar scenarios therefore I think it is worth to clarify it properly.
In my case I’m using relative encoders(knobs) that send a value of 65 or more for right movement and 63 or less for left movement. If your controller send different values, the programming of the movement will need to change.
Attached is the project file I used for the demonstration.
Hi Steve,
I have been through your project ‘Relative-to-Mouse-Drag-Davinci-2022-03-30’ and I got some questions:
With regard to Translator ‘Move Encoder Set Watchdog’ I think to understand that its functions are:
a) To run once one of the knobs is moved.
b) To activate debug mode (if needed) by setting manually global variable zz to 1
c) To create a Timer action called ‘Watchdog’ with a 1000ms delay, cyclically as long as knob movement is detected.
With regard to Translator ‘Watchdog - Mouse Up’ I think to understand that its functions are:
a) To perform action ‘Mouse up’ following call after 1000ms from outgoing Timer action ‘Watchdog’.
Please correct me if the above interpretation is wrong or if it is worth to add some more details.
In any case, with reference to the above, my questions are:
1c) Why do we need to create this delay?
2a) What if we keep rotating the knob more than 1000ms? In this situation does the ‘Mouse Up’ action still gets performed at 1000ms effectively interrupting the rotation of the knob even though for a fraction of time? If so, won’t make more sense if the ‘Mouse Up’ action gets performed only if I stop turning the knob?
2a) Instead of using the Timer trigger (Watchdog) for Translator (Wathcdog-Mouse Up), could we not have used instead just a ‘Knob not turned’ or ‘turning knob stopped’ input trigger (and if so how to create this trigger)? Also why this system would be eventually less efficient than yours?
You need to wait a period of time before triggering the mouse up otherwise it will interrupt what you are doing with the knob.
The delay will extend by triggering again if you are still turning the knob, thereby disabling the mouse up action. There is no ‘event’ for stop moving other than using a watchdog timer. You can change the delay to shorter if you think 1000ms is too much. If it is too short, it may indeed trigger mouse up if you pause turning the knob.
Your assumptions are correct.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
While I was setting up my Maschine MK2 knobs to “relative offset” mode, I come across a behavior that I did not expect, which is when I turned the knob the MK2 was outputting on its screen only 2 values: 0 and 2 !
Checking the above MIDI output on Bome translator it turned out that those values were actually 63 and 65.
I thought initially there was something wrong in having only 2 values as output from a relative offset mode until luckily I came across a wonderful post from you on this thread Translating absolute MIDI CC into relative -1/+1 values which explains in deep and very well, beside other things, how various types of relative encoders work.
That has been a godsend for me and I wish to thank you for that excellent post and to mention solution link on this thread so that will be easier for other users to find it.
Hi Claudio,
thanks for that interesting discussion and the nice words!
2 cents from me:
Yes, I fully understand that this could be a natural area we could diversify into. One hurdle for us is actually our commitment to quality and customer service. If we would release, say, a specific solution for Davinci Resolve, we’d want to need to acquire know how with that video software, so that we can create a suitable solution, and provide the customer support for it. Unfortunately, at this time, we don’t have the man power for all of that.
For now, we stick with what we know and we see as a core strength: build the tools and let the customers work on actual solutions.
We do offer an OEM version of a runtime of MIDI Translator Pro (MT Player): if a customer wants to get into the business of marketing a specific solution created with Bome MIDI Translator Pro, we can enter a license agreement. One example is MIDIGrade, where the customer even wanted the user interface fully customized. It’s actually a MT project file for using a MIDI controller for color grading in Davinci Resolve.
Good find! We also provide a video tutorial for that:
it is a honor to have your participation in this thread, it looks like I manage to attract your attention
Thank you for:
the link to the video tutorial
mentioning one of the solutions to a pre-made mapping for DaVinci Resolve.
clarifying your development policy.
With regard to the above points this is my reply:
While I must give credit to MIDIGrade’s creator to have done an admirable job with the mapping, it looks to me that (at least for MAC users) the previous mapping solution I mentioned (the one for the AKAI APC 40 https://www.youtube.com/watch?v=7S03SN0GKeU&t=1471s from tachyon-consulting.com) is more powerful because:
a) (corrected post): It allows to customize DaVinci Resolve ‘Suite’ parameters (excluding FUSION page parameters) to any MIDI control, not just Color correction/grading parameters. Depending by the DaVinci page/environment characteristic, to control parameters it uses sometime screen coordinates (for example in the Color page because the page where the controls are is mostly static) sometime various programming tricks (where possible and for less static pages). Because Fusion environment is dynamic and the most/completely ‘closed’ compared to other DaVinci pages/environments, it is not possible to use screen coordinates or any programming tricks to control his parameters. Please refer to http://tachyon-consulting.com for further details.
b) The software required is currently less expensive, about 100 Euros (and the fact that the cost of MidiGrade jumped from the initial 49.95 Euros in the year 2016 to the the current 224 Euros is definitely exaggerated and excessive. Even with an eventual discount which brings the cost at 145 Euros it is still a big jump).
c) You can get one of the hardware required (the AKAI APC 40 MK1) on the second hand market for less than 100 Euros.
d) Therefore considering all of the above points you can get a much more versatile solution for less than 200 Euros.
I understand your policy and current constraints and I hope one day you will manage to diversify and offer a versatile DaVinci Resolve scripting solution that works on the ID of any of its parameters and allow mapping on any MIDI device (and eventually as well on computer keyboards). I am not aware that this sort of solution already exist and I am wondering (from the the development point of view) if a Midi Translator API would be required or not to achieve that. I am sure you could answer to this question perhaps clarifying as well the best way to interface a DaVinci script with MT.
Additionally, since tachyon-consulting.com solution seems to be available only for MAC, won’t be a good idea if you would contact the developer and suggest to come out with a solution for Windows using your software MT player?
Hi Claudio, thanks for the further thoughts on this. In general, we are not involved in the business of our licensees (features, pricing, etc.). I’m not trying to sell anything here.
I understand that you’d like better support for Davinci Resolve in MT Pro. But specific support for it wouldn’t be something we are likely to add. That’s best done in products created by Davinci Resolve experts.
never thought so. I was just providing a comparison on various aspects of two competitive products which I think might be appreciated by DaVinci users.
Fine. At least you have been clear on this…not so Blackmagic Design which inquired if they would add more ‘open’ support to MIDI (or at least a complete set of parameters keyboard shortcuts) they just replied the standard ‘we will refer your request to our development team’ without providing any further details…
is there any chance Bome Translator could introduce a more ‘object oriented’ friendly GUI and in particular introduce a typically powerful node based one like ControllerMate ControllerMate has?
Beside the node based GUI is also typically the choice of powerful software like DaVinci Resolve (at least for some of its pages/environments) but also many powerful others.
On top of that, it seems that ControllerMate is more suitable to be used in medium to large projects because it has excellent inter-object communication, which is the reason to make it the preferred choice for sophisticated object oriented projects like the the DaVinci Resolve mapping solution discussed before from http://tachyon-consulting.com.
Therefore could you please let me know if any of the above improvements will be introduced into Bome Translator and if so what would be the time frame?
Hi Claudio,
thanks for the additional thoughts. As you know, we listen to our customers and consider all suggestions. And we do have a lot of ideas for the next major update of MIDI Translator Pro.
But we don’t copy features from other software. If ControllerMate works better for you, then you should use it instead of MT Pro. Or, if it has other problems, work with its manufacturer to have them fixed.
MT Pro has some unique features and a defined scope. It’s not meant for huge projects (though its performance scales remarkably well…). So, rather than trying to provide a tool that tries to work for everyone, we try to focus on the core strengths of our software. One important aspect for us is to limit features and complexity so that the learning curve for new users is not too steep. Believe me, maintaining a balance here is not always easy, because I would also like to add many more features!
I’m sorry I cannot answer this in the way you would have liked…
I have only one main objection to your answer and it is when you say ‘we don’t copy features from other software’.
I am sure that this is not the way (copy features from other software) other software companies think when they adopt a node based GUI design proposition. It is just a technology that exist not invented by a specific software company therefore ‘copying it’ does not apply!
Moreover it is actually true that a node based GUI shortens the learning curve and make the setup process typically more visual, fast and more clear to operate/modify making for that also the preferred choice for live performance use and also for musicians not too much into traditional programming.
I understand that you will not take into consideration my two proposals for software improvement.
You’re right. I should have said: only because another manufacturer uses a certain user interface will not make us consider it more. Frankly, we don’t care what others do. We value what our customers say (you!) and we discuss internally and come to our own conclusions about UI and UX questions. We want our software to have its own philosophy and character.
This is not the point.
We do consider all proposals
What is an improvement and what is not, is very subjective and depends on many many factors. What you see as an improvement might be seen as a degradation by another customer.
Furthermore, your statement implies a certain expectation. But please consider that MIDI Translator is on the market for more than 20 years and it has a certain design philosophy. You just cannot expect us to completely change that quickly.
We are constantly thinking and brainstorming how to improve the user interface. We’re watching first-time users to understand flaws and problems. We have already thought of how and if such a ‘node’ architecture would make sense, and we’ve also considered much more radical changes. So yes, we are open to changes!
In summary, we do consider your proposal, but we may not agree that it is a good fit for MT Pro at this time. But as said, this idea has been on the table for a long time. We may pursue it later if we think that it’s a good fit, then.
thanks a lot again for your reply, always sooo much appreciated as it makes me (and the users) understand better also the overall software development (short and medium-long term).
and customer support policy.
I just would like to say that I never had expectations or request for a quick change/release and frankly I never implied anything like that, but definitely my query was to find out if my proposals will be considered and implemented in future AND if so what is the time frame to release them.
From your last answer I understand now that:
They will be taken into consideration
Even if this improvement has been on the table for long time, you are still not sure if it will be actually implemented or not.
No time frame given, even approximate (perhaps because of point 2 above).
You also say that “you do not care what others do” and “value what our customers say” and that " we may not agree that it is a good fit for MT Pro at this time".
Well, my user reply to that is that: I am interested in better solutions than others offer, I am not asking for a better solution for BT “at this time” and I am just expressing and therefore propose an improvement into a direction which beside I am sure will make MT more inviting, powerful, user friendly, easier to manage (also visually), allow more developers adopt your software and therefore increase competitiveness, exposure and sales.
Therefore, an improvement to your answer would have been (as long a decision is finally taken) if the features proposed will be introduced or not and time frame for it (even approximate time frame will be fine). Missing all that perhaps you could tell us WHEN a final decision will be taken.
Hi Claudio, of course that would be useful for you and many customers who long for certain features. Occasionally, we do disclose future features. But please understand that we never disclose any internal time planning. We’ve learned that this is better for us, for the products, and for our customers…
Would you please at least provide a roadmap without release dates? Ideally one that clarifies what is ‘planned’, ‘in progress’, ‘released’. That can’t be something bad for anyone and it is actually used by other developers to better encourage ideas, participation and excitement (let say) from users!
