TMSA 1.0 progress (mikestar13 design notes)

[mikestar13]

I'm back to working on TMSA 1.0 and am making improvements to the 0.4 codebase. The last change just finished today has a new way of finding the tmsa charts and options. First, the environment variable TMSA_PATH is checked. The value if set is the full path to the tmsa folder. So for example mine is D:\documents\TMSA, it would be possible to use a different folder name if desired such as C:\astrology. You only need to keep your charts in your documents folder if you wish to, but of course most users will. Mine is on a removable drive backed up to the cloud (not in the user documents folder), thus ready to transfer to the new computer whenever I get that worked out. If TMSA_PATH is not set, TMSA finds the users document folder and the path will be (document folder)\tmsa. On a new installation the tmsa folder and its subfolders (charts, options, and errors) are created. It's perfectly possible to store other files/subfolder in your tmsa folder, as tmsa only uses these three subfolders. On the rare system where TMSA_PATH is not set and the documents folder can't be found, the TMSA folder will be at C:\TMSA.
I've found a workaround for the finding timezones. Timezonefinder 6 depends on h3 which I can't build (I'm consulting with our other Python programmer named Mike about that), however the almost as good timezone 5 finder does not! I will also look into timezone finding from TMSA directly from Uber's web page, which will assure the timezone info is up to the minute current.

The 0.5 Preview thread is getting awfully long, and is now not accurately titled as the upcoming version is 1.0 now. I will announce progress in this thread from time to time, and all other discussion of version 1.0 is order. Jim you may wish to demote the 0.5 preview thread to a regular thread.

[mikestar13]

A productive day today, wrote lots of code for the aspect and midpoint listings. The framework is in place for enumerating all the bodies in up to three wheels in correct order. I'm in the midst of writing the code for checking what aspect if any is in effect for each pair of bodies such as trMa and rSa.

The procedure:

1. Check for any ecliptic aspect, save the aspect and strength score.
2. Check for any mundane aspects, and one exists if it is stronger than the ecliptic aspect (if it exists), save it.
3. If the user has not enabled parans, goto step 5.
4. Calculate the parans that exist (if any) and choose the one with greatest strength. If this stronger than the stronger of the ecliptic and mundane aspects, save it.
5. Return the saved aspect or return "no aspect" if none were saved.

Of course at each step I'm checking if Eris and Sedna are in use and which version of the Node (if either). The aspectarian and midpoint code is the most complex I'll need to write, but it is much better organized and hopefully more efficient than the code in 0.4, though TMSA calculates a chart so fast I doubt anyone will notice one way or the other.

I had a fairly lengthy dark night of the soul about TMSA, but I seem to have much of my old fire back.

[Jim Eshelman]

"Joy turned to ashes" followed by "The Return of the Phoenix," aka, Resurrection

Almost a digression because you probably have this in your mind, but: This complexity raises the question of what the base chart is (for use as a root epoch for precessional matters and the operational geographical coordinates).

[mikestar13]

"Base chart" is my generic term for the chart that is the base from which other charts, transits, progressions, or directions are derived. Normally it will be a nativity or event chart, but it might be an SSR (anlunars, SQ, PSSR) or an ingress, or any chart the user is calculating a novien for. I might have called it "root chart".

As for "The Return of the Phoenix" event, if I thought it were significant enough to constitute an actual new birth, I would treat a chart of the moment as the base chart. However, though it's important, I don't regard it as quite that important.

Noel Tyl wrote a delightful short story "The Case of the Missing Moon" about an astrologer who at end of the story cast as new birth chart for himself at the time of a life changing event. https://books.google.com/books/about/Th ... svDwAAQBAJ

[mikestar13]

I have the last Chart Option page (aspects) written covering ecliptical and mundane aspects and parans, the former two enabled by default, the last disabled. Managed to get everything on one page.

[mikestar13]

Good news: I will have the ability to cast the novien of any chart in 1.0.

The novien report will be a much simpler version of a typical report, as the following are not considered in noviens: angularity, mundane aspects, parans, midpoints. We still could have both classes of aspects and a limited comic state report with aspects to each planet sorted by orb. I assume the wheel will be drawn in the customary Moon on first cusp equal house format, though it's quite doubtful signs are relevant in the novien, and certain that houses are not. The default for aspects I think will be class 1 major dynamic aspects class 1 at 3° and class class 2 at 5°, with class 3 not used. I'm inclined to let the user choose the orb, but not to make soft aspects available as there seem to be no indication these are valid. These options are so simple I will let the user change the orb values when the chart is cast, also allowing the choice of single wheel (just the novien positions) or double wheel (also base chart positions--usually but not always a nativity).

[Jim Eshelman]

I agree with the above. - Possible exception, some think that soft aspects are equally valid so, presuming it's no trouble to leave it in, perhaps let them dissuade themselves of this in practice <g>. - I'm working up a mock-up of what I think might make good basic tables based on the Novien brainstorming thread (almost done once I add the aspects), I'll post it on that thread when done. (It's a LITTLE overboard, but there is a lot of space.)

[mikestar13]

Thanks Jim. That will help inspire me. Soft aspects will be made available, but off by default, and I will use option files for noviens as well.

[Jim Eshelman]

I've shown the first four Noviens of Moon and Sun (it fills out the space) but these should probably be off by default, too.

[mikestar13]

The problems with timezonefinder continue. On Windows 11, loading it causes the Python interpreter to crash with a null pointer exception. Previously versions of TMSA built on Windows 10 will still run on Windows 11, but I can't built or test a new one unless I disable the timezone lookup feature (latitude and longitude lookup use a different library and aren't affected. The world clock website allows users to lookup up timezone information by lat and long for dates 1/1/1970 and after. I can automate the process of querying the site and have the page with start/end dates, but user would have to fill in the time zone fields in TMSA manually. I hope this is not a dealbreaker.

[mikestar13]

The online time zone DB I'm working with looks like it will do the job. While I'm developing my free account will give me enough queries and then some, but when it's time to release, solunars.com will need to pay the $5/month for premium access which says no limit on queries. This page gives details: https://timezonedb.com/premium

[mikestar13]

Will do, I'll find more info when it gets closer to release, during development and testing, my free account key is more than enough. The procedure seems simple enough: you would purchase a $5 monthly subscription and receive a key, which you will send me via PM, so I can embed it the TMSA code, in lieu of my free code, which I will retain as a fallback in case the subscription should ever lapse. Lookup would still work, but lookups would be limited to one per second, all users world-wide. No apparent limit on total number of lookups. I will contact them and make certain I understand the terms correctly. Maybe my free key would be adequate for a while until user base grows a bit. The issue is not total number of lookups, but how many users will attempt to look up a location in the same second. My impression is that timezonedb is intended to be a free service, with heavy users subsidizing their costs.

[Jim Eshelman]

I think the free one is fine for the near future. The $5/mo isn't a problem, I'll sign up at once when needed, but I don't think we'll have that demand for a little while. (Once 1.0 is out, we need to talk about more aggressively circulating it.) I also wish we could get you a security certificate that would end Windows treating it like a suspicious program.

[mikestar13]

Working today. I have upgraded to 32-bit Python 3.11 and this necessitated some very minor code changes, but pyinstaller is working again (unfortunately timezonefinder still isn't), so I can once again build single file .exe's with no need to install any python libraries, as was the case with version 0.4.9.2. I'm also considering a 0.4.10 release to put the reverted minor angle formula, and the new method of finding timezones in circulation.

[mikestar13]

Regrettably pyinstaller only works the first time on a clean install of Python, it breaks on subsequent builds. So I will need to distribute executables via cx_freeze, which additionally installs Python library files and python.exe, but these will be out of the users' sight in the installation directory.