For the Study & Growth of Sidereal Astrology
https://solunars.com/
The midpoint bugfixing is the last part of this beta that still needs to get fixed before we can call it a stable release and I can start working on 1. stable Linux and MacOS releases, and 2. the 0.7 stuff.Jim Eshelman wrote: Sun Feb 09, 2025 7:08 pm And no changes to midpoints were needed because they're already by orb.
That's an exciting juncture! As much as I want to get to 1.0, I'd also like to begin offering this to people who are on MacOS since there is really nothing for them to use right now to do anything like we want.Ember Nyx wrote: Sun Feb 09, 2025 8:07 pm The midpoint bugfixing is the last part of this beta that still needs to get fixed before we can call it a stable release and I can start working on 1. stable Linux and MacOS releases, and 2. the 0.7 stuff.
My concept is that it's only useful in the natal right now, and there should an Options setting to turn it on/off. Perhaps default it to On, though, so people start seeing it.The things on my radar for 0.7 are:
Add Novien table to bottom of chart page (i.e. the natal chart page, I'm assuming)
This might be one or the coolest additions. I'm at least interested to see whether the mind takes to this better than NOT having it. - As part of this, I think an important feature is to use it to capture transits to natal angles in return charts (either in the first list because it's foreground or in the Other Partile). - Oh, I just saw that you had that last one below.Allow users to display contacts with angles as aspects in the aspect list (i.e. optionally, additionally parse them as aspects within the normal rules that govern contacts to angles)
All good.Add support for 10° multiple aspects
Add partile transits to natal angles to Other Partile section
Include zips under source control (i.e. distribute downloads via Github rather than pass around direct download links)
Some of these I'm quite eager to see. (I'd do a lot more KLRs with it. Even though I have a kluge in Solar Fire, the precision isn't as good as I'd like.) I don't know how much people in general are interested in all this, but we ultimately should have it.Additionally, I'm hoping to get in some more infrastructure for the minor solunar return charts - Ennead variants, KLRs, NLRs, anlunar variants, etc. Lunisolars and solilunars would probably come later due to some technical (algorithmic) challenges. (I probably have semi-usable code lying around to calculate those, but I'm not confident in its behavior.)
Oh, yeah! I definitely hear that. I'm not sure what we'll find with stuff like mundane three-layered aspects in a Kinetic.It's fine if the kinks aren't worked out on those - but I find myself continually missing this functionality whenever I slog through calculating one of these charts and their aspects (especially mundane aspects) the hard way.
You're right, and I kind of forgot about that part.Jim Eshelman wrote: Mon Feb 10, 2025 8:51 am Since KLRs require calculating secondary progressions, will these be available ahead of the return variants? Having secondaries by themselves first would make QA go better, since getting the rate exactly right needs some work compared to any software in the past. -- Unfortunately, introducing secondaries introduces a few extra complications to get the variants correct.
Code: Select all
Number of days elapsed since birth = target datetime - birth datetime
Julian day for prog planets = number of days elapsed since birth * progression rate
(Then just plug in that julian day and calculate all the positions)
Yes, that's it in essence (and that's it exactly for the simplest case). The whole complication of the simplest case is in getting the exact progression rate constant.Ember Nyx wrote: Mon Feb 10, 2025 10:25 pm Here's my thought process on that - getting the julian day corresponding to the progressed planets is I think as simple as:
(Pseudocode)Is that correct?Code: Select all
Number of days elapsed since birth = target datetime - birth datetime Julian day for prog planets = number of days elapsed since birth * progression rate (Then just plug in that julian day and calculate all the positions)
One of these days we're going to have to confront the fact that we have too many perfect synonyms in use - multiple names for the same thing. When quotidians first came into use (and multiple variants of them unfolded) it seemed obvious to give them their own names. However, ultimately, the natal quotidian is exactly the same as the progressed natal chart. (Ditto with the solar quotidian and the progressed SSR.) So, in doing secondary progressions, we are exactly doing quotidians already.Also, I feel like it would be a good idea to eventually include quotidian charts on the same transit/prog menu page, since they'd work the same way: very similarly to solunars, but using an exact date and time rather than finding active/forward charts. Calculating quotidians requires a lot of similar infrastructure to calculating anlunars, KLRs, etc - we'd need to calculate a few charts along the way to get their points, and in doing so would need to know "what is the UTC julian day for the active SSR/quarti-SSR/whatever," etc.
I see what you're saying, and yeah, it's probably worth it to nail down the core 1.0 stuff as the immediate next priority. I do think we should talk about menu design/etc prior to 1.0 release. Time Matters doesn't really conform to modern UI/UX conventions and I'd like to rearrange things before championing it widely.Jim Eshelman wrote: Fri Feb 14, 2025 10:24 am That you've essentially finished the original plan for 1.0 doesn't mean we can't add more (and it certainly doesn't mean we shouldn't look ahead to anticipate infrastructure needs). I wanted to float the question, though, of whether it's a good idea to add these extra things at this stage. There seems to me great merit in having a full release 1.0 that we can start evangelizing, spreading the word online, getting more people involved in a product we're willing to say is completely finished (while subject to expansion).
Mike N's original plan of natals / ingresses / solar and lunar returns has been sharpened a great deal. Maybe a fresh QA look will find little things that need tweaking (oh, you said there's is something still to be done to get midpoints right - I forgot that). What do you think about making a beeline for a 1.0 release with the short list remaining?
Nitpick, I see things like transits/progs/etc as being 1.x releases rather than 2.0. I personally see a 2.0 release as something like 1. an entirely new, modernized Python framework instead of Tkinter (or moving to something like Electron, which is Javascript-based), or more likely, 2. a web application that would be inherently cross-platform and mobile-compatible out of the gate. I don't think there's a reasonable way to get full mobile and cross-platform desktop functionality without having it be a website (which explains why no existing program is either). That is a whole other can of worms (where do charts live? etc), but I see Time Matters (or an open-source successor, whatever the name) as eventually being a web app.That would mean Noviens now and the rest of your 0.7 list being a 2.0 target.