Why am I here?

OK so this isn't some existential crisis blog...

Basically I'm thinking about the creation of a single application that can handle all the tasks an astrophotographer needs when taking exposures. It's mostly here for me to keep a record of what I'm doing, but if you stumble across this blog by mistake and you have any ideas or suggestions for improvements, please don't hesitate to put the boot in.

Now I haven't done any astrophotography (AP from here on in) for a few years now - I did a bachelor's degree in Astrophysics which, needless to say, started taking up too much of my time. Then I decided I'd carry on and am currently about to finish my Master's degree and begin a PhD. Oh yeah, and I had a baby too, so time has been kinda tight.

However, I have had a lot of time to think, and one of the things that used to stress me out about AP was that you had to have so many programs running at any one time, and that they didn't always necessarily talk to each other all that well.

SO...the plan is to bring them all together into a single app.

Last time I did AP then, I was using the following software:

PHD for Autoguiding
APT for image capture
Cartes du Ciel for GOTO control
DeepSkyStacker for DSO image stacking
Registax 6 for planetary (I was always rubbish at this).
Photoshop CS6 for further processing.

Now, I'm not intending to take on any of these established brands for supremacy - they undoubtedly have the upper hand when it comes to technical know-how, coding skill and applicability - but what I lack in those I make up for in bald-faced idiocy, so here we go!

The app will be programmed in Java for two simple reasons:

1. Java is excellent for cross-platform operation, so I won't have to dick about too much with OS-specific coding.
2. I can only code in Java. Well, that's not strictly true - I can only do GUI based coding in Java. I may fall back on Python or something for some scripts here and there, but if I can I'll keep it Java.
2b. I also know a little about multithreading in Java which may prove useful, especially when a fairly large number of operations are going to be proceeding concurrently.

Whilst of course I will offer my efforts up for the use of others, I shall, at least initially, be coding this for my own benefit. This means it will be designed to work with my own quirky setup. Why is it quirky? Well, I want to operate my 'observatory' remotely, despite being only in the living room whilst the rest of it's outside. The problem is a) that I rent, so I can't start drilling holes in walls and b) AP happens best in winter, so SWMBO won't be too chuffed if I have the door open for a bunch of cables.

The plan is then, from a hardware point of view, to use VirtualHere server on a Raspberry Pi 3 connected to my scope and cameras, whilst the Client is inside on the Mac/PC/Linux machine. I have the luxury of all three, which will be convenient for testing when I start thinking about releasing this for others to use.

Now I'm not sure whether or not VirtualHere will operate fast enough, particularly for autoguiding, as I've never used it before. However, if all goes well, the devices connected to it should just behave as if they're connected to the client machine, so I'll be doing the coding as if this remote setup didn't exist. At a (much) later date, it might be worth investigating the possibility of integrating VH into my own software, but that is some way down the road. Hell, I've not written a single line of code yet, so baby steps.

OK well there's the basic premise. I'll next post about my thoughts on the layout and initial functionality of 'AstroShop' as I've hastily decided it will be called.