Thanks for the feedback bro. You are right about this. I was wrong in getting the buffer data from Gadi_NormalizedVolume indicator. At new codes (version 03), i am using the snippet code from yours, comparing all blue, red, and white histogram, and get the biggest. Thanks for that.  

Thanks G, will try it next week, and will see simplex’s idea on how to code based on session. Thanks @simplex too. 

Vlan:

Look here for my newest blueprint – might save you some time to manage that session averaging.

It’s still a prototype! If you find bugs I’d appreciate if you notified me.

Have fun!

s.

Ok,

Following G’s repeated proposal (thanks for that!) of averaging volume per session, I now attach a first simple prototype of that kind.

For now no gimmicks, no normalization (except for time), no oscillator. Unit shown is ticks per second, bars colour coded in a simple manner for up / down.

By default, session averages are being calculated…[Read more]

Thanks for your feedback!

Yes:

I do understand your assumption, but I just don’t believe that it’s true and I also don’t believe that ‘this was shown before’, as you’re stating.

So for your formulas: uppath / totalpath would be kind of a ‘bar efficiency’, equal bodySize / barRange. Correct?

s.

@Anti:

Could you provide some conceptual background about this special part of the algorithm:

if (Close>Open)
buff=((High-Low)*MathPow(2*High-2*Low+Open-Close,-1))*iVolume(NULL,0,i);
else if (Close<Open)
buff=((High-Open+Close-Low)*MathPow(2*High-2*Low-Open+Close,-1))*iVolume(NULL,0,i);
else
buff=iVolume(NULL,0,i)/2;


s.

Great:

But could you anyway try on your old laptop and report here? Would save me the trouble to grab some age-old laptop, install MT on it and check for myself!

s.

Yes:

That’s probably the case. I only wanted to provide an example of how the indicator looks like when no ticks are coming in.

s.

Ok, and now for the indicator.

I still consider this one experimental, a prototype and possible basis for further intrabar development.

@Anti: you wrote that you’re working on some weak laptop at the moment. So your feedback about ressource consumption would be highly appreciated. On my XEON system CPU consumption lines hardly move when I launch…[Read more]

Yep, I watched in my new magnifying lens I coded last night (see pics):

Pic 1: normal activity. I chose AUDJPY for this example for minor influence by EUR and USD news G. mentioned.
Pic 2: during the event I had a phase of more than 1 minute with no ticks coming in (broker GP)
Pic 3: ticks are coming in again
Pic 4: up to 800 points per…[Read more]

Yep, I watched in my new magnifying lens I coded last night (see pics):

Pic 1: normal activity. I chose AUDJPY for this example for minor influence by EUR and USD news G. mentioned.
Pic 2: during the event I had a phase of more than 1 minute with no ticks coming in (broker GP)
Pic 3: ticks are coming in again
Pic 4: up to 800 points per…[Read more]

So, here it is, quick and dirty version. I added other feature too beside alert. I will look at it next week if there is bugs. Please try it.
And many thanks for your congratulations @blueface.

Will try today mate, because my niece will marry tomorrow, so tomorrow to Sunday will be busy days for me.

Good point:

I also thought about such a delay for my analysis. Hopefully I will have time for that during next weekend.

s.

An interval of only 1 or 2 ticks would certainly be too short:

I think what G. mentioned above meant 1 or 2 shortest of the time intervals from my latest proposal: 4 … 8 seconds.

s.

An interval of only 1 or 2 ticks would certainly be too short:

I think what G. mentioned above meant 1 or 2 shortest of my time intervals mentioned: 4 … 8 seconds.

s.

G:

Ok, got it – thanks!

Only counting, no weighing with strength of price movement, I assume.

s.

Ok:

I assume you’re talking about direction of price?

That would make the coding task simpler and reduce CPU ressource consumption. I already assumed that the shortest (i.e. most recent) time intervals would make the greatest impact.

s.

Ok, here we go.

Please remember that this is a preliminary and purely experimental indicator – to be continued and extended (hopefully!).

All we have now is plain volume (in ticks per minute) and an average, in particular my version of an FIR filter based on John F. Ehlers’ publications. At the moment, the details of this filter are not…[Read more]