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.
We don’t solicit MT Player licensees. They would need to come to us. And if they had already contacted us, it would be confidential…
Hi Florian,
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.
Regards.
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…
Hi Florian,
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?
Thank you.
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…
Hi Florian,
thank you for your reply.
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.
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!
Hi Florian,
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:
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.
Thank you.
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…
Hi Florian,
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!
Thank you.
Hi Claudio, I really appreciate your interest! But this is still slightly more than we’re able to disclose. And yet, we’re still far from doing it Apple-style, which never publishes any plans or announces products before they’re done.
We do disclose detailed lists of “released features”. For MIDI Translator Pro, you can find the list here:
https://www.bome.com/products/miditranslator/overview/version-history
We’re a small manufacturer, and it’s an advantage that we can stay flexible. We have hundreds of features “planned”, and dozens “in progress”. The prioritization of the “planned” features can change at any time. And what will actually make it into the next release mainly depends on the quality of our implementation. If it’s not good enough, yet, we’ll leave it out of this release and schedule it for the next (pending quality control).
Here’s the long explanation why I said that not disclosing our planning is better for customers, the product, and for us:
As soon as we declare a feature as being “in progress”, interested customers will assume a right to that feature and urge us more or less to finish it asap. Then, some or all of the following will happen:
And if customers aren’t happy, we aren’t happy, either.
Hi Florian,
this can be solved by splitting the ‘in progress’ section between ‘in progress’ and ‘in progress for next release’ and anyway by always clarifying in a sticking note at the head of the list anything you might feel suitable to communicate regarding ‘planned’ or ‘in progress’ features (for example: ‘please understand that effort is required for development …etc’) effectively educating your users.
Said that, I must belong evidently to that ‘rare’ category of users that feel unhappy if left completely blind in regard to ‘planned’, ‘in progress’ and ‘in progress for next release’ features and I can’t really say ‘thank you’ for that.
Claudio, believe me: that won’t work. I tried. Most customers are likely to take any announcement (no matter how it is phrased) as a promise.
I don’t think you’re the only one. But the fact of the matter is that the only thing we guarantee is the current set of features. That’s what you purchase. Any future features delivered via update are not what you purchase. We do provide updates for all 1.x releases free of charge, but we just don’t guarantee anything else with respect to future updates.
I don’t think users should be unhappy about free updates. Even if they don’t know what the next update will bring. They already got what they purchased.
And everyone who has received a free update, has already received much more than what she or he originally purchased.
You’re welcome 
Hi Florian,
I do not know why you brought up this unrelated subject. Our discussion is NOT about features in the current purchase of BT and NOT about the updates price policy.
The subject of our discussion and dissatisfaction is about the fact that users are left blind regarding the specifics of future planned and in progress features because (as you say) of most of your uneducated users behavior for which all of them (including the educated ones) pay the consequences.
Hi Florian, I do not understand how comes that many other software companies, from little start-ups to well established and/or big ones, manage to have a well laid out and tidy system for collecting features requests and informing their customers about future planned developments status without making a big fuss about it.
I guess that they also might have the ‘majority’ of customers potentially uneducated.
I guess that if they receive an email chasing anything they might simply have in place a reply saying for example: ‘look, we got a standard reporting system set up that you can find here and there, and we cannot provide any further or better information about actual release time. Therefore please keep logging on that system to find out if any status update changes. Thank you for your understanding and interest in future features development’. That’s it!
I can’t be sure about their actual answer even though I am client of many of them because I NEVER chased anything but definitely I submitted features requests and I am COMPLETELY happy about their really cool reporting system. One of the excellent examples (user request driven) is this: Feature Requests - Integrately
If a user request driven system does not suit you, a simpler reporting system not based on votes or user requests but simply on your own decisions (while anyway collecting public user requests for consideration) can also be set-up.