Ok so it is all about the priority. What are your priorities that the developers should focus on?
Personally speaking, there are some features that I’d like to have in SGP: direct support for QHYCCD cameras (or at least the possibility to set the offset for each event), the possibility to repeat times a sequence (i.e. instead of 9xR + 9xG + 9xB do 3 x (3xR +3xG + 3xB) without duplicating the target, INDI support for a client/server approach, and many more. However, all I really ask to developers is keeping the current level of reliability as they-re adding support for new hardware.
Anyway, that’s just my opinion and I’m perfectly fine with you having a completely different one.
Thats good to know. I thought the Devs policy was to not spend time on specific hardware support but to focus on supporting ascom compliant devices. In many posts they have put the onus on the hardware developers making their drivers ascom compliant. You can already do 3x 3x R etc by adding extra events. INDI support is also interesting. I wonder what percentage of users are asking for this? Perhaps a poll of users would help?
Just to be clear, with “support for new hardware” I mean the capability of handling new types of devices of new functions that are NOT supported by ASCOM. Perhaps something that’s still to be invented. As a owner of a QHYCCD camera I’ll never ask for direct QHYCCD support: everything that can be done in ASCOM should be done in ASCOM, hardware abstraction is a key principle in programming. There’s a big difference between what I’d like to a have (as a nice feature) and what I’d ask to developers (BTW, I never issued a request for a new feature since I use SGP).
Interesting. Thanks for sharing that Jared.
And thanks for all the great work on SGP. Much appreciated!
I fully agree on that Alessio, I’ve been an INDI user from 2015 onwards and I love the entire idea of it. Linux as a server so it’s super stable (and never tries to force an update) and is built for remote control. I’ve had very succesful sessions with it and am still trying it out in the beginning of a new session, just cause the polar alignment is/was awesome (mainly when PHD didn’t have it yet). My main problem with it, as much as I love it, it is unreliable. In 2015 I was on board and wanted to test out everything and send back bug reports, nowadays it seems I still have to do that. And I appreciate the effort the developers put into it ofcourse (and it’s free as well), but when drivers for my camera’s out of nowhere suddenly stop working or the scheduler suddenly misbehaves and this happens for 3 years already off and on… I’m now simply waiting until those kind of issues don;t pop up on the forum anymore. As much as I want to not use ASCOM anymore and as much as the stability of a Linux based system is attractive, when I started using SGP, I simply was snapping away. Updates? No issues, just carry on. So to me it seems a bit like too many new features, but I also wonder if the underlying code is as clean as it could be. Otherwise these kind of bugs should show up more easily (just guessing as I’m not programming it).
TLDR; I rather have a feature take 3 years to develop, than to bug fix every little step on the way for a hobby like astrophotography.
It’s interesting to watch the call for bug fixes. In my experience with SGP over many years I’m not seeing these issues. The thing I like about SGP is that it simply works. I have a reasonably standard setup including Windows, ascom, eqmod and ascom drivers. I often wonder if a lot of the issues people report as bugs are UGEs or simply compatibility issues with unsupported equipment/drivers?
I still experience a few gremlins in 3.0.1 but nothing too serious or unreliable as such. Most of my imaging is unattended and I can leave it all night without concern.
I echo the sentiments about reliability. If this hobby was a simple as buy some kit, turn it on and upload some pictures, it would be no fun at all. The middle ground is someone who has the satisfaction of overcoming obstacles and gets to where they want to be with a reliable system and finally those who are constantly battling with multiple issues which defy correction and ultimately have nothing to show for their investment.
There is a bit of device specific going on… quite a bit of traffic from ZWO users, which I guess is why it is being singled out for special attention.
There has not been an update for some time and it might be useful to know what is on the planned next maintenance release.
If someone were to ask my opinion on the matter, and having developed software, I think buzz’s analogy is spot on. Just because it can, does it mean it should?
I’d rather sgp be good at what it does (imaging sequences) first and foremost. Stabilize that, then add additional functionality.
I think if anything, adding application compatibility may be a better way to do this, ie. allowing sgp to communicate with other softwares that are good at what they do.
So I wouldn’t say never add it, but as mentioned by others, it’s a priority thing. Especially since there are stand alone softwares out there that are dedicated to that.
Unfortunately ASCOM doesn’t expose offset and CMOS cameras seem to need that. We’ll (unfortunately) do the same for QHY after ZWO is finished. But we had to pick one to start with and ZWO seems to have more traction with CMOS cameras than QHY does at this point.
Unfortunately no one has asked the ASCOM developers to add offset.
If you had then if might have been added. But no one asked. I did mention it but the wisdom from experts is that there isn’t a technical reason for it, not even on a CMOS CCD. I’m not going to push for something that I don’t believe is required on behalf of people who can’t be bothered to ask for it.
I notice that some of the latest CMOS cameras change offset automatically when the user changes the gain and the offset is not exposed to the user. In many ways, that is a more robust way to go, as it allows the OEMs to have tighter control over the image quality.
I almost had written the very same. My ASI294MC (a very new CMOS camera model) has no setting for offset and I am glad that the setting of the offset happens automatically. It works very well.
I’d prefer to use the existing capture, solve and slew capability of SGP for fast polar alignment than have to resort to using other applications which are more limited than SGP - especially in their plate solving capability.
The concept of new major releases implys new features will be added, not bug fixes. If it can and enough users think it is a useful feature to add then why not?