All GomRecorder Indicators

[Flyingscots]

So far so good! I'll test it longer tomorrow. Thanks a lot again.

I'll wait for your PVP; I'm sure it will be great if you decide to make it.

[Flyingscots]

Hi Gomi, I think I can say that GomVolumeProfile works now.
Thanks again and I'll be waiting for your PVP.

[gomifromparis]

Well guess Ninja's own VolumeProfile indicator is flawed then because I had only rewrapped some GomRecorder stuff around it.

[danjurgens]

NT 7 and loss of 1st tick of a new bar.

When using GomDeltaVolume indicator I noticed that the delta of the bars usually differed slightly from what I saw in investor RT's VB indicator (live data). Both are using IQFeed data. I tracked the issue down to the 1st tick of the new bars GomOnMarketData being called before GomOnBarUpdate. I worked around it by storing the last delta and volume in GomOnMarketUpdate and reinitializing totalvolume and deltavolume to those values when a new bar forms.
I just started using NT and only use NT7, so I assume isn't desired behavior for NT6.5. I've attached the modified indicator below. If this isn't right for NT6.5 I'm sure an #if could be used to make it compatible.


Now to figure out why the values of the indicators change when I reload the chart and it reads back from the file!

[gomifromparis]

Thanks for that. I'm pretty sure in NT 6.5 OnMarketUpdate fires after OnBarUpdate.

[danjurgens]

No thank you!

No problem. I really appreciate what you've created and shared here, without you NT wouldn't be suitable for my use!

I'm interested in getting longer term volume profiles based on minute data due the difficulty of obtaining long term tick data and the space it requires.

I'm planning to look into expanding your suite of indicators to accept minute data and break it down into "ticks" with the volume in the minute bar spread equally over range of the bar. You lose delta capabilities, but the VP would still be accurate. Maybe there is something that already does what I want, so I'll do some investigating before I really go to town. Or just handle that breakdown in "preproduction" by creating gom file with the minutes split into fake ticks.

Anyway, thanks again!

[aviat72]

Now to figure out why the values of the indicators change when I reload the chart and it reads back from the file!

It may have to do with the resolution which NT provides (1 second) and that in many instruments, there can be multiple bars in a second using tick or volume charts. When you reload all the volume for that second goes to the first bar and the other bars get nothing.


gomi: There is a big thread on BigMike's about this change in NT7 where OnMarketData() triggers prior to OnBarUpdate(); I actually like that if you are primarily work on tick based data. Also FirstTickOfBar is tied to OnBarUpdate() only and its value should not be relied on in the OnMarketData() call.

[danjurgens]

Thanks for the info. Quite likely the 1 second "fuzz" is causing a bit of volume rearranging. That explains why the per bar values disagree with other sources but the cumulative delta seems to match.

[LuboLabo]

No problem. I really appreciate what you've created and shared here, without you NT wouldn't be suitable for my use!

I'm interested in getting longer term volume profiles based on minute data due the difficulty of obtaining long term tick data and the space it requires.

I'm planning to look into expanding your suite of indicators to accept minute data and break it down into "ticks" with the volume in the minute bar spread equally over range of the bar. You lose delta capabilities, but the VP would still be accurate. Maybe there is something that already does what I want, so I'll do some investigating before I really go to town. Or just handle that breakdown in "preproduction" by creating gom file with the minutes split into fake ticks.

Anyway, thanks again!

Have u look to the dValueArea indicator, may u could re-arrange it with Add(PeriodType.Minute, 1), and to add the choise for multimple days histogram since now works only intraday.

[gomifromparis]

When you reload all the volume for that second goes to the first bar and the other bars get nothing.

If you wathc carefully a 1 tick chart you will see this is not really the case. But the tick splitting on the bars of same timestamp could be improved.

gomi: There is a big thread on BigMike's about this change in NT7 where OnMarketData() triggers prior to OnBarUpdate(); I actually like that if you are primarily work on tick based data. Also FirstTickOfBar is tied to OnBarUpdate() only and its value should not be relied on in the OnMarketData() call.

Yes, I like the fact that now OMD fires before OBU so when you're in OnBarUpdate you have the OMD info that triggered it.

This is more logical, and now you can keep your repaint code in OnBarUpdate and don't have to put in OnMarketData.

Drawback is that you have to move your bar reinit code in OnMarketData, thus putting Bar logic in OnMarketData....

And of course all the indicator that reinit stuff in OnBarUpdate have to be rewritten....

[gomifromparis]

After a few tests, this is going to be a PITA because OMD fires before OBU which is cool, but in the case of the first tick of a new bar CurrentBar hasn't the correct value in OMD, so you can't simply put your if CurrentBar>lastBar in OMD, it won't work...

So guess will have to do some danjurgens hacking, storing ticks and taking them out in case of a new bar...

[RJay]

If you wathc carefully a 1 tick chart you will see this is not really the case. But the tick splitting on the bars of same timestamp could be improved.


Yes, I like the fact that now OMD fires before OBU so when you're in OnBarUpdate you have the OMD info that triggered it.

This is more logical, and now you can keep your repaint code in OnBarUpdate and don't have to put in OnMarketData.

Drawback is that you have to move your bar reinit code in OnMarketData, thus putting Bar logic in OnMarketData....

And of course all the indicator that reinit stuff in OnBarUpdate have to be rewritten....

Hi Gomi,

I'm the one who uncovered the FirstTickOf Bar problem. I have an OCD issue when it comes to accuracy.

I have updated GomCD with a fix for the non cumulative mode which has the "problem". Cumulative mode is working fine and needs no adjustment.

Here are the proposed changes in Bold.

-------------------------------------------------------------------------------------------------------------------------

Define Variable in variable area - protected int lastdelta = 0;


DeltaValue.Set(dsClose.Get(CurrentBar));

if (startbar==-1)
startbar=CurrentBar;

lastcalcbar=CurrentBar;

if ((chart==GomCDChartType.NonCumulativeChart)&&(Firs tTickOfBar)&&(!Historical))totalvolume += lastdelta; //---added----
}


//void ProcessDelta(int delta, bool firstTick)
protected override void GomOnMarketData(TickTypeEnum tickType,double price,int volume,bool firstTickOfBar)
{

lastdelta = delta=CalcDelta(tickType,price,volume); //--------------- NT Fix for 1st Tick Being Dropped ----

int delta=CalcDelta(tickType,price,volume);

totalvolume += delta;

--------------------------------------------------------------------------------------------------------------------------------

It could probably be done better. I have tested this and it works great for me!!!

If it works for you, I leave it to you to release an updated GomCD.

RJay

[gomifromparis]

Nice find of yours, RJay, well done !

I'll take a look at your patch, but I'll try first to modify the recorder so I don't have to mod all my indies.

Thanks again.

[RJay]

Gomi,

As I have said in my prior post, I am am accuracy nut.

I have been studying the GomRecorderIndicator and I would like to propose a change.

The following code seems a bit dodgy for me.

-----------------------------------------------------------------------------------------------------------------------------
if (ask<bid) // should not happen but does
{
if (price<ask) tickType=TickTypeEnum.BelowBid;
else if (price==ask) tickType=TickTypeEnum.AtAsk;
else if (price<bid) tickType=TickTypeEnum.BetweenBidAsk;
else if (price==bid) tickType=TickTypeEnum.AtBid;
else tickType=TickTypeEnum.AboveAsk;
}
else if (bid<ask) //normal case
{
if (price<bid) tickType=TickTypeEnum.BelowBid;
else if (price==bid) tickType=TickTypeEnum.AtBid;
else if (price<ask) tickType=TickTypeEnum.BetweenBidAsk;
else if (price==ask) tickType=TickTypeEnum.AtAsk;
else tickType=TickTypeEnum.AboveAsk;
}
else //bid==ask, should not happen
{
if (price<bid) tickType=TickTypeEnum.BelowBid;
else if (price>ask) tickType=TickTypeEnum.AboveAsk;
else tickType=tickType=TickTypeEnum.BetweenBidAsk;
}

---------------------------------------------------------------------------------------------------------

I propose it be replaced with this simpler, more clearly defined code.

With this proposed change, every tick gets counted. No "cracks" in the code for ticks to "slip through".

Any tick that can't be defined gets stuffed "Between" where it can still be counted.

----------------------------------------------------------------------------------------------------------

if ((price<bid)&& (bid != 0)) tickType=TickTypeEnum.BelowBid;
else if ((price==bid)&& (bid != 0)) tickType=TickTypeEnum.AtBid;
else if ((price==ask)&& (ask != 0)) tickType=TickTypeEnum.AtAsk;
else if ((price>ask)&& (ask != 0)) tickType=TickTypeEnum.AboveAsk;
else tickType=TickTypeEnum.BetweenBidAsk;

-----------------------------------------------------------------------------------------------------------

Also,the following change will also be needed if the previous one is implemented.

Replaced commented line with the one following:

-------------------------------------------------------------------------------------

// if (!initBidAsk)initBidAsk=(ask>bid);
if (!initBidAsk)initBidAsk = true;

------------------------------------------------------------------------------------

I have tested this and it works quite well for me.

Again, your indicator, your call, I leave it up to you.

Love your stuff,

RJay

[gomifromparis]

Well basically the code you propose is the same as my if (bid < ask) part.
If bid==ask all your volume will be counted on the bid side.
If ask<bid and price between bid and ask all the volume will be counted on the bid side,even if it's actually between the bid and the ask.

Sorry, all problems don't have simple solutions :-)

PS : please point out where the ticks might "escape" or "slip through" ?