Expectations for SGPro 4

Hi folks,

Now that things are calming down a bit with support and the new licensing system seems stable, we can start looking forward to SGPro 4. Before specifics though, I want to take a moment to discuss the new licensing model and how it will impact SGPro versions 4 and beyond.

The first point is that, with our new licensing model, versions numbers in SGPro are much less meaningful. They will still exist going forward, but they will mostly be for the purpose of referring to intangibles (i.e. so we can all refer to the same thing during discussions). One of the major selling points of our new model is that we no longer feel obligated to save up a whole bunch of features and release them all at one time in order to justify the value of a major (paid) version release. That style of release is inherently fragile because it holds so many new things at one time and it also serves to hold some features “hostage”. If we wanted to release ten new features and nine are complete, but we are having difficulty with the last one, those other nine may be held hostage by a last set of problems. Our current model allows us to release features as they become available. It’s better and easier for us as developers and it’s definitely a better deal for our users.

As for the subscription part? Is less than $5 per month too much for unlimited access to SGPro upgrades? maybe too little? I’m not sure and, in any case, that kind of value is certainly in the eye of the beholder. What I can say is that we have taken great care to present this new model in a way that does not force anyone to pay something for nothing. At any point in SGPro’s lifetime, you can stop paying and you will always have a version of SGPro you can use… forever, and never spend another penny. Further, if you want to take a break from your subscription and later decide to re-subscribe, you will never be charged the initial sign-up fee again. If we never produce another feature that you value more than $5 a month for a single year, you will never need to pay anything again.

It’s too exhausting to try to convince everyone of this, but I will say that you should feel free to share this if you have the opportunity (meaning… if you happen upon external conversations that, for the sake of outrage, take this model out of context, compare it to modern day highway robbery, etc, I hope that this may serve as an explanation). Ok! Enough of this… let’s talk about 4.0.

Given the context above, nobody should panic that the initial scope of SGPro 4 includes only one feature or is maybe not what you were hoping for. We will usually have a pretty clear line of sight on the next couple of things coming out (because we are actively working them), and probably a pretty good, but less clear, notion of the next few things to be released afterward.

Some time this week, it is my hope to release the first 4.0 beta (any active subscriber can use it… keep in mind that when the first version of SGPro 4 is officially released we will reset all new active subscriptions such that they will remain valid for 1 year from the date of that release… in other words, don’t worry about “wasting” your subscription time on a beta). Here are the upcoming releases that we feel pretty confident about (all in the context of SGPro 4):

  • Full support for ASCOM and PrimaLuce Eagle switches. Control all your switches manually through the control panel (and a floating module in a future release). Set a complete “switch state” at sequence start and end. Coming soon afterward: control switch state in a variety of other sequence states: auto focus, manual focus, calibration frames, error states, etc.
  • Fully compliant 64-bit support. It will be referred to as 64-bit SGPro for simplicity, but SGPro doesn’t actually have a “bitness”. This refers to SGPro’s ability to use and communicate with drivers and external software that is actually 64-bit. You will no longer be required to install the 32-bit version of drivers and for some larger format cameras, this could be very meaningful (if you were having memory issues with 32-bit).
  • Small pause for stability and minor enhancements (sequence start scripting, add some of the switch state support mentioned above and several others)
  • Refactor the “Target Display Window”. Resizable view area (to some extent), expand to expose and edit common settings without opening the target settings dialog.
  • Bulk target editor (think spreadsheet-like interface)
  • Official support for dual (or more) SGPro coordination. First release will only support dithering coordination, then maybe later, support for synchronized auto focus and synchronized error handling for failure in secondary imaging train.
  • TBD: Session planning tools… this is a deep topic, more on this later in a dedicated topic.

As always, please do request features. We do read and consider all suggestions (even if we don’t respond to all of them).

1 Like

Will V4 run on a 32 bit OS?

Mike

Yes, there will be a 32 and 64 bit variant. We were planning on coupling them together and allowing the user to switch between the two in the application (assuming your OS could support both). But that turned out to be too onerous so for the time being there will be a 32bit and a 64bit that you can download.

I have a feeling that a handful of users will likely be stuck in the 32bit version until more devices have 64bit drivers. It really just depends on your hardware. But my Qhy11 only has a 32bit driver so I’ll be one of those users forced to use the 32bit variant.

Jared

On 32bits vs 64 bits, will some of the SGPpro specific drivers continue to operate under 64 bits : for example the FLI drivers ?
One suggestion is to also incorporate as much as possible in your thinking that we are transioning more and more to CMOS, which implies gain management. That means : (1) flats calibration wizard being able to use different gains for different filters, (2) assigning in profiles different gain levels to different filters, (3) if not (2) moving gains setting to the main sequence window as opposed to the settings.
The bulk target editor seems like a great idea. If there would be a way to incorporate into it start and stop time depending on Alt and AZ that would be great. For example, I have many obstacles around my home and add/remove a few minutes manually to start / stop time for targets I image on multiple nights because of Alt / Az constraints. The Rolls Royce version would have masks that consider what part of the sky is available for your imaging…
Thanks

Yes, as long as the manufacturer makes a 64bit driver. As an example there is a 64bit driver for FLI but SBIG is only 32bits. So SBIG users would have to stick with the 32bit option until they release a 64bit driver.

Jared

This all sounds great

I have two requests

  1. integrated planetarium program (nice to have)
  2. better automated scheduling of such things as filter-by-altitude, proximity to moon, etc.

automation works great today, but i still have to manually tweak things on a day-by-day basis depending on position of moon, etc.

it would be great to say “shoot red filters below 50 degrees, only shoot blue filters near zenith…” etc.

I would like to see the image file option of XISF compressed files. Much needed with large files of cameras like QHY600M
It’s something Nina does that doesn’t sound that hard to do.

2 Likes

+1 for that one @gregm as I am now using the ASI6200 which has already caused SGPro to crash a couple of times during Flats Calculation Wizard

I presume the 64 Bit version will also allow the usage of more memory region to make the application faster also?

64-bit will not be inherently faster unless your camera manufacturer explicitly states as much. SGPro itself, does not have a “bit-ness” and the 32-bit version is identical to the 64-bit version… the only difference is that SGPro knows to use 64-bit drivers, but nothing internal to SGPro will change.

Ken,

Can you please explain to me what you mean by that SGP does not have a bitness? Is it a 32bit app that is thunking to use the 64 bit drivers?

SGPro is .NET app and (as any .NET app from the born) can run as both 64-bit or 32-bit executable.

Yes I understand the source code for #net is not bit specific, but complications can arise when calling DLLs. When you build the EXE you can specify a target that may be 32bit , 64bit or either. I guess that is what I was getting hung up on. I understand now thanks.

Hi, I know this is an old thread however, I was wondering if the XISF file format has been implemented?

Thanks.

Gray.

XISF support has not been implemented.

Jared