I'm running out of global variables, but need quite a few more - maybe 20

I'm afraid my programming style isn't very sophisticated, so I've used up nearly all the globals.  I suppose if I had used the globals bitwise (testing for bits set or not set in a global) I  wouldn't have the problem.

But now I'm wondering if there's any way to have more globals available.  Or maybe there's some technique for storing the globals externally (external to MT), and then retrieving them.

It would look something like this:

•  Store the cutoff value of a filter in 'ga'   (this is iteration 1 of 'ga')
•  Use it when as I normally do.
•  If I need another variable, say, to store the q of that filter (but don't have any more       variables available) Do the following:
•        -  Store 'ga' externally (don't know how I would do that)
•        -  In MT, overwrite iteration 1 of 'ga' with the filter q value (this is iteration 2 of 'ga)
•        -  Use this iteration 2 of 'ga' any time I'm working with the q value
•        -  If I want to work with the cutoff value again, do the following:
•                 - Store the q value externally in an unused location.
•                 - Retrieve the cutoff value, storing it in a 'ga'
•                 -  Use this as a starting point for any changes i want to make to the cutoff.

I'm not sure if this is ridiculous, or if there's another - simpler - solution.

Well, now that I've written it out, I see it might be possible to do this in MT entirely, using the same scheme.  But in any case, I'd sure like a better way of doing it.

Thanks,

Gabriel

Funny you should ask, I was mentioning a similar strategy to Florian just the other day. Unfortunately there is currently no way to create additional global variables. In my calculations you have 360 global variables at your disposal. Each one of these is a 32 bit signed integer so you have 11520 bits of global space.

The first strategy of course is to use local variables whenever possible. There are 20 available for each incoming event. If your project needs more global space you will need to revert to some bitmapping strategy. This is what I did in a recent project where I wanted to control state of 120 buttons which with bitmapping only took 4 global variable space (with some bits left over).  If you want to map rgb for a given led, you can store 10 led states into a single global variable.

I would be interested in looking at your project to see why you require so many global variables. I have some pretty complex project and with the strategies discussed have never run out of global variable space.

With that said,  if you project is really complex, maybe you should break it up into two projects. You can call one project file from within a different project file so as long as you do not have to share variables between the two projects, you should be OK. Each project, of course would have its own global variable space. This is similar to the the “Chain” command in the old 8 bit days (remember BASIC)?

If you would like, you can post your project and maybe I can make some recommendations.

Steve
bome@sniz.biz
Independent Bome Programming Specialist
Bome Q&A moderator

Hi Steve,

As usual, your answer has made me think hard about my methods.  This time it led me to consider other ways to decide when to turn my APC Mini LEDs on or off.

I now have seven APC Minis, each of which controls 3 tracks in Live.  In each track, I have 11 effects.  In order to know what’s going on at any one time, I need to know whether or not an effect is currently active for each track.  I do this by turning on (of off) an LED.

This attached photo should help explain:

In this photo, Track 2 is being sent to a delay, so I indicate this by turning on the LED for the Column 4/Row 6 button.  Note that the fader for column 4 is just controlling the amplitude of the audio being sent through track 2.  It doesn’t have anything to do with the delay send.

Since I’m using endless encoders (on my Novation keyboards) to attenuate the signal being sent to the delay, I can’t tell if the the signal is totally attenuated (off) or is on (in any amount).  If I had used faders or potentiometers, I’d either have to have a separate fader for the delay send for each track, or put up with a jump when I try to control the delay send of another track.  There are ways to get around this jump, like “pick up” or “value scaling” takeover modes in Live, but I haven’t had much luck fitting them to my purpose, so I use encoders instead.

In order to determine when I have turned off the delay send for a track, I devote an MT global to act as a counter.  Each tick “upward” increments the counter.  Downward ticks decrement the counter.  When a counter reaches zero, I don’t allow the counter to be decremented any further.  When it reaches a certain top limit, I don’t allow it to be incremented any more.  Now I can tell when my send is on or off.

Displaying the state of eleven effects for twenty-0ne tracks requires 231 globals.  This is a bit of an exaggeration because some of the parameters are controlled by faders or merely by switches, but still, the number globals required is pretty high.

So I knew that this is where I should be looking for a way to change my method…. and I found a way.  Live sends a midi message when an effect is turned on of off.  I was pretty dumb not to take advantage of this.

So what I have tested is just to monitor the messages being sent to MT from Live.  When I receive a message that a certain effect has been turned on or off, or that a send for an effect has been turned on or off, I turn the relevant LED on or off.

This will certainly make available more globals than I need!  So I need to thank you for getting me to rethink what I’ve been doing.

As usual…. thanks for your clear insights.

Gabriel

 

Glad you figured it out! Yes Ableton sends back messages and you can leverage these for updating your LED’s as you stated. I use this technique sometimes for keeping MT Pro in sync with Ableton Live. For example, state of solo when using Ableton instead of external controller to change it.

Another thought came to me after I posted my answer. Did you know that if you have two translators monitoring the same event, that these variables are shared between the two translators? Maybe not relevant for this situation and I have not leveraged this knowledge yet in any of my projects but maybe the situation will come up some day and allow me to use local variables to communicate among translators monitoring for the same event. Bottom line is that local variables are local per event, not per translator.

Thanks for sharing your solution!

Steve

Another thought, although your solution is probably better. If Ableton did not send this information back to MT pro, you could still use a bitmap to control 4 LED;s with one global variable, thereby increasing the available variable space. This assumes you are only using values of 0-127 (or even 255) for each counter. If you ever need help with this, just come back and ask. It takes a little planning to set up but once it is set up, it really isn’t too bad.

Steve

Ideas keep coming. If you have multiple instances enabled in MT pro, you could also set up a method to pass variables from one instance to the other with Sysex or similar.
Instance 1 sends Sysex with a header indicating save set number, start and stream of variables.

Instance 2 takes these keeps them storied within its instance.
Another Sysex request them back later for retrieval.

I haven’t worked up any specific examples but something like that could work.

I’m glad your ideas kept coming. In fact, I think I like your idea of running two instances of MT. This would probably be easier than rewriting my code to use Live’s feedback instead of creating counters in MT.
This is especially true because I’m running two instances of Live. Instance 1 hosts all my clips plus effects. Instance 2 hosts Nerve (the drum machine vst by XferRecords) and also a few effects.
The two instances of Live are kept in sync using the new Link utility, but are otherwise independent. Well… not quite. They do share a few global variables, but the intent is to keep track of which instance of Live is currently being displayed and also to decide which instance should receive midi from my controllers.
Much earlier in the development of my MT code and Live sets, I did run two instances of MT. Then, I found that I was able to do it all within one instance, so I merged the two. But now, I believe I’ll try splitting the MT code again. Might be just the perfect answer.
Hats off to you, Steve.
Thanks,
Gabriel

Glad to help, Gabriel!

Uh oh…. I hit a speed bump. Though I previously was able to launch two instances of MT, now I can’t remember how I did it. When I try to launch the second instance, nothing happens. Can you remind me how it’s done?
Thanks,
Gabriel

Ahhh…. now I remember. Well, actually it took looking at the read only forum to jog my memory. Make a copy of the MT executable and name it differently.
Now to see if I can make it work…. assign Virtual ports correctly etc.
Gabriel

Actually you can go to settings and uncheck “only one instance”. Then double click on
another bmtp file and the second one will open in a new instance.

Sorry for the late reply. Wasn’t monitoring for a while.
Steve

10 local variable available not 20. That was a typo
oo, pp, qq, rr, ss, tt, uu, vv, ww, xx

This posting about 10 vs 20 local variables showed up in my inbox and it made me look at the previous post where you mentioned calling one MT project file from another. I’m not sure what this implies, or if it’s different from passing variables between two instances of MT using LoopBe. Can I actually just call the second instance and ask for a variable?
Gabriel

I doubt if there is sharing of variables (global or local) between multiple instances running of MT Pro.

So if you have a global variable ga on instance 1 and also on instance 2, they should both be different, however you could certainly take the value of ga on instance 1 and pass it to instance 2 via LoopBE. In instance 2 you could either assign the value to ga or any other variable you desire in instance 2.

I haven’t explicitly testing this but I think since many times when I do projects for others, I run 2 instances of MT pro, one emulating the clients controller cause I can’t buy everything and the other instance running the instance of the project I’m developing.

I’ve never run into collision of variables across the instances running.

OK Steve… just checking. I’ve been using two instances of MT for a while now, using LoopBe to pass variables back and forth. What you said made me think there might be a simpler way. LoopBe works, it’s just a bit clunky to do it this way.