Time Matters 0.6.0a Alpha Pre-Release - Windows

[Jim Eshelman]

Works great! (And I see you added Orcus and rearranged things on the Options page. Neat.) Thanks

And no changes to midpoints were needed because they're already by orb.

[Ember Nyx]

Funny story, I had had Orcus there the whole time... It was just hidden behind Sedna because I screwed up the Y coordinate for those entries.

And no changes to midpoints were needed because they're already by orb.

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.

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)
• 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)
• 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)

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.)
Triwheels (and probably quadwheels) do functionally work in terms of chart display and aspect parsing stuff, but the various setup screens and their logic (i.e. finding the desired return datetimes) aren't set up.
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.

[Jim Eshelman]

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.

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.

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)

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.

Given that options setting, I can't think of a reason (unless there are programming complexities) not to make it available on returns and ingresses as well - defaulted to Off, though. (Returns would only have it for the return, I guess, not repeat the natal.) I can't think at the moment that people really want this, and it could lead to some insane pathways; but if it's only a matter of copying a few lines to the returns and ingresses, I can't think why NOT to make it available as an option if someone digs enough to find it.

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)

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.

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)

All good.

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.)

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.

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.

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.

Oh, yeah! I definitely hear that. I'm not sure what we'll find with stuff like mundane three-layered aspects in a Kinetic.

[Ember Nyx]

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.

You're right, and I kind of forgot about that part.

Here's my thought process on that - getting the julian day corresponding to the progressed planets is I think as simple as:

(Pseudocode)

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)

Is that correct?

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.

[Jim Eshelman]

This could be a long, rambling answer; or maybe I'll use a bit of self-discipline.

In fact, I'll create a new thread in the Wish List File Room sub-forum about progressions. That will be more useful as a stand-alone.

Ember, I need to say first (and I'd forgotten this myself) that I saw all of these minor chart add-ins as version 2.x developments. I looked back at the version 1.0 target list and - apologies for being surprised - saw that you've almost covered everything. All that's really left on the original plan is the Novien table and a couple of minor text matters (and then the Mac and Linux builds you already said come next).

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? That would mean Noviens now and the rest of your 0.7 list being a 2.0 target.

(I'll address the exact progression questions in the next answer and then start working on a Progressions wish list post.)

[Jim Eshelman]

Here's my thought process on that - getting the julian day corresponding to the progressed planets is I think as simple as:

(Pseudocode)

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)

Is that correct?

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.

However, there are important non-simplest cases that we need to include - things that (at the moment) I don't think are valid but really do need to be examined because (1) they represent a correct representation of Fagan (and to a lesser extent Bradley) positions, (2) many Siderealists wouldn't take us seriously without our including them, and (3) they really do need to be examined - we've never had the right tools to do this exhaustively even though smaller studies seem to have settled the issues.

I'll cover these in the progressions thread but they boil down to (1) allowing both the Q1 and Q2 progression rates and (2) allowing the argument (the pace at which time unfolds) be either even by the mean solar rate or uneven by the apparent solar rate. The two variations that use the apparent solar rate are more complicated, even though they ultimately follow the concept of your pseudo-code.

The apparent solar rate methodology will also be essential for the PSSR. Both Fagan and Bradley held that the PSSR used the apparent Sun, not mean Sun (uneven, not even) rate. Kenneth Bowser and I independently concluded that the PSSR worked by the mean rate, though I'd say this is based on too few examples and too little work overall. I'd like to put the way of testing this easily in everybody's hands rather than just conclude that Ken and I know what we're saying <g>.

So there are variations. Probably the progression options table should be able to pick from all four variants and then other things (like Kinetics) based on those progressions use whatever variation is selected.

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.

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.

Yes, I agree it's for an exact date/time. I think the options pages and landing pages are the hard part of all of this: The calculations themselves are straightforward even when complicated. These are techniques where the computer can shine and make up for the nearly HALF CENTURY we haven't been able to give this research the right attention.

BTW, if there is currently any (infrastructure or definition) reason this can't all be done for calculated ingresses, we have to change that. Some of these techniques are basic to the ingress system (and I've been holding off researching all the variations until we have the software).

Bottom line, yes, I think your above paragraph shows you've got this all sorted out in your head correctly.

At some point we need to consider how many progression forms to include. One could argue for only including secondaries. If TM becomes widely used, there will be a noteworthy minority wanting tertiaries. This is mostly the same as your original formula above (with a different progression rate) except that the angles are handled differently.

One further thing: For the sorts of things we're discussing now (transits, progressions, quotidians), I think we want to think about two separate delivery systems: One is just the calculation of a stand-alone chart. The other is more of a report outputting contacts by date etc. that they are exact. The 'calendar' reports, of course, depend on the ability to calculate the individual systems in the first place.

[Ember Nyx]

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?

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.

That would mean Noviens now and the rest of your 0.7 list being a 2.0 target.

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.

[Jim Eshelman]

No disagreement with the broad, expansive picture. Those are all important steps and moves (and the idea of webapp deployment possibilities, which also takes it to mobile platforms, is really great!).

I was tending to think of the first successor version or two (I hadn't thought past 3.0) being more feature additions than platform additions. This isn't to slow modernization and the other expansion, just to not rush all features into the first pushed version.

And yeah, menu work sounds good - I'm sure we can do better (I say that being enormously grateful for what we have). And regarding transits etc., I've been patiently hoping for the ability to put any chart at all "inside" (or "outside") any other - to get any blending similar to what we have with transits and progressions but with any two charts of any kind. This would seem useful as a step toward transits, progressions, and eventual synastry stuff. (I soooo want the cool synastry stuff but I know it will be way easier after a lot of other stuff is built ahead of it).

[Jim Eshelman]

Or, to say it another way, I've been quite willing (when release time comes) to say, "It doesn't look like much, you won't use it to visually impress anybody, but man-o-man it does things no other program does and is well-crafted to astrological practice for Sidereal astrologers. Oh, and it's free."

At the same time, I'd be even happier not to have to say the first part of that

[Ember Nyx]

I'm currently working on a design mockup for the various menus in Figma, and I'll share a link once I have that ironed out. I'm also doing some more research to see what is doable with Tkinter (the UI library that Time Matters relies on to render windows) and add-on packages. The research portion of that will probably take the longest, so I suspect the remaining bugfixes and more feature work will happen before that's ready - but just so you know!