Greetings. Loooonnnnnnnggg time user of MT Pro. While I purchased and use MT for what it can and does do, I was of the impression from many years ago that various things were being worked on and would become part of MIDI Translator in time. In particular, unlimited (or, at least, a lot more) global variables and the option of values persisting between sessions.
Are such features on the horizon at all or am I waiting for something that will never happen? The lack of these features in particular has stopped me from taking the plunge with a BomeBox.
I believe the next version of MT Pro is planned for release soon. It will have an additional 270 global variables. I’m running a release candidate version now. Global variables will still not be persistent between sessions by default, however there will be a command line option to either set them or restore them. I have a helper application (thar runs on Windows platform only) that does just that.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
And while that increase of global variables will be appreciated, why not a more open framework to allow an unlimited number? Or, at least, something that’s practically unlimited.
Well sorry but I’m not sure I can answer your questions as Bome does not provide pre-announcement information or schedules of availability.
With that said, since the next MT Pro release is currently past Beta and I’m working with a release candidate (RC), that generally means a new release is coming soon. The functionality I’m speaking of has been in Beta and is now a release candidate.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Named variables are indeed a top priority, but because they require parts of the engine to be rewritten, and a new .bmtp file format, we’re developing that feature in parallel. As Steve said, the upcoming version 1.9.0 will not have named variables, yet. Sorry for the loooong time we’re letting you wait on that.
The situation is a little less clear on the situation with persistent variables. We cannot just make all variables persistent. So the general ideas are:
introduce a third type of variables, so that we have: 1. local, 2. global, 3. persistent variables.
add an outgoing action to save and load one or more variables from a named storage space. For example: save [g0, g1, g2, g3] to storage [knobs]
Where knobs is just an arbitrary name, and you can use any number of storage spaces.
add load and save functions to the Rules, e.g.,: save g0 to "knobs" save g1 to "knobs" load r0 from "random seeds"
What do you think?
PS: we don’t confirm specific release dates… sorry!
Regarding the global variables, it’s great to hear that the more open framework of named variables is still being worked on. Looking forward to the interim solution too.
As for the persistence of them, the third option, using functions in Rules, seems by far the best and most flexible, while also allowing easier integration with existing workflows. However, I am curious why all global variables can’t be persistent by default: could their values not simply be stored with the project file (either as metadata or as a linked file)? At least with that third option, all global variables could be persistent with the necessary lines of Rules.
And I completely understand about not sharing specific release dates, my query was more about whether we’re talking weeks, months etc. Just a rough timeframe, but it doesn’t matter. I’ve waited this lonnggg.
Let me know if you would like another tester/feedbacker though.
I think most of this would have to do with backward compatibility as currently all global variables are assumed to be zero at startup. Of course you can set them as part of an initialization sequence. Bome takes great pain to ensure backward compatibility.
Having a rule, that loads variables from persistent storage (from the last session) instead of manually initializing the variables should be rather straight forward. This give the user a choice and maintains compatibility.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
In addition to the backwards compatibility mentioned by Steve, the reasoning here is that most projects don’t need persistent storage, and they ‘pollute’ storage space. These translation projects also run on the BomeBox, and it has limited flash memory.
Here is a fourth option we are considering:
mark a project as persistent so that when you close it (or MT Pro), the state of all variables is stored. When reopening that project, all variables are initialized with the stored values.
The third option from before (load/save from Rules) still seems much better, more powerful, and more flexible. Seems like it would be best for everyone: best for you because it retains backwards-compatibility (just adding Rules functions) and means all variable values aren’t persistent and using memory by default and best for users because they can get that functionality, but, more likely, the in-between functionality of just having particular variables persist while others continue to be zeroed in a new session.
Not sure because I can’t always associate user names here with email addresses through the contact form. I usually answer same day so if you are not getting through, send a private message using the Forum.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
