Hi Tiburio,
thank you for your detailed feedback! I am sorry that the latest update included changes that do not work well for you.
As Steve said, we don’t have any evidence that it is buggy. We don’t have any such reports from other users, and also we here at Bome work with MT Pro on a daily basis and don’t experience problems with copy/paste or even freezes. For us, it is very important to fix any bug and freeze to ensure that MT Pro is the most stable MIDI processor. If you could provide us more info, it would help us enormously to hopefully fix your issues:
- are you on Windows or Mac?
- as Steve pointed out, please make sure to use the latest version (as of December 2023: v1.9.1 build 1060).
- if you can find a step-by-step way to reproduce the copy/paste problem, please report here (if we cannot reproduce it, we will not be able to fix it).
- if you experience a freeze (or even a crash), please follow these instructions to send us a dump file: Crash or Freeze? Please send us a dump file!
Also, explain what you were doing before the crash or freeze happened. Thanks!
Here, I can shed some light. This was changed due to this report: Lose the 0-15 Count in MIDI Channel Outgoing please!
You’re absolutely right that you should be able to select the correct channel by just entering the number. We want MT Pro to be easily usable without mouse! We’ll file this as a bug.
Whether channel numbering starts with 0 or with 1 is not easy to solve. I guess that it’s an individual preference, or even depends on the kind of project you’re working on. I think displaying both is a good compromise.
I think what you’re referring to is that when you’re editing Outgoing action of Translator 1, and then go to Translator 2 via Cmd+N (or ctrl-N on Windows), the Outgoing Action may move up or down.
This ‘jumping’ is a problem we’re aware of. We’ve actually improved (reduced) it considerably in the last versions. But under some conditions it is still there, especially if the Incoming section is larger or smaller in Translator 2. We’ll record this as a bug.
We thought that this problem was fixed in v1.9.1, and I cannot reproduce it here. Could you provide a specific example where that happens?
Yes, this is a highly rated feature request. Unfortunately, it means reworking ALL GUI code for the actions, and to come up with sensible solutions when the selected translators have different types or Rules. It should not be easy to accidentally overwrite all selected translators (e.g. the Rules).
I’ve bumped up the priority of this feature request.
I fully feel with you here. We use empty presets with dashes as name for a minimal kind of grouping, but of course that is not what you need. I’ve bumped up the prio of this feature request. If we implement this will be a decision of simplicity vs. functionality. But maybe we can find a way to keep the simplicity of the preset list while still offering hierarchical presets.
Your project is 80MB? That would be the biggest project we’ve ever encountered, by far! Although the processing engine has no problem with huge projects, the GUI editor may respond sluggish sometimes, with such huge projects (although we try to optimize things as best as possible).
Great request, and also already in our feature request tracker.
Great new idea! Added to the feature request tracker.
Very nice idea. You mean you can start an LFO via an Outgoing Action, and it would regularly call an Incoming Action ‘LFO’ with the current LFO value?
In summary, thank you very much for taking the time to write down all these requests. We’ll use this forum topic to track any questions and progress.
You will also like @SuperTrev’s feature requests, some of them are overlapping:
MT Pro Feature Requests