Support Board
Date/Time: Sat, 21 Dec 2024 17:42:58 +0000
VbP: Include Prior Profile Common Price Volume
View Count: 2051
| [2015-03-28 20:38:47] |
| i960 - Posts: 360 |
|
Include Prior Profile Common Price Volume
When this Input setting is set to Yes, volume from the prior Volume Profile at common prices is included in the Volume Profile that follows it. What does this do? I was hoping that it would include common price volume from previous profiles so that I could include the preceding session volume into the existing session volume but I cannot discern any change when using this setting with "from session start to end", "multiple profiles fixed by time", or "multiple profiles fixed by bar count". With the configurations I've tried, it doesn't appear to do anything. I also just did a general search of it in google and the support board search and found no previous mention to this study setting anywhere other than the documentation itself. Also, I'm not trying to spam you guys with these recent threads, I'm just posting topics based on notes I've taken while using SC based on things I noticed as problematic. I'm truly trying to make the software better, not just be a pest. :-) Date Time Of Last Edit: 2015-03-28 20:39:52
|
| [2015-03-28 20:41:04] |
| |
|
This is definitely not something we will provide support for. It was developed for a user.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2015-03-28 20:41:20
|
| [2015-03-28 21:08:35] |
| i960 - Posts: 360 |
|
It's provided in the software for everyone to use so it's highly arguable it should be supported as a normal feature like anything else or removed entirely from the interface and documentation. I will most likely not be the first person who ends up asking you about this thing not working - so why not just support it, make it work as it says and everyone avoids that inevitable situation down the road of other people not understanding it and SC becomes even more solid? |
| [2015-03-28 21:24:23] |
| |
|
We have tested it and we can see that it indeed does nothing. And we think we know why. We have to add support for it back again. And this is precisely the detriment of us doing custom specialized programming for users, because then as we maintain the software and make changes, the feature has to be maintained. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2015-03-28 21:24:54
|
| [2015-03-28 21:39:48] |
| i960 - Posts: 360 |
|
Hey, I'm a developer as well, I know how it is and I know how crap rolls down hill (for instance, I completely agree with your long writeup on why object code based plugins for interfacing with various trade services is a terrible design and they should be using FIX, DTC, or basically anything that communicates via a socket) - but at the same time I know that when we agree to provide something for someone, and said feature becomes publicly available, the dev basically has to own it at that point, unfortunately. If a custom programming effort for someone ended up making sense for everyone else, it's only natural that it becomes a standard feature at that point. If it ends up being a one-off crappy thing of little value to the masses, then yes, it's perfectly reasonable it gets ripped out. Anyways, I'm not trying to give you a hard time explicitly. I thought the feature sounded pretty valuable and that's why I tried to use it. I really like SC and am interested in helping make it as robust and powerful (but not necessarily full of useless features) charting/trading platform as possible. This is the headspace where my suggestions are coming from. |
| [2015-03-29 22:37:27] |
| i960 - Posts: 360 |
|
I've thought about this more and experimented with various overlaid VbP studies - and I think what really is of value here is not necessarily including the previous profile as a binary option but the general aspect of "period" vs "frequency" in the general VbP settings. On top of that, start and end (period) could have the concept of where start actually is and if it's an absolute window vs a moving/shifting window. Default for frequency could be 0 which is a sentinel value for "same as period" as it functions now. Examples: Period: 7 day Frequency: 1 day Window: Absolute The above would plot a 7 day VbP at daily boundaries taking into account the entire cumulative period, essentially showing a weekly VbP being built up each day (with the 1st day starting at zero). Period: 7 day Frequency: 1 day Window: Moving The above would plot a 7 day VbP at daily boundaries but the 7 days is 7 days of cumulative volume from the point of plot and back, not 7 absolute days from the beginning of the period (which could be totally empty if it just started). As each day progresses the new 7 day VbP will plot, but will consider 7 days back rather than something being built up over 7 days. This is a rolling 7 day VbP plotted daily. Period: 2 day Frequency: 1 day Window: Moving The above is the same as the previous example, but the rolling window is 2 days. This accomplishes the same goal as "include prior profile" as does anything else using a rolling window type. The ability to plot VbPs of a given period on a different frequency from the period itself *and* also have the ability to calculate cumulative volume on a rolling period rather than an absolute period would be a pretty kick ass feature as it would take into account previous period volumes. This is similar to how the last days highs and lows are relevant to the current day. Right now, at the end of a period, one can do something *similar* by looking at the previous period's VbP and marking in the future where a given area of interest may be - but the new period they're operating with will be entirely empty at the beginning meaning in most cases the previous profile will end up having to be consulted anyway just to figure out potentially where things may go. Visible bars is already automatically doing a lot of what I'm describing but it's entirely dependent on what is visible and cannot show change over time (frequency of when the period is plotted) because it takes into account everything that's viewable. Frequency and window type are the additional dimensions here. Date Time Of Last Edit: 2015-03-29 22:39:40
|
| [2015-03-30 08:56:22] |
| |
|
A question about post #7, do you require the Include Prior Profile Common Price Volume feature? Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2015-03-30 09:50:32] |
| |
|
In any case, the user who this was developed for, instructed us to remove this feature so it will not be put back.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2015-03-30 20:03:14] |
| i960 - Posts: 360 |
|
I don't get it - we're all describing to you highly useful functionality and you're attempting to justify reasons to remove it. The users here are doing sane idea generation and putting time in to describe functionality and thoughts and simply ignoring them outright is just plain rude - particularly as we are paying for this product. If you cannot handle the development workload, hire more people. |
To post a message in this thread, you need to log in with your Sierra Chart account: