Multicharts -features, stability, reliability and speed  [SOLVED]

Questions about MultiCharts and user contributed studies.
User avatar
bensat
Posts: 331
Joined: 04 Oct 2014
Has thanked: 46 times
Been thanked: 104 times

Multicharts -features, stability, reliability and speed

Postby bensat » 08 Nov 2014

I don't want to hijack another thread and I just want to say what I'm writing in the following is not personal against anyone here.

I saw another feature request today. Again, A FEATURE REQUEST. Every day, A FEATURE REQUEST.

It is just one example for many oithers: http://www.multicharts.com/discussion/v ... =1&t=46530

In my opinion, what can't be reproduced anytime back with the same results is just synthetic and not reliable enough for trading or/and at least serious testing. It is just looking for the some success in the clouds. Has anyone seen any successful trader, team, HF etc saying he's only successful because his synthetic open is at 5, 10 or 15 only ? Is this feature for making you better trading or just for feeling better ? If your market does not open at 05, 10 or 15 just go back to bed. If you can't reproduce your trading systematics every day with openings at 89, 33 & 54, just stop trading it. If you already said (yes, in this forum !!!!) MC is already much overloaded and way to heavy, please don't call for new future implementations anymore.

I'm 6 weeks back to MC and in most cases I really like it. But what I saw and see on feature requests here makes me scared and worried about the future, while basics in this trading/analysis software are still buggy and/or still not working. I had to work on importing old studies and functions for one week. ONE WEEK. The hole construction of the database is a mess. Many complaints about adjusting and exporting data, splits, dividends etc confirm my observations. Own data can not be imported and being used for our own analysis. Why I have to move to R, Python etc (without paying for and open source !!!!) to get this done. The testing environment is not good enough at all and produces incorrect or different results often and many times. Plotting, seriously just plotting 20 bid/ask levels for 1h in 1 tick chart in the ES with some calculations and color coding forces MC to die. Code reviewed, optimized. Just impossible. DOM can't be placed and fixed in a workspaces without staying on top of the hole screen. I could call much more basics which should work but aren't.

But many guys here in the forum are still going for features, features and features. Some want MC should develop monitoring tools. Same people are talking about cheap monitoring tools in the web, because they can't afford "more professional" tools. What are we talking about when you want to trade 24/7 Forex markets mechanically? I could repeat many ..... of this.

I'm already tired. Wherever I worked in highly professional trading environments, stability, reliability and speed for the basics came first. Than and only than, feature stuff. I understand TSSupport's strategy stay's more for richness of features to compete with the market.

Please guys don't push for features which are just for your goooooood feeeeeelings.

Now you can push me from left to right and hit me verbally ;) or the forum admins just delete my thread. That's fine.

Have a nice weekend with all my regards.

Ben

hilbert
Posts: 224
Joined: 17 Aug 2011
Has thanked: 76 times
Been thanked: 64 times

Re: Multicharts -features, stability, reliability and speed

Postby hilbert » 08 Nov 2014

Great points in general bensat. You used 4 keywords in this thread title. Let me analyze them.

Stability: MC is ok as far as stability is concerned. Software doesn't crashes during live markets, unless you super-load the software with 100s of charts etc. However, with every release, we have had stability issues like last time, MC was hanging when strategy parameters were changed with performance report open. There have been persistent memory leaks etc etc. But MC Team is pretty good and they fix these stability issues soon. I give them a 9 out of 10 here, given their limited resources. They are not a big IT company.

Reliability/Consistency: MC needs to improve at multiple levels on reliability front.
Some aspects of backtesting work differently compared to real-time trading, which often work little differently than autotrading. Examples SetExitonClose works during backtesting, but needs workarounds in other situations. Many other examples where if a customer doesn't have a deep understanding of MC, or has not done sufficient testing, can lead to surprises/errors/misunderstandings simply because is software is not completely consistent. However, they have a great wiki, great support and a working PM system (though it can be improved). Also, designing a trading software is a fairly complicated endeavor and most other software have these limitations. I give MC a 7 out of 10 on this parameter.

Speed MC is like an octopus, it does a lot of things. It is a first class charting application, it supports autotrading. It supports WFO, Optimization, 3D display, Scanner, CVD, whole lots of drawings etc etc. Compared to a trading software being used by a niche trading group; MC has a vast customer base with wide variety of trading needs or good to have needs which necessarily doesn't mean greater trading profits (as bensat says). So, there is huge demand of different features. Net result is that the code becomes bloated, and remember MC has to support easylanguage, so it is not the fastest or the most flexible toy in the market. Accepted!

However, there are benefits of having such a large and varied customer base: such a large base of customers allow us to get MC for around 1500$. MC is quite a good software: it is broker/data-feed independent, supports portfolio autotrading. Pretty good stuff. Anyways, I give it 8 out of 10 in speed, but I think it is ok. No one should try to do HFT with MC. It is not meant for that.

Features: A large customer base demands a large number of features. This has both advantages and disadvantages. Compare MC clients to a small prop group. Just by reading the forums, one can get exposed to so many different trading styles, which one might not get exposed to in a small tight-knit prop group, which does only pairs trading (for example). I think adding different kinds of features is good in general, with a keen eye on above points. I give them 9 out of 10 here.

One more post to follow.....
Last edited by hilbert on 08 Nov 2014, edited 1 time in total.

hilbert
Posts: 224
Joined: 17 Aug 2011
Has thanked: 76 times
Been thanked: 64 times

Re: Multicharts -features, stability, reliability and speed

Postby hilbert » 08 Nov 2014

After analyzing the keywords in thread's title, I will write what I think ben was referring to, though a little subtly.

Basically, ben is saying that we need to differentiate between Core Features that MC must have and non-core features. One example of non-core feature that comes to my mind is "custom bar type", adding more drawing tools, changing settings of drawing tools etc. etc.

Example of core features that MUST work solidly in MC are

1) Data Management - Tick data is very costly, if we as users can consistently collect tick data using MC, it will be a great thing. I think a great move in this direction was when MC allowed collection of tick data without plotting charts using QM. Next small but worthwhile step was when Reload of missing data was allowed automatically, for symbols plotted on chart. Final step in this direction would be to allow automatic reload of missing data for all the symbols that are in QM for which data is being collected without plotting.
https://www.multicharts.com/pm/viewissu ... no=MC-1017
Finally, we don't want to be tied to QMD data only. If we want to run some code in MATLAB, we should have access to data stored in MC easily. So, export of multiple symbols together in ASCII format from MC is a core functionality that should get added.
https://www.multicharts.com/pm/viewissu ... no=MC-1553

2) Handling stock-splits and dividends in database. Well this is also a core functionality. I never understood why this has not been implemented yet. Maybe because it was very hard to trade on a large number of symbols using MC before. But now with scanner and Portfolio trader available, this is something that should get priority.

3) After good data, we come to strategy backtesting and real time trading. Core features that should get implemented are better order management capabilities in powerlanguage, removal of limitations like being not able to use open next bar with data2 series/IOG, SetExitonClose limitation, improvement of powerlanguage editor, maxbarsback setting allowed access from within powerlanguage, access to strategy performance report data from within powerlanguage etc.

4) Core features of autotrading are access to OPT from power language. Also, access to QM logs from within powerlanguage will be very helpful. I want to complement MC on the improvements made in the autotrading front. MC has come a long way compared to 3 years ago or so in autotrading. Great Job!!

5) Finally portfolio trader is a good start but these features are absolutely must: Bar Magnifier, extended series for portfolio trader, IOG etc etc.

I would give a semi-radical suggestion. I suggest that MC team stops working on enhancing ANY new (non-core) features for 6-9 months. Rather they completely focus on making MC a more solid platform, by focusing and working on only CORE features.

I reckon that if MC is able to sort out even 50-60% of the issues mentioned above over the next 6-9 months, it will rise way above any competition in retail trading software market. I own MC, I have invested thousands of hours in MC as a user, and I want this software to become rock-solid in performance, stability, reliability and features as well. :)
Last edited by hilbert on 09 Nov 2014, edited 1 time in total.

hilbert
Posts: 224
Joined: 17 Aug 2011
Has thanked: 76 times
Been thanked: 64 times

Re: Multicharts -features, stability, reliability and speed

Postby hilbert » 08 Nov 2014

Also, want to thanks Multicharts for having so many good rather great Great features:
1) Exchanges and ECNs from around the world
2) Nice ability to create custom futures
3) Roll-over dates, session settings...good.
4) Nice DOM
5) So many bartypes
6) Access to levels in depth of market from powerlanguage
7) 64 bit version, .NET version, multi-threading....very nice

Pretty impressive list!! Another core set of improvements that I missed in my last post are better PL editor and some architectural changes: breakpoints, subroutines, if possible get methods into powerlanguage. Challenge would be to incorporate these changes while maintaining compatibility with Easylanguage. All the best MC Team!

User avatar
arnie
Posts: 1594
Joined: 11 Feb 2009
Location: Portugal
Has thanked: 481 times
Been thanked: 514 times

Re: Multicharts -features, stability, reliability and speed

Postby arnie » 09 Nov 2014

But hilbert, what is core for you might not be core for me.

There'll be always a gap between what an algo and a discretionary trader needs.
Most of the things mentioned as core are useless for my needs. But I understand how important they are for algo traders.

It was not very elegant of you to create a core and a non-core list of features.
We all have our features requests and despite PM became worthless at this point with so many requests, each needs to be respected even if we don't appreciate it.


Gooooood feeeeelings? Really?
Geez...

evdl
Posts: 401
Joined: 19 Jan 2011
Location: Netherlands
Has thanked: 85 times
Been thanked: 124 times

Re: Multicharts -features, stability, reliability and speed

Postby evdl » 09 Nov 2014

Agree with Hilbert on the core functionalities of MC. Data is the basis of everything, and how to place a trade and keep track of it, is in my book core functionality. To add another radical idea:

With in mind, that I work with MC almost 4 years and invested 1000's of hours getting to know and use the software and contribute to the development of the software by reporting bugs and ideas as several other users on this forum.

Here comes the radical: for me the most important is continuity (because of the time invested) I want MC to be the best software tool for trading for the retail clients. So if it will benefit the development of MC and the speed of implementation of core functionalities, I suggest a subscription fee per month of the magnitude of two or three round trips of a trade.

The extra income for MC can be used for hiring extra programmers to speed up the implementation of extra stability and core functions. Get rid of limited resources. If you are serious about trading, it will pay back the extra investment within day's. Maybe we can vote on this one, ofcourse with the promise from MC to invest the extra income to speed up development. (not to say that the development is slow, but you know what I mean)

User avatar
MAtricks
Posts: 789
Joined: 09 Apr 2012
Has thanked: 286 times
Been thanked: 288 times

Re: Multicharts -features, stability, reliability and speed

Postby MAtricks » 09 Nov 2014

I completely agree with evdl. A reoccurring month fee for a 'Professional' edition of MC would help support new and needed features/fixes. Actually an added on $.10/side would probably be a great way for MC to achieve this.

User avatar
arnie
Posts: 1594
Joined: 11 Feb 2009
Location: Portugal
Has thanked: 481 times
Been thanked: 514 times

Re: Multicharts -features, stability, reliability and speed

Postby arnie » 09 Nov 2014

I completely agree with evdl. A reoccurring month fee for a 'Professional' edition of MC would help support new and needed features/fixes. Actually an added on $.10/side would probably be a great way for MC to achieve this.
The majority of SC and IRT clients would prefer to have a lifetime license instead the monthly payment these platforms have.
You guys have a lifetime license platform and prefer to pay a monthly fee.

Go figure.

When you guys talk about a professional version are you talking about a 4th mc version? Standard, .net, tws and now a professional? Wow!
Not everyone would be available to pay a monthly fee when they bought a lifetime license. That's the point of a lifetime license.
If there's already some features that the .net has that it's not on the standard version and people complaint about it, how things would be if there would be another version with features that were not available on all the other versions?

I agree that the lifetime license remove from mc a revenew that can help/sustain the company in continuing improving the software but im not available to pay a monthly fee for my lifetime licence. It would be preferable to set a time table for major releases, for instance every 6 months and then charge a residual fee for it (IRT costs $75 a month and SC $45. I think a residual fee for each major release inside this interval would be suitable).

hilbert
Posts: 224
Joined: 17 Aug 2011
Has thanked: 76 times
Been thanked: 64 times

Re: Multicharts -features, stability, reliability and speed

Postby hilbert » 10 Nov 2014

But hilbert, what is core for you might not be core for me.

There'll be always a gap between what an algo and a discretionary trader needs.
Yes, discretionary and auto traders do have different needs. I tried to maintain balance but its possible that the core list is little biased towards system traders. But pls note that Multicharts markets itself as an automated trader's solution. Multicharts tagline is:
"Multicharts9
Introducing Portfolio Trader: One Stop Shop for Serious Automated Traders"

Most of the things mentioned as core are useless for my needs.
I think you overlooked first 3 core points. They affect you as much as they affect me :)

My first 2 core points are about Data Management, stocks splits and dividends. They apply equally well to both automated and discretionary traders. Point number 3 on backtesting also applies to discretionary traders to a very large extent. Many traders perform backtesting to gain insight into market patterns, and based on these insights, they improve their discretionary trading. Agree points 4 and 5 about autotrading and portfolio trader are not relevant to discretionary traders.

My point is:
if MC management decides to focus on improving core features for next 6-9 months, it will have a disproportionate amount of affect on the whole of MC software. These changes will be helpful for everyone, since core features affect 100% of clients, whereas an individual feature request would affect maybe 5-20% of clients. I hope you see my point and appreciate what I am trying to say. Have a nice day!

User avatar
bensat
Posts: 331
Joined: 04 Oct 2014
Has thanked: 46 times
Been thanked: 104 times

Re: Multicharts -features, stability, reliability and speed

Postby bensat » 10 Nov 2014

I think this is going in the wrong direction. There was no intention to start a discussion about a new fee structure or separation of features. No, no and no.

I just wanted to make people aware not to call for every feature which are just good for their good feelings. Again, this is just a fresh example. When I read the request for Renko bars to start at a special level in the morning, I just had enough. These guys will never be able to proof that to start Renko's at 5-15-50 or 95 every day will increase their trading results. Never. In my eyes there are many feature request like this out there. Why I had enough, because I'm the 7th week back in MC and I already see all the problems in MC and it's not me only. Look at the new thread I opened today while having problems with importing symbols/data via qmd-files. To repair problems like this took me the hole Sunday morning. This is not necessary. I would like to get problems fixed first instead of discussing red..... feature requests.

I further thought about the hole update routine for new releases. Why I have to compile the whole amount of studies again for every update and for like 4 hours in my case using MC as testing platform only? Is this seriously necessary ? Is there no other way to get updates in the platform ? I made the work to search through the hole forum and bug-reports etc. There is a lot out there what has to be repaired and fixed. Let's discuss all these things and lets give MC a chance to fix these things first.

I'm not a fan of "democracy", but the voting system is a "j...." or at least not working like it should be. There is no function to vote against features. It is possible to vote for it or to shut up only. How MC knows what people really want ? If 50 people want a feature how MC knows that no 50 other people don't want it ? Weird.

SO PLEASE STOP REQUESTING FEATURES WHICH CAN'T BE PROOFED TO BE THERE FOR BETTER HANDLING OR TRADING !!!! THAT IS ALL I WANT PEOPLE SHOULD AWARE OFF AND THINK ABOUT FIRST BEFORE ANY FEATURE REQUESTS. THANK YOU.

Regards.

Ben
Last edited by bensat on 10 Nov 2014, edited 1 time in total.

User avatar
arnie
Posts: 1594
Joined: 11 Feb 2009
Location: Portugal
Has thanked: 481 times
Been thanked: 514 times

Re: Multicharts -features, stability, reliability and speed

Postby arnie » 10 Nov 2014

I further thought about the hole update routine for new releases. Why I have to compile the hole amount of studies again for every update and for like 4 hours in my case using MC as testing platform only? Is this seriously necessary ? Is there no other way to get updates in the platform ?
I must agree with you on this one.
Quite annoying everytime we update to a new version all studies need to be compiled.
Sure, we can remove the option during installation but that does not save us from having to compile them afterwards.
In my case is 30min looking at the ceiling waiting for it to compile all the studies.

There should be a way to improve this.

hilbert
Posts: 224
Joined: 17 Aug 2011
Has thanked: 76 times
Been thanked: 64 times

Re: Multicharts -features, stability, reliability and speed

Postby hilbert » 10 Nov 2014

I think this is going in the wrong direction. There was no intention to start a discussion about a new fee structure or separation of features. No, no and no.
We can discuss ad infinitum among ourselves, it makes a difference only when MC management takes a note of our discussion and acts on it. I think this thread has generated some good thought provoking content. So, whatever your initial objective, I want to thank you for creating this thread. :)

User avatar
MAtricks
Posts: 789
Joined: 09 Apr 2012
Has thanked: 286 times
Been thanked: 288 times

Re: Multicharts -features, stability, reliability and speed

Postby MAtricks » 10 Nov 2014

The majority of SC and IRT clients would prefer to have a lifetime license instead the monthly payment these platforms have.
You guys have a lifetime license platform and prefer to pay a monthly fee.

Go figure.

When you guys talk about a professional version are you talking about a 4th mc version? Standard, .net, tws and now a professional? Wow!
I don't "prefer" or "want" anything. I'm simply engaging in a discussion to figure out how MC can better the platform features where everyone comes out on top. My post wasn't anything but to help prod the discussion along that path... Like other people on this thread, I want MC to be the best. At the retail level, it currently takes the blue ribbon, but I want it to be more :)

MC needs resources to create a reliable platform. We need a reliable platform. MC needs $$ to do their job. We need them to do their job so we can make $$. Any suggestions?

txls
Posts: 76
Joined: 17 Nov 2010
Has thanked: 36 times
Been thanked: 24 times

Re: Multicharts -features, stability, reliability and speed

Postby txls » 10 Nov 2014

Somehow this doesn't feel fair to MC.

Personally I always felt that MC has always taken reliability and stability issues very seriously.

I don't even remember when MC last crashed on me. Each and every issue I had with it was reviewed and within 1-2 days followed by recommendations on how to avoid it with ballpark ETA of the fix, or sometimes a hotfix (these took a bit longer of course).

Regarding new features, -- have a look at PM page, there's like a million feature requests, yet we don't see them being introduced by thousands with every release.

And MC already has something for those longing for a monthly subscription, it's called custom programming, a very solid way to implement certain features of one's interest.

User avatar
MAtricks
Posts: 789
Joined: 09 Apr 2012
Has thanked: 286 times
Been thanked: 288 times

Re: Multicharts -features, stability, reliability and speed

Postby MAtricks » 10 Nov 2014

No one is taking away from the hard work that MC is already accomplishing. They're doing a great job while charging such a small fee for basically unlimited support. What has been proposed here is more resources for more features, upgrades, and bug fixes.

There's no perfect platform out there, but some of us feel like we can get pretty close.

MC is my #1 platform and I have great hopes for the future which is very obvious based on the recent years of my hard work with the MC team on many of the implemented features so please do not misunderstand the constructive criticism.

I'm unsure how you are rating reliability of the platform.. It is very low on the list of reliable platforms. Even on the retail end. It is not only the worst platform, but the worst piece of software I've ever used when it comes to consuming machine resources. New features seem to be 'hacked' into an already outdated and mediocre framework

So I welcome the suggestion of providing more resources for those of us who use the platform regularly and at a professional level.

Jad
Posts: 92
Joined: 15 Jun 2014
Has thanked: 13 times
Been thanked: 21 times

Re: Multicharts -features, stability, reliability and speed

Postby Jad » 10 Nov 2014

Somehow this doesn't feel fair to MC.
Yes, it is hard to be all things to all people and there is no doubt that in many ways MC is the most versatile platform available. It's a Jack-of-all-trades with each user wishing it was a master of their own unique requirements. I agree that MC do a great job under the circumstances but I took the original post to be commenting on MC's focus on new bells and whistles when much of the 'basic' stuff still isn't working correctly.

Perhaps I misunderstood but I think bensat's concern is whether these bugs are not being addressed as quickly as they should be because MC is more interested in adding 'features' or if it's the plethora of feature requests that is causing the basic fixes to be put on the shelf.

If it's the latter, I think he was asking for us all to help the MC developers by thinking carefully before adding to the list of feature requests for things that we'd personally just like to have for "goooooood feeeeeelings" as he put it.

I tend to agree with his sentiment. However, it should be noted that many reported issues ('bugs' as far as I'm concerned) are too quickly dismissed and we are instructed to request the change as a Feature Request. This has happened to me on several occasions in the last few months (another example just happened again). I have had to keep banging away to get MC to recognize first that it isn't a 'feature' but a problem/bug that should not exist. The next stage is convincing them that the responsibility to fix it rightfully rests with them rather than us having to try and code round it. I have coded around some of the problems as I wait for the new releases but some issues can't be coded around.

That to-and-fro makes the whole process longer than necessary and I can see how some people wouldn't be persistent and just add it as a Feature Request which may, in part, account for the growing mountain of requests.

User avatar
Andrew Kirillov
Posts: 1589
Joined: 28 Jul 2005
Has thanked: 2 times
Been thanked: 31 times
Contact:

Re: Multicharts -features, stability, reliability and speed

Postby Andrew Kirillov » 11 Nov 2014

Dear customers!
I’m really pleased to see this discussion and I do recognize importance of your suggestions. I’m happy that many of you find MultiCharts is the best platform out there. Please take a look at the list of fixes and improvements we’ve made over the course of the last 10 years! It is terrific. If you analyze the what’s new page you will see that we always focus on adding new features and fixing/improving the existing functionality. The improvements/fixes are very important part of our development cycle. We carefully consider all suggestions in our Project Management, but implement only ones that we believe fit our concept. We are happy to analyze any specific issues and improve MultiCharts as we always do. I think we should discuss some concrete issues rather than our company’s policies. Thanks for keeping discussion constructive and lets make MultiCharts better together.

User avatar
bensat
Posts: 331
Joined: 04 Oct 2014
Has thanked: 46 times
Been thanked: 104 times

Re: Multicharts -features, stability, reliability and speed

Postby bensat » 11 Nov 2014

Somehow this doesn't feel fair to MC.
Yes, it is hard to be all things to all people and there is no doubt that in many ways MC is the most versatile platform available. It's a Jack-of-all-trades with each user wishing it was a master of their own unique requirements. I agree that MC do a great job under the circumstances but I took the original post to be commenting on MC's focus on new bells and whistles when much of the 'basic' stuff still isn't working correctly.

Perhaps I misunderstood but I think bensat's concern is whether these bugs are not being addressed as quickly as they should be because MC is more interested in adding 'features' or if it's the plethora of feature requests that is causing the basic fixes to be put on the shelf.

If it's the latter, I think he was asking for us all to help the MC developers by thinking carefully before adding to the list of feature requests for things that we'd personally just like to have for "goooooood feeeeeelings" as he put it.

I tend to agree with his sentiment. However, it should be noted that many reported issues ('bugs' as far as I'm concerned) are too quickly dismissed and we are instructed to request the change as a Feature Request. This has happened to me on several occasions in the last few months (another example just happened again). I have had to keep banging away to get MC to recognize first that it isn't a 'feature' but a problem/bug that should not exist. The next stage is convincing them that the responsibility to fix it rightfully rests with them rather than us having to try and code round it. I have coded around some of the problems as I wait for the new releases but some issues can't be coded around.

That to-and-fro makes the whole process longer than necessary and I can see how some people wouldn't be persistent and just add it as a Feature Request which may, in part, account for the growing mountain of requests.
You got it. Thank you.

Regards

Ben

txls
Posts: 76
Joined: 17 Nov 2010
Has thanked: 36 times
Been thanked: 24 times

Re: Multicharts -features, stability, reliability and speed

Postby txls » 11 Nov 2014

Dear customers!
We are happy to analyze any specific issues and improve MultiCharts as we always do. I think we should discuss some concrete issues rather than our company’s policies.
Actually, an interesting issue/feature of MC was brought up here earlier - the fact that each update has to be followed by studies' compilation. I'm using MC on two PCs, so that takes considerable time multiplied by 2. Is that compilation some kind of an absolute necessity? Perhaps there might be a way around it?

User avatar
Henry MultiСharts
Posts: 9165
Joined: 25 Aug 2011
Has thanked: 1264 times
Been thanked: 2957 times

Re: Multicharts -features, stability, reliability and speed

Postby Henry MultiСharts » 11 Nov 2014

Dear customers!
We are happy to analyze any specific issues and improve MultiCharts as we always do. I think we should discuss some concrete issues rather than our company’s policies.
Actually, an interesting issue/feature of MC was brought up here earlier - the fact that each update has to be followed by studies' compilation. I'm using MC on two PCs, so that takes considerable time multiplied by 2. Is that compilation some kind of an absolute necessity? Perhaps there might be a way around it?
This is something we are going to improve in the next major platform update (MC 9.1).

hilbert
Posts: 224
Joined: 17 Aug 2011
Has thanked: 76 times
Been thanked: 64 times

Re: Multicharts -features, stability, reliability and speed

Postby hilbert » 11 Nov 2014

I'm not a fan of "democracy", but the voting system is a "j...." or at least not working like it should be. There is no function to vote against features. It is possible to vote for it or to shut up only. How MC knows what people really want ? If 50 people want a feature how MC knows that no 50 other people don't want it ? Weird.
I don't think negative votes is a good idea. If two people have rivalry, they can go and cast negative vote on the feature requests of their adversary. Also, if some member of forum is unpopular, maybe some people will cast negative vote on his feature requests. You know - human beings are known to be be not completely rational and balanced all the time and can show unexpected behavior!!

However, I find merit in the idea that PM system is not working as efficiently as it could. I have been thinking about how we can improve the PM system and finally it seems I have a good suggestion. I have created a new thread to discuss it, as I dont want to go off-topic in this thread.

viewtopic.php?f=1&t=47565

User avatar
piranhaxp
Posts: 241
Joined: 18 Oct 2005
Has thanked: 4 times
Been thanked: 30 times

Re: Multicharts -features, stability, reliability and speed

Postby piranhaxp » 13 Nov 2014

I can remember many months ago when I posted my irritation about some useless feature requests. I got hammered from you ladies and gents. I got hammered from Henry Multicharts via PM's and so on. Damn. I gave up since, because knowing there are much more good MC users with me thinking the same direction, but shutting up because it's no longer worth to discuss it here.

I love and I really love MULTICHARTS and I'm still working with it. But we all see things and developments coming, which won't help MC in the future. Some things are getting messy and I see some already feel the pain. But I'm not complaining anymore. I'm still watching just to know what's going on. When it's time to leave the pain I'm prepared myself. But that's it. I just found the thread the thread opener is referring to. Yes, way to funny feature request and "bensat" is right. I just had a big lough and it feels good that complains about feature request behavior is confirmed and the view what will happen in the future about feature requests and MC was right.

If MC could just stop implementing such features for a while, fixing basic parts, taking heavy users on the side and discuss things together would raise the quality of the software big time. But sometimes I have the impression there are just sitting programmers. Sometimes I can't believe a "heavy trader" raised his thumb for such a program change or something else.

Go on MC, we still love you. But love has to be deserved, like in real life.

User avatar
MAtricks
Posts: 789
Joined: 09 Apr 2012
Has thanked: 286 times
Been thanked: 288 times

Re: Multicharts -features, stability, reliability and speed

Postby MAtricks » 13 Nov 2014

I can remember many months ago when I posted my irritation about some useless feature requests. I got hammered from you ladies and gents. I got hammered from Henry Multicharts via PM's and so on. Damn. I gave up since, because knowing there are much more good MC users with me thinking the same direction, but shutting up because it's no longer worth to discuss it here.

I love and I really love MULTICHARTS and I'm still working with it. But we all see things and developments coming, which won't help MC in the future. Some things are getting messy and I see some already feel the pain. But I'm not complaining anymore. I'm still watching just to know what's going on. When it's time to leave the pain I'm prepared myself. But that's it. I just found the thread the thread opener is referring to. Yes, way to funny feature request and "bensat" is right. I just had a big lough and it feels good that complains about feature request behavior is confirmed and the view what will happen in the future about feature requests and MC was right.

If MC could just stop implementing such features for a while, fixing basic parts, taking heavy users on the side and discuss things together would raise the quality of the software big time. But sometimes I have the impression there are just sitting programmers. Sometimes I can't believe a "heavy trader" raised his thumb for such a program change or something else.

Go on MC, we still love you. But love has to be deserved, like in real life.
Incredibly well said!

The engineers behind the platform should also have experience in using it for its purpose.

orion
Posts: 250
Joined: 01 Oct 2014
Has thanked: 65 times
Been thanked: 104 times

Re: Multicharts -features, stability, reliability and speed

Postby orion » 15 Nov 2014

If MC could just stop implementing such features for a while, fixing basic parts, taking heavy users on the side and discuss things together would raise the quality of the software big time. But sometimes I have the impression there are just sitting programmers. Sometimes I can't believe a "heavy trader" raised his thumb for such a program change or something else. Go on MC, we still love you. But love has to be deserved, like in real life.
Incredibly well said! The engineers behind the platform should also have experience in using it for its purpose.
One issue is lack of universal agreement on what constitutes a heavy trader since there are several dimensions to the problem: (a) manual vs semi-automated vs fully automated trader, (b) trading single instrument vs few instruments vs hundreds or thousands of instruments, (c) trading style (scalp, swing, ...), (d) categories traded (forex, futures, equities, options), (e) level of technology fluency (desire to have more interfaces to augment with own PL/C#/C++ solutions)

As an example, someone trading hundreds of instruments using PT may prefer API access to the database to be able to manage database integrity in a fully automated way but this may not be of interest to a trader who trades fewer instruments and can afford a manual solution for database integrity.

Overall MC has gotten the architecture right even though it has some warts. MC is able to deliver EL compatibility at 5X the performance while offering a .NET solution and a portfolio trading solution (even though there are warts such as the PT symbol list import feature not being compatible with the QM symbol list import feature).

Hilbert's suggestions of voting mechanism for feature requests is right on. A limited number of votes per user per year will help MC management sieve through the myriad feature requests that pop up.

txls
Posts: 76
Joined: 17 Nov 2010
Has thanked: 36 times
Been thanked: 24 times

Re: Multicharts -features, stability, reliability and speed

Postby txls » 15 Nov 2014

This is something we are going to improve in the next major platform update (MC 9.1).
One more thing, if I may.

I'm using two displays, and there is a small issue with QM.

When QM finishes importing an ASCII file, "The data was imported successfully" window appears (as I understand) on the currently active display. Can it be forced to appear on the same display as the QM window?

User avatar
JoshM
Posts: 2195
Joined: 20 May 2011
Location: The Netherlands
Has thanked: 1544 times
Been thanked: 1565 times
Contact:

Re: Multicharts -features, stability, reliability and speed

Postby JoshM » 17 Nov 2014

Hilbert's suggestions of voting mechanism for feature requests is right on. A limited number of votes per user per year will help MC management sieve through the myriad feature requests that pop up.
A limited number of votes is not a good idea, I think. Because that will 'punish' the more active users that actually use the PM to make requests and vote for them.

Let's say I get 10 votes per year and I consider myself an active PM user. And let's say this thought experiment starts in January. So what will happen if in February my votes are used? Since I then cannot use one of the important features of the PM anymore, I will not use it again for the remainder of the year. If other users also feel that there is no point anymore in reviewing requests made by others (since they cannot vote anymore), the PM website would be used even less.

Limiting the amount of votes to some arbitrary number is like limiting the number of posts one can make on the forum. What kind of problem would be solved by that? Is the current problem of the PM really that there are too many votes?

I can think of a lot of other things of the PM website that are more important:

* The website speed,
* The huge amount of issues that are not closed or reviewed,
* The slowness in responses and reviews from MC,
* The search capabilities and browsing capabilities,
* The low amount of activity and low number of votes,
* The different login compared with the forum credentials coupled with the cookie's settings,
* And not being able to downvote.

hilbert
Posts: 224
Joined: 17 Aug 2011
Has thanked: 76 times
Been thanked: 64 times

Re: Multicharts -features, stability, reliability and speed

Postby hilbert » 17 Nov 2014

Hilbert's suggestions of voting mechanism for feature requests is right on. A limited number of votes per user per year will help MC management sieve through the myriad feature requests that pop up.
A limited number of votes is not a good idea, I think. Because that will 'punish' the more active users that actually use the PM to make requests and vote for them.
Its not 10 votes per year, rather its 10 votes allowed at any given time. As soon as a requested feature gets implemented, your vote gets released, and you can use that vote for another feature request. This system will not 'punish' the active user, rather it will help make the active user "prioritize and focus" on the most important features that matter to him.
Let's say I get 10 votes per year and I consider myself an active PM user. And let's say this thought experiment starts in January. So what will happen if in February my votes are used? Since I then cannot use one of the important features of the PM anymore, I will not use it again for the remainder of the year. If other users also feel that there is no point anymore in reviewing requests made by others (since they cannot vote anymore), the PM website would be used even less.
1. Your votes will get returned to you as soon as MC implements a feature. So, say by April, they have implemented 3 features out of 10 requested by you, you will get your 3 votes back.
2. Rather than going to PM every month and requesting for new features, don't you think it is a better idea that you go to PM once every 3-4 months, think carefully and vote on "most important features for you" rather than vote on all the nice features that MC should have? I personally think rather than working on 100 things simultaneously, it is much more productive to focus on only 5 things at a time and finish them.
3. Now, since all the active users are forced to think critically before voting, it helps to channelize and funnelize the most important features for the majority. MC management gets a much focused feedback compared to current state of affairs. If you plot a barchart of #votes Vs Features, this bar chart under above proposed PM voting model will have a bi-modal shape with much more sharper peaks - one peak corresponding to features important for auto-traders and while another corresponding to features important for manual traders. Under current PM model, the bar chart has a very broad round looking hump in the middle.
I can think of a lot of other things of the PM website that are more important:

* The website speed,
* The huge amount of issues that are not closed or reviewed,
* The slowness in responses and reviews from MC,
* The search capabilities and browsing capabilities,
* The low amount of activity and low number of votes,
* The different login compared with the forum credentials coupled with the cookie's settings,
* And not being able to downvote.
We all agree on these points. I personally appreciate all the suggestions that you keep giving to MC team for increasing PM speed. They have mentioned that they are going to create multiple tabs in PM window, that will increase the speed of PM process.
My suggested solution solves your point number 2, 5 and 6 above. My hypothesis is current low amount of activity and low number of votes and low number of active users on PM is because PM is so ineffective right now. I think - Increasing the speed along with above suggestion to limit number of votes will make PM system much more effective. Have a nice day!
Image
Attachments
New PM Model Vs Old PM Model.png
(25.57 KiB) Downloaded 3062 times

User avatar
arnie
Posts: 1594
Joined: 11 Feb 2009
Location: Portugal
Has thanked: 481 times
Been thanked: 514 times

Re: Multicharts -features, stability, reliability and speed

Postby arnie » 17 Nov 2014

If you lock (10 votes) the ability the user has in voting on new features, if the user has the misfortune by voting on features that might take more then a year to be developed... he's stuck. He can't show is interest in other features that are requested after his votes and that management for whatever reason finds more important to be implemented first if there's some interest in it.

You're assuming that management decides what features are to be developed depending on users requests. They've shown us several times that it's rarely the case. Why do you think they are always saying that so and so do not fit their road map?
Management decides what feature to be developed based obviously on users requests but above all else their own plan to where they want to take Multicharts and their view what Multicharts should be, independently what their users think or wish.

Although agreeing with the way they manage MC it sucks as a client when having some requests rejected :(

hilbert
Posts: 224
Joined: 17 Aug 2011
Has thanked: 76 times
Been thanked: 64 times

Re: Multicharts -features, stability, reliability and speed

Postby hilbert » 17 Nov 2014

If you lock (10 votes) the ability the user has in voting on new features, if the user has the misfortune by voting on features that might take more then a year to be developed... he's stuck. He can't show is interest in other features that are requested after his votes and that management for whatever reason finds more important to be implemented first if there's some interest in it.
Agree, this is a problem with this limited votes system and I have been thinking of a good solution. A solution could be if a user has exhausted all his 10 votes, and none of the feature requests turn into production for 4 months, system can allocate him 2 additional votes. I didn't put this suggestion initially, as I wanted the voting system to remain comparatively simple, and not have people start threads to understand the voting system :) :)

To summarize, my thought is: Limiting votes to the PM does suffer from above problem, but it solves so many other problems, that we will be all better-off if above change is made to the PM system.

hilbert
Posts: 224
Joined: 17 Aug 2011
Has thanked: 76 times
Been thanked: 64 times

Re: Multicharts -features, stability, reliability and speed

Postby hilbert » 17 Nov 2014

You're assuming that management decides what features are to be developed depending on users requests. They've shown us several times that it's rarely the case. Why do you think they are always saying that so and so do not fit their road map?
Management decides what feature to be developed based obviously on users requests but above all else their own plan to where they want to take Multicharts and their view what Multicharts should be, independently what their users think or wish.
Yes, management does have their own road-map, but at the same time, I do give credit to MC management, they are much more appreciative of user requests than TS management. TS platform was basically stagnant for a long-time before 2011. And I think MC's constant focus on adding features and doing roll-outs, did play a role in forcing TS to develop their platform again after a long period of time starting from 2010-11. So, I like MC management, for not only making MC a better product, but also to force TS to improve their product. We traders are better-off as a result. :)

orion
Posts: 250
Joined: 01 Oct 2014
Has thanked: 65 times
Been thanked: 104 times

Re: Multicharts -features, stability, reliability and speed

Postby orion » 17 Nov 2014

Agree that limited votes with 10 votes per year could be problematic. But it would be less problematic if you increased it to 100 votes per year. Also, perhaps it is worth thinking about not 100 votes per year per user but 100 votes per year per license. If a user wants to influence some new feature he is free to buy 10 licenses and cast 1000 votes for the feature. Perhaps we may be better off when people vote with their wallets?

User avatar
arnie
Posts: 1594
Joined: 11 Feb 2009
Location: Portugal
Has thanked: 481 times
Been thanked: 514 times

Re: Multicharts -features, stability, reliability and speed

Postby arnie » 17 Nov 2014

If a user wants to influence some new feature he is free to buy 10 licenses and cast 1000 votes for the feature. Perhaps we may be better off when people vote with their wallets?
It would be way more cheaper to pay MC directly for custom development and of course you would have your feature developed way faster

User avatar
MAtricks
Posts: 789
Joined: 09 Apr 2012
Has thanked: 286 times
Been thanked: 288 times

Re: Multicharts -features, stability, reliability and speed

Postby MAtricks » 17 Nov 2014

Some of us already have that many licenses :)

User avatar
bensat
Posts: 331
Joined: 04 Oct 2014
Has thanked: 46 times
Been thanked: 104 times

Re: Multicharts -features, stability, reliability and speed  [SOLVED]

Postby bensat » 18 Nov 2014

Hey guys,

are you sure your discussion about voting procedures and a right PM is still on topic in my thread ?
If you want to discuss a new or different PM system, please open a new thread. I just wanted to make a point about (un)necessary feature requests. There was no intention to talk about a PM from my side. Thank you.

Regards.

Ben

User avatar
arnie
Posts: 1594
Joined: 11 Feb 2009
Location: Portugal
Has thanked: 481 times
Been thanked: 514 times

Re: Multicharts -features, stability, reliability and speed

Postby arnie » 18 Nov 2014

Like it or not, it's all intertwine.

User avatar
bensat
Posts: 331
Joined: 04 Oct 2014
Has thanked: 46 times
Been thanked: 104 times

Re: Multicharts -features, stability, reliability and speed

Postby bensat » 18 Nov 2014

Like it or not, it's all intertwine.
With all the respect to the user, who made this feature request which "forced" me to complain about such feature requests, I did not hijack his thread and opened this thread. Further I see no relation between the improvement of the PM system and my entry in this thread here and I just said in my 2nd post that it is not possible to vote against something and questioned how MC knows what people want. Is this a call for a discussion about the PM system right here ? I don't think so.

I know my English isn't the best, but this should be obvious.

Regards.

Ben

Jad
Posts: 92
Joined: 15 Jun 2014
Has thanked: 13 times
Been thanked: 21 times

Re: Multicharts -features, stability, reliability and speed

Postby Jad » 18 Nov 2014

It's easily missed in the thread above but hilbert already tried to direct any further discussion about the Pros and Cons of the PM system to a new thread.

viewtopic.php?f=1&t=47565


Return to “MultiCharts”