Hey Doug,
Unless you were using Kino's original PipsToRibbons indicator on every chart, you won't really see much improvement in RAM & CPU usage by using my mod of Padnoter's indie.
The real advantage of the mod comes into play when another indi or an EA needs to know where a particular ribbon's MA's are (price-wise) in relation to other ribbons, or market price, as they can just look at the GV's instead of using iCustom calls, as each time you use iCustom, it loads the T3MA with the required parameters, T3MA does the calculations, then unloads from memory again, which can cause quite a bit of lag (this is how Padnoter's indie works anyway, but why do it with every other indie/EA as well?).
The disadvantage is that it has no historical information that other indies can use, so they can't tell if a ribbon is expanding or contracting, moving closer to or further away from another ribbon, or whether price is moving towards or away from any ribbon... There is a (partial) solution to that, though...
Any indie or EA that requires historical information will have to have a pair of arrays for each ribbon... At the close of each bar, it can pull the prices for both MA's for each ribbon from the GV's, and store them in the arrays, for as far back as required, for whatever analysis is desired.
I say it's a partial solution because it will take a while to populate the arrays that way, and that info is lost when you change chart timeframes, or restart Empty4
Thinking this through as I'm typing here...
If we have such an indie, it will initially have to populate its arrays by...
1. Waiting for a new bar, (or, at least, ensuring there won't be a new bar whilst we're populating our arrays).
2. Calling the T3MA indie with the correct parameters for each MA of each ribbon, from shift 1, as far back as required.
3. Complete any other initialization processes.
Once initialization is complete, we are then free to collect data from the GV's at the close of each bar.
I think that just about covers it
Have fun!
Radar =8^)