Solunars by Aldebaran Sidereal Academy

I'm curious whether those of you who use TM use one of its original design features or whether it is more of a bother.

Makestar13 created the way TM stores calculated charts this way:

• Within the Charts folder are folders (among others) for each letter of the alphabet (first letter of last name) and one for Temporary.
• Within each of these is a separate folder for each person (e.g., within the E folder is a folder titled Eshelman, James among others).
• Within that folder is the natal chart and any other charts (such as return charts calculated for the same natal and saved).

His idea, I think, was that all charts for the same person would be stored in the same folder for each of access. This only really works, though, for return charts and I never, ever, ever save return charts (they're too easy to recalculate in a couple of seconds). In fact, I sometimes accidentally save them and then have to go back and bring them up so I can delete them.

This might be useful to me if it would store event charts - it would be quite cool, I think, to be able to have charts for the exact time and place of major events in a person's life to bring up over and over again for research. But there is no feature to store these in a person's folder - they'd have their own name and that would create a new, different folder.

By default, all return charts are calculated as temporary charts. You can change this with one click, but that's the default and probably what most of us always do. Instead of being stored under the person's name, they are stored in the Charts\Temporary folder and deleted on the next restart of TM. This is good IMO. (Note: If you then recalculate a return, it is saved in the personal folder, not in temp. I'm not sure why. I think this should also default to Temporary.)

So here is my question...

Does it help anyone that each natal chart has its own folder that theoretically could hold multiple charts for one person? Or do you also have (99-100% of the time) only the single natal in there (and some occasional accidental saves that you have to go back and delete).

If nobody uses this design feature, I'm going to suggest we get rid of it. Simply the architecture. Have a folder for each letter of the alphabet and store each chart there, rather than in its own sub-folder. It saves a few clicks every time you open a chart. - However, if the current architecture is useful to you, we probably should keep it.

I'm sure it's really easy for MikeV to change the program so that it works this way going forward. The more tedious part would be dealing with the existing charts all of us already have. (Mike, if we go this way, I have a backwards-compatibility logic flow in mind to suggest.)

I should also mention that this question may become moot when a smoother chart search is implemented. MikeN said he'd already built this - based on his earlier Python project for cataloguing his music collection - but we lost all that and don't have access to it, so it would have to be created anew (and may not be an early priority).

I might as well add the logic idea here: Mike, these are just random thoughts flowing through. My first thought was a conversion tool to convert existing file structures to a new format. While that might be easy in theory, it's probably a pain in the butt to failureproof. Also, a one-time converter seems prone to leave people behind if everybody doesn't follow exactly the same upgrade path etc.

That got me thinking of the larger picture of backwards compatibility. We've already talked about version-stamping each chart in the .dat file and reading that when a chart is accessing - then automatically recalculating it if it was calculated in a now-incompatible earlier version.

Along the same lines of thinking, I see no reason a given Alphabet Letter folder couldn't have a mix of foldered and unfoldered charts. That would let conversion progress non-dramatically over time. It would work something like this on all future versions (I don't know how tricky the first step is to program):

• When a chart is opened, do you (or can you) capture the full file path? (I assume you need this to open it.)
• If so, anything in Documents\charts\lettername\anyfolder should be automatically recalculated in Documents\charts\lettername and the anyfolder folder deleted.

This would clean things up as we go.

Just a first (incomplete) thought.

Agreed. The extra layer has always felt excessive, and a use for it has never come up.

Jim Eshelman wrote: Sat Aug 24, 2024 9:47 am Along the same lines of thinking, I see no reason a given Alphabet Letter folder couldn't have a mix of foldered and unfoldered charts.

That seems quite doable.

That would let conversion progress non-dramatically over time.

FWIW, at my day job (as a dev), I quite often have to deal with the question of migrating these kinds of data formats. My preferred solution is exactly this - even though it plays out more like 50/50 at work in terms of "migrate everything all at once" versus "have 2 formats and gradually migrate things."

When a chart is opened, do you (or can you) capture the full file path? (I assume you need this to open it.)

Yep, I need the full path to open it no matter what, so I will have access to this.

If so, anything in Documents\charts\lettername\anyfolder should be automatically recalculated in Documents\charts\lettername and the anyfolder folder deleted.

This would clean things up as we go.

That is essentially what I would have proposed. It is fully backwards-compatible, and flattened directories are going to be easier to navigate anyway. (I didn't write most of that navigation logic, but rewriting it like this is a simplification.)

I agree with Patrick.
Then again, it's very nice to work with TMSA and easy.
Regards, Flo