[15:00, 31 Aug 2023]

I was hoping that this wouldn't be the case, but it seems that the time until I obtain a #Tetrinsic [gd0041] powered device is going to be longer than I hoped. More information can be found in this project log. 

I'm looking into pivoting to a promising custom linear motor solution that I'll write about later, but custom solutions mean unforseen problems. It also means that I have to redesign a lot of things, including the PCBs.

I also expect that this isn't going to be an isolated case, in that my other projects are going to have setbacks and delays of their own, meaning that the cost in development time will too high.

The most notable project to get shelved is #Tetent [gd0090] as I will be focusing on #Tetrescent [gd0150].

[2 April 2023]

So I was researching into input devices, and I had an idea: what if there was a way to use the SpaceExplorer I have in a shelf as a 2D mouse? Hear me out here!

The main reason it was in a shelf was because I didn't want to have to keep swapping my hand between the keyboard and the mouse, and 3 devices takes up quite a bit of space (but that's mainly because a full sized keyboard is already quite large). 

I've considered getting a trackball mouse to further reduce the amount of deskspace needed, but mainly so that I didn't actually need a desk surface to use the mouse accurately. Unfortunately, none that I could find had enough programmable buttons, and I only need 4 (+2 for left / right click). 

The SpaceExplorer I have very much looks like an earlier iteration of the SpaceMouse Pro. I'm not really sure why 3DConnexion dropped support when the inputs are electrically identical. 

The idea is simple:

1. Move the cylinder X/Y like a TrackPoint to move the cursor
2. Tilt the cylinder in one of 8 directions to send an event (a bit like the SpaceTraveller but not using 8 physical buttons). East/West will be the left or right clicks and up / down would be for scrolling, leaving 4 user programmable "buttons".

3. The 'Fit' key on the SpaceExplorer toggles between mouse and spacemouse mode. The reason the "2D" button isn't used for this is because it's much harder to press with the thumb, and unreachable if the SpaceExplorer is on the right side of the keyboard.

[4 April: Morning]

Ok, so I've been digging though the forums for clues and I've got part of a solution, and have learned some things about the undocumented XML along the way. I've got cursor X/Y and scrolling working nicely, but I haven't yet been able to get mouseclick events or macros on the cylinder.

So first, navigate to 

%appdata%\3Dconnexion\3DxWare\Cfg

There should be a Global.xml file. I edited it to make it look like:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Global Default="false" xmlns="" CfgFormatVersion="1.3" ThisFileVersion="2.0">
    <CfgProperties>
        <ID>ID_Global_Cfg</ID>
        <Name>STR_GLOBALCFG</Name>
        <InheritsFromID>ID_Base_Cfg</InheritsFromID>
    </CfgProperties>    
    <Settings>
        <InstallerAutoCheckForUpdates>true</InstallerAutoCheckForUpdates>
        <LastAutoCheckForUpdates>3-4-2023</LastAutoCheckForUpdates>
    </Settings>
    <ButtonActions>
        <ButtonAction Type="Driver_Other">
            <ID>Driver_Desktop_ToggleGrab</ID>
            <Name>STR_DRIVER_DESKTOP_TOGGLEGRAB</Name>
            <Image>
                <Source>[driver_images:Driver_Desktop_ToggleGrab.png]</Source>
            </Image>
        </ButtonAction>
    </ButtonActions>
    <Devices>
        <Device>
            <ID>ID_Standard_3D_Mouse</ID>
            <ButtonBank>
                <Button>
                    <Input>
                        <ActionID>V3DK_FIT</ActionID>
                    </Input>
                    <Output>
                        <ActionID>Driver_Desktop_ToggleGrab</ActionID>
                    </Output>
                </Button>
            </ButtonBank>
        </Device>
    </Devices>
</Global>

Driver_Desktop_ToggleGrab is a specific action that changes the Desktop.xml file (that you have to create), specifically toggling:

<Grab>Hard</Grab>
<Grab>None</Grab>

 In "Hard" mode, the driver will lock onto using this .xml file everywhere and never let it go. However, if it's on "None", the driver acts as usual, selecting the .xml that relates to the application currently in focus. 

The names for mapped buttons (eg V3DK_FIT) can be found in

Program Files\3Dconnexion\3DxWare\3DxWinCore64\Cfg\Base.xml

 You can use the driver software to change the button map in some random program, look in the same folder as Global.xml / Desktop.xml and you'd get something like "HIDButton_13", which you can then look up in Base.xml, such as:

...
<ButtonID>HIDButton_13</ButtonID>
<V3DKID>V3DK_1</V3DKID>
...

 Anyway, next was to create Desktop.xml in the same folder as Global.xml

<?xml version="1.0" encoding="UTF-8"?><...

I noticed this fact maybe 2 weeks ago now: my designs have a lot of square diamonds but not a lot of squares. From the grills in #T^2 TyMist [gd0138] to the large squared diamond #Tetent TestCut [gd0139] makes when in use, it seems that I like square diamonds.

Now, the icon logo used squares because I like(d) squares more than circles. Back over a year ago when I designed it, Teti was the only design with diamonds. Now, thinking about the hardware and software designs I have planned, it does seem like I'd be using diamonds more than squares. I probably might have realised this sooner since that was one of the reasons I liked the game Strata:

My main worry was that it would look sharp... in a bad way. I really should've just gone into Fusion360 and made the change instead of thinking it over another 2 weeks.

It looks brighter, like the diamonds are sparkles. Then I switched back to the current logo

and my first thought was genuinely "Who is this plain and bland imita-- oh". Maybe it's just because the logo is over a year old and it's starting to feel a bit stale, but it just makes me think more towards "office" and... not as energy-emitting.

I'll probably realign the diamonds before rolling it out (see aligned new logo below), but otherwise it looks fine. It also looks similar enough to the current one that it should still be recognisable and possibly interchangable. HP has 2 drastically different logos; I think I can get away with the same logo but one has rotated squares. I'm already imainging it opening up new potential motion graphic animation opportunities.

[14th Feb 2023] Rolling out the new personal branding now.

The curve of the brackets has been slightly tweaked, which means that the icon and full kelvinA look slightly more fluid and less orthagonal.

I also decided to put a filleted chamfer in the E because I use those extensively in my designs and so shoud be part of my brand image somewhere.

Earlier today, I found out that The Verge just got a fresh new look (see below) and after seeing their new logo, I thought I should see if I could freshen up my own now that it's nearing to be a year old.

Here is the old (top) and new (bottom):

From using it for a few months, the only thing I thought needed improvement was visibility. The old logo became a hard-to-decipher blob a little to quickly for my liking.

The main thing I did was increase the negative spacing from 0.25 to 0.375. A nice side effect was that this made the line in the A a perfect 1x1 square. This means that I could potentially animate from the 3-dots logo to the kelvinA logo and match up the dots.

Next, I changed the line that comes from under the n so that it looks continuous. The base idea of this logo is that it can be made out of 2 lines. 1 line is the loop in the k and the other line creates everything else. The single-line idea was a feature of the verrry first kelvinA logo I made in 2015 all the way up to 2021.

The 2 above are made in Powerpoint, and the newer ones are made in Fusion 360. The hours lost trying to get the sketch solver to cooperate... (FreeCAD wasn't any better or worse.)

Moving on, the next thing I did was reduce the width from 27.5 to 27. The idea was that I could animate 3 logos (each logo is 9x9) with a 0.25 gap, but I think the more predictable 3:1 aspect ratio is a more favourable solution. This change made the e look a bit compressed, so I added a fillet to the bottom of the square. It now looks more e and less E, as well as the filleted square looking a bit like a leaf (I like leaves).

The biggest thing that's changed that I didn't even notice until right now (when I had to export the logo so that I could have a side-by-side image) is that the v has become noticably larger. I think this is a good accidental thing though because now the v looks similar in size to the n, the sharp edge of the v noticably cuts through the bottom line (I like sharp stuff such as Beyblade performance tips, gyro tips and the tip of a pair of compasses, and I don't like ultrarounded Googleization) and it accentuates the overall shape (of looking like a 2D spaceship sprite) better from a distance. (The biggest problem I had with the 6 years of the old-old logo style was that I could never just press "align centre" and the logo actually look like it was centred. While the n might look wider than the e in the 2021-present logo, mathematically it's the same.)

I started reading https://technologyconversations.com/2013/12/20/test-driven-development-tdd-example-walkthrough/ and got to the subheading "Requirement 2: For an empty string the method will return 0" yesterday.  I like their example, which is an "add" function. It shows the potential issue that even a simple sounding feature could have a bunch of smaller requirements that can be all too easy to conglomerate into larger but more descriptive requirements. Now, after sleeping on it, I've come to the conclusion that this might be a realistic way of getting progress done on projects like #SecSavr [gd0036].

The Deliverable

I plan projects based on the "deliverable" that Me In The Past requested. This is similar to starting at the end of a maze and drawing a line to the start. In this case, it is me mentally simulating what it would've been like in an alternate reality where I bought my project as a kit. I know that there is a high chance that the deliverable would still need refinement, just like buying a product and voicing suggestions for improvements, and so the main goal is to reduce the chance of having to start from square one because the deliverable that Me In The Past requested isn't what Future Me now requires. 

Eventually, I'd converge on a project solution such that the only way I'd properly compute a new solution is if the deliverable of the current solution was insufficient (in other words, going back to the drawing board because the prototype failed). Even if the deliverable works, I know that the probability of a perfect design first try is very low.

Relating to Test Driven Development

Thinking about this, it just seems that I'm just doing 1 large (and therefore complex) test case instead of what was suggested in the article: creating 1 test case from 1 requirement (that fails since nothing has currently been designed), designing to fit that test case only, passing the test case and moving onto the next one.

Now I need to think about the way to order the requirements to reduce the chance of a large refactor effort down the line yet still have the easier requirements closer to the top. Fusion 360 (and especially FreeCAD that is tackling the Topological Naming Problem for the future 1.0 release {I wasn't expecting them to ever get a 1.0 out for decades}) isn't very friendly when it comes to CAD refactoring (and is paritially the reason why I'm researching my options of writing my own CAD software in #enSweepen [gd0096]). In the present day, this and the desire to limit the filament consumption for 1-off prototypes due to cost and the environment means that my interest to reduce refactoring works against getting prototypes and tests out more frequently. 

There's obviously a balance somewhere in there. Right now I'm likely too far on the "reduce refactoring" side of the spectrum to productively and consistently progress in my projects and will try to compute a new solution to this problem that incorporates ideas from Test Driven Development.

Current tags as of: 

11 July 2023

• [C] = Coding

16 June 2023

• [L] replaces [EM]

02 June 2023

• [X] = Experiment / Test
• [EM] = Electronics Modelling

14 Feb 2023

• [S] = Software (for primarily hardware projects)

14 Jan 2023

• [B] = BOM

09 October 2022

• [A] = Announcement / progress update
• [G] = Generic progress update
• [E#] = Edit number #
• [M] = Modelling
• [P] = Parts received / Part Printed
• [P2] = Part 2 of previous log
• [T] = Thoughts
• [R] = Research

I'm putting projects that I'm not mainly working on at the moment on the shelf. These are projects that I don't see myself getting meaningful progress done between now and the end of September 2022.