Update post history - compilation

This is why there is so much concern about not getting a major update for nearly 17 months. We all can understand delays. Well, most of us. But I’m putting up this record so Waytools can maybe better realize how much this problem has grown.

The following dates sometimes ran into conflicts - the date listed on the Waytools “Activity” page may show one date, but clicking on the post would then show a different one. I remember there was a period when something messed up many dates on the posts so this is probably part of that. I opted to use the date on the Waytools activity page.

I read, or at least scanned, just about every post WayTools made going back to June 20 of last year. I may have missed some references to making an update, but I doubt it would be many and especially doubt it would matter to the basic issue.

HOWEVER, as I was reading through the many posts for many hours, I also found quite a number of things that could be considered “updates”. No, not the bigger one we have been waiting for, but certainly some good information.

I may go back yet again and create a similar list of those little updates to get a proper, complete, record of the past almost 17 months. But I’m sure not looking forward to that process. This one was hard enough, but scanning through them again, trying to find what was sometimes a single sentence of useful update info will likely be far more time-consuming.

Well, we’ll see. Meanwhile, the following are the statements about upcoming updates. If there is not a blank line between statements, it is from the same post. If there is a blank line, it is from the same date, but a different post.

I put an asterisk in front of the date of some to designate dates where the statements were particularly problematical to me, considering the update wasn’t made. But I probably didn’t do it every time I could have.

June 20, 2018
We’ve updated our servers to reflect our Fall release estimate, and we’ll post some technical details soon about a major upgrade to our infrastructure firmware to accommodate user requests and facilitate service in General Release.

confirm we are working on the update info now. We’ll be updating our server on Thursday to acknowledge summer time window, and we’ll follow up with info on current focus areas within the next week

June 21, 2018
We’ll post some tech details in our update, but it’s mostly the firmware subtleties. We fix those pretty quickly, but we need reports on them first, and good logs.

June 29, 2018
just a heads-up that we still have a few items to work through with the dev team before we post our evaluations of the current priorities. That’ll take a few days and we’ll likely will have the new post up around the time of the July 4th holiday.

*July 5, 2018
editing latest data, and a lot on the plate, so likely during quiet time on the weekend.

July 8, 2018
Working through update topics this Sunday, will advise soon.

July 9, 2018
Getting through our action items right now, will advise in advance of posting.

July 16, 2018
next up is posting some technical background, and that’s a function of some decisions currently being discussed by dev team.
Main thing we’re deciding now is how to manage transition to newest infrastructure code. Want to sort that out so we can give a coherent insight into the work we’re doing right now, and how it facilitates the overall release plan. Dev meetings this week are aimed at settling that.

July 24, 2018
Note - what we’re working on isn’t the volume of text, but rather the team decisions about how best to complete the migration so it’s most favorable for release. That is working through a lot of dependencies to minimize them. We’ll advise as soon as we’ve completed a coherent analysis and team agrees on most efficient path to help us advance quicker.

August 19, 2018
Got our hands very full this week, but will circle back soon to give example details of what we’re doing now.

August 27, 2018
We’ve got our hands full at the moment, but will aim to post a summary later next week.

Sept 9, 2018
we’re putting together descriptions to provide context for the infrastructure code we’re focused on right now. That code will accommodate the requests we’ve gotten from users, and will provide a good foundation to support the sort of needs that general release users will likely ask for. We’ll put in a few more days on those explanations, so you can all have good visibility on what remains for GR

recent asynchronous demands have been more intense than expected, so quiet time’s been a bit hard to come by. That’s what usually is needed to write-up detailed summaries based on latest dev results.

Sept 13,2018
Sorry for not posting more details now, we definitely care a lot about you, and every customer who wants this new technology. We have quite a lot going on in this period, and we have to prioritize progress on GR shipping over PR content. We’ll give you some detail insights as soon as we can, but the focus on engineering action now is really what gets a great product to your door.

Sept 19, 2018
will update fairly soon, after working through decisions relating to transition for new code fork. Those decisions are operative to set overall plan.

Sept 26, 2018
There are complex interdependent choices which we are deciding now, and we’ll update our forecast soon.

December 15, 2018
We’ll reveal some interesting tech details after we’ve proven a few more steps in our dev labs. Not ready to comment publicly yet, but think you’ll really like the upsides for users. They’re significant.

February 5, 2019
we’ll unveil more tech details about the architecture advances soon.

March 7, 2019
we will provide some meaty tech details later this month.

we’ll be updating on tech details of the new fork later this month

March 30, 2019
Will publish a tech update soon, but not sooner than a week from now.

April 11, 2019
We’ll make some official announcements in a few weeks, but features and price will advance.
All existing preorders get to keep their original pricing, and will also gain all the added benefits.
The preorder deal is better than currently announced.

April 22, 2019
We’ll post a more in-depth TechTalk about the foundations for the new firmware and its significant advances in capability, after we complete a few more of the migration steps.

May 20, 2019
we’ll soon be publishing details of the new infrastructure firmware - around end of May.

*May 31, 2019
Just letting everyone know we expect to post our TechTalk update with a lot of exciting news about TextBlade’s powerful new firmware infrastructure, on Saturday evening after 9 pm pst

*June 1, 2019
Will be working on it for a while yet tonight, so please get your rest in the meantime.

*June 2, 2019
got some good content settled this evening, and want to cover a few more points of interest.

Will get some sleep now, and finish editing Sunday to post for you all.

Sundays are good quiet time for this kind of work.

Get some rest to see the Keynote. We’ll be busy on this for a while yet tonight.

*June 3, 2019
Quite a lot of ground to cover, but getting though it. Think you’ll like what you learn in this update

Gonna keep at it for a while to try to get this one off the plate.

Think cognitive productivity will improve to get it done faster after a few hours rest. Will come back at it fresh to finish up.

June 6, 2019
thanks for your patience while we finish the update. It contains many things you’ll like.

June 11, 2019
Although we’ve posted many points relating to our infrastructure work, there’s some important and exciting dimensions that we know folks are anxious to learn. We own that task, and we apologize for the time it takes to work through it. That onus is on us, and we feel it profoundly every day, until our update is online and it’s put behind us.
Reporting tidbits of data is not hard, we’ve been doing that, but to embrace what folks really want, and provide them enough context and depth of detail to understand it - that takes much more thought and care. Much of that involves not writing, but instead working through important decisions by our team about how we handle certain technical and business choices that defend our customers best interests. Some of those choices have more aspects than you first think, so you must work to settle any loose ends before you announce.

*June 12, 2019
We know what you need, and we’re making it. You’ll learn more about what we’ve done in our post.
Rather than declare a time that tries to please, we’ll just complete our post expeditiously and put it online.

don’t worry, this self-regulates. It’s simply too excruciating to stay in the soup of doing it

June 15, 2019
By the good questions raised above, you get a feel for why there is a lot to cover. The update goes into some good depth on these points, and we expect it will be helpful.

June 18, 2019
we’ll focus on finishing our main post which should give a bigger picture of what we’ve built.

June 19, 2019
we apologize for delaying our post. There were more points to decide than we had considered, and several asynchronous tasks added to our load. As we mentioned, we’ll post soon and hope it’s helpful to you.

July 11, 2019
As we said earlier, better to let our post give the full picture, and drive the date. We’ve been handling many time-intensive requirements which we believe will settle soon.

July 23, 2019
team has everyone focused on manufacturing facilities logistics tasks right now. Will post again after we get that done, which will be very helpful for shipping. Will make some comments next week

Sept 30, 2019
Will put bandwidth toward editing tech update next week, and post soon after.

Well, as to content, we don’t think folks are expecting a Hemingway, but the TechTalk should give everyone a good understanding of what we’ve been doing, and our timing.
We’ve provided small posts along the way, but nothing will quite satisfy like the big picture. So we’ll let the post itself do the talking.
Please nag us next Tuesday dbk if you want to follow up, right now we’re full-up laser focused on patent legal documents for Friday.

October 8, 2019
Patent stuff went excellent, so we’ll be putting bandwidth toward editing update for you during this week. Made considerable firmware progress in the meantime, and hope to post details for you soon.

October 16, 2019
Working to satiate that hunger soon.
Engineering milestone review went well today. Test data is quite encouraging.
We believe you’ll like what you learn when we announce details

October 30, 2019
will focus on that once the rest of the amazon servers that manage orders are likewise upgraded with new certs and security code.

November 7, 2019
Admin distractions often grab cycles for dull but necessary tasks. Definitely more fun to write about cool engineering advances the team has built. That work has marched forward in the meantime, and we’ll discuss a few in our update.


Lest anyone doubt dbk’s independent thinking - pls see above.

Until we’ve shared the details, it’s fair criticism.

The engineering that takes us home however, has been our focus, and is advancing well because of it.

Must point out when WayTools get their timing predictions right.:wink:

Still looking forward to a TextBlade!

1 Like

:blush:Thanks Bryce.

While taking our flogging, it does help to hear cheerful reminders of why we do this thing.

In SpaceX vernacular, NET = no earlier than.

Which is how Elon’s optimistic goals are reconciled with practical execution by their team.

That cross-dynamic produces sci-fi-grade spaceships, a decade before sovereign nations.

As I said in my prior long history post of announcing updates that don’t happen, I also found a number of posts that did contain some update information. I have no idea how far I’ll research this, but I figure I can at least get started, but do it a little at a time, unlike my prior post.

It will also be hard to remember if something said is a repeat of old information or something new. However, some repeats can actually be important. For example, if at some point they say that switched characters have been solved (that was a problem at one time), then if they say it is still fixed a year later, that matters. It probably means the fix really is permanent. Or if they say the hardware seems to be solid, it is good if that is also the feeling after a longer time period.

Anyway, let’s see what I can find. I’m not limiting this to just techical update stuff, but anything that gives us any insight into what they are doing. And I’m probably going to leave out some stuff that would require more context to understand. This job is too big without including that!

June 21, 2018
We’ll post some tech details in our update, but it’s mostly the firmware subtleties. We fix those pretty quickly, but we need reports on them first, and good logs. That incidence is narrowing nicely now, and they usually surface only after long term daily pounding by hundreds of diverse users. Around 95% of users have good operation and don’t experience one of these details, but we want to get that number very low so we can reasonably scale our support for volume deliveries.

June 25, 2018
30-35 hours operating time per charge is normal spec.
So depending on number of hours of typing per day, it typically goes between one week and one month on a single charge. [DBK note: This isn’t new, but it may be the first time it was put this way. Previously it was described as a 30 day battery but, of course, that depends on usage each day. As something that was originally promoted as a mobile keyboard, it was probably reasonable to think the typical use case may just be for short periods, some days of the week. For me, it sure isn’t a month, but I have it on a great deal of the day, every day].

June 29, 2018
Remember that in classrooms, especially for young kids, you want to organize and keep track of small parts, so there are mechanical provisions to retain the blade set and identify them. In-class use does not require (and in fact must prevent) kids from putting TextBlades in their pockets. Now that full keyboard functionality is in this compact 1.5 oz core, you have a lot of design freedom to accomodate many edu use cases. It’s very easy to embed that tiny core in a larger deck that keeps it secure and in sight.

July 1, 2018
Laptops with TextBlade technology embedded in them can stow the keys pressed.
So you can have both 2 mm full travel, and a super thin package, all in the same machine.
This was not possible before, and it’s a lot better. [DBK note: This is part of a more detailed post as to why a regular keyboard can’t do these things].

July 2, 2018
Examples include some unexpected scope to diagnose and fix widespread bugs with Bluetooth or USB3 ports on their tablets or PC’s. Or subtle filters that an OS may apply when keystrokes arrive too fast. We had to devise accommodations for the quirks across different machines.
We’ve provided extensive logs to the major vendors like Apple and Google to work through these issues, and they have both been fantastically cooperative. The latest releases of their OS’s are significantly improved, and now the experience is pretty smooth even on edge cases.
We also have the burden of goof-proofing the configuration of 6 slots for a user’s array of different machines. This involves new kinds of documentation and self-recovery automation. There’s lots more items beyond these examples, but the essence is that you have to address all the little friction points, even those not on your side of the fence.
That’s going well, and we’re grateful for how the major vendors have responded with their part of the process.

July 4, 2018
Interested in this case of space-hold entries.
Right now, here’s how it works -
Tap space = space character
Press space, tap another character, release = green shifted symbol character
Press space, hold for a bit then release = null entry. (Assumes you changed your mind about a symbol.)
So depending upon what you want to do with the space bar, it may make sense to add new functions.
We can for example, add contexts to the inference engine to produce different outputs as needed. So mapping these more nuanced cases is very interesting to us. [DBK Note: Just thought it was interesting how many basic things have to be done, just for the space bar. And also how they think they can do more with it in the future].

FYI - We have previously made a feature that recognizes a gesture on the SpaceBlade as a space repeat command.
To make this force a repeat on the host OS, we have a few methods. We can hold back the release code, or we can send a synthetic pulse train - as if you were repeatedly tapping the space character.
So even though the host controls space repeat, we can drive it based on user intent.
This gesture for this space repeat is something we’ve tested internally, but we’ve not made it part of any of the consumer releases.

July 6, 2018
Lots of options here - group can comment on a few that dev team has discussed -
Double tap = space repeat for as long as 2nd tap is held. Gets adobe hand tool.
Set SpaceBlade hot corner to space repeat.
Map space key to an additional location on keyboard. Can be held just like spacebar to get hand tool.
Lots of other gestures are possible with sensors built into SpaceBlade.

July 7, 2018
Option 4 - ‘fat press’ thumb spanning multiple sensors.
Option 5 - sweep thumb across to toggle state. No press needed.

Option 6 - Two, three or four fingers are all possible to read. So that’s an option too. It’s multitouch. These input signatures are not mutually exclusive.

July 17, 2018
The current app is on the iOS platform, but we will support android once further changes aren’t needed to the initial iOS app. After GR, we plan to make the app platform-independent, so not only android, but linux, windows and all other users can have direct access to configuration controls from their native systems.

Ok, so looks like there is concurrence emerging here.
Add ModKeys to map editor as independent keys
Allow remapping of hot corners to include independent ModKeys
Provide sticky key tap mode config option for ModKeys

July 18, 2018
Android-native app exists in prelim dev form. Once the iOS-native app is validated and functions are locked down from treg, we will do the main sw work to render a full consumer android version. This work will start after GR.
We have a separate dev path to provide a web-based, platform independent config tool. More work than just android-only version, but this will allow any user on any platform with cloud access to perform all config functions without need for iOS or android. Planned after GR, and expect to have it after android version. Ultimately, full platform-agnostic config tool is the main goal for the steady-state.

July 20, 2018
working on an emacs map now, and should be able to let you try it out next week.

July 25, 2018
this first step provides a new map for emacs users, where CTRL is mapped to both the home key and the left hot corner.
Emacs users can use either location, or both, and can also delete any unused location and replace it with other functions via the MultiMap editor.
This provides a way to have CTRL where emacs users like to have it, right now.
After we’ve migrated over to the new code fork, we’ll also update the map and macro editor to allow placing the CTRL key at any arbitrary location, as well as including it into macro sequences.

Yes, combos and scripts on a single location are part of what is contemplated with the revised editor, once we’ve migrated to the new code fork infrastructure. [DBK note: this has to do with being able to put just a modifier key or a combination of modifiers on a single key, other than the present default positions].

July 26, 2018
new features like tap for sticky CTRL will be implemented via the updated infrastructure code, which we’re working on right now.
Pinky Ctrl-A to support legacy editor styles, like the emacs case discussed above, is one of the user requests for specialized use-cases. It’s a good example of why we invested more to expand the software infrastructure.
For general release, we have to make sure there’s plenty of capacity in the code footprint to quickly accommodate any needs that emerge as the installed base grows. That user base will quickly increase a thousand-fold. As we start releasing high volume, staff is typically very busy the first few months. We won’t have a lot of bandwidth to focus on fine needle-threading then, so it’s wise to resolve any of this kind of stuff in advance. Just to be clear, while there’s a ton of cool feature ideas from users, we’ll get to those after GR. Right now, our focus is only on what might interfere with a reasonably common use case.
Users get to liking TextBlade in their main location, and then want to use it in other locations - not just a desk or table or bar, but on a couch, easy chair, or even bed. And with lots of different screens, with all their different case sizes. Users have told us they really want such an accessory, and some have even improvised devices on their own. So it’s beyond just a casual want, and has evolved into more concrete demand. We couldn’t find anything on the market that did the job, so we built it from scratch.
We’re now testing some of these new accessories with users. They’re not announced yet, but we’ll add them to our store after GR.

July 29, 2018
Updating our data structures now to open up lots of codespace, so we can respond quickly during GR.
New structures will also provide more generality so we can update more thru just fast cloud data changes.
Once installed base goes way up in GR, support needs to be very easy to keep response latency quick.

August 19, 2018
Optimizing certain infrastructure code is focus right now, to make response to customer support needs quicker and simpler for general release.

we do have a wired mode option in the works right now.

it’s done without changing the design, and without any ergonomic interference.

August 20, 2018
We’re concentrating right now on infrastructure firmware code updates that support several improvements, including this wired mode. Completing + validating these greatly simplifies support for general release.
Will release basic wired mode first. Fancier modes will be added by OTA update after general release, to let GR proceed sooner.
New wired mode capabilities -
Automatically charges TextBlade while in use at desk. Always topped-up tank whenever you grab and go.
Smart charge management to guarantee no risk of overcharge when connected long term.
Jumps to all devices fully supported while wired.
Supports direct USB link to local wired host.
Plug and play pinless pairing automation to wired host.
Most above features will be through OTA updates after GR, but infrastructure will be in place day one.


Continuing the examples of info from Waytools since June 20, 2018.

August 24, 2018
TREG users reported ink wear in heavy use, and we have since done several test batches with stronger and multi coated inks that show about 5-10X longer life. We’ll be using those for GR.

For every hardware product, like an iPhone or a Tesla car, there are constantly occurring small hardware adjustments going on under the hood. This is happening every month of manufacture for any of these high volume products, and it’s true for us too…
An example with TextBlade would be the tolerance for the glide tracks for our molded keycaps. They are more precise, and more durable, and maintain their precision really well now. If you looked underneath these parts, side by side with your own eyes, you wouldn’t see a difference. But it’s real, and you feel it. It’s even more taut, more quiet, and more smooth in its force curve. If you ask any TREG user, they can speak to this.
And this also improves our process yield which lets us scale volume faster, so we can execute our ramp quicker for all our customers.
This example is a small thing, but there literally are dozens of these small things going on at any one time, and they typically don’t stop after general release. Our job before general release is to do the ones that will make a material difference in the initial user experience at scale. And this in turn minimizes the support load, so we can be very responsive to people who truly need our help.
So yes, we are making hardware improvements all the time, and even though most are invisible, they still matter.

August 28, 2018
while wired mode requires the new code, we don’t need to hold back release to validate wired mode, so it won’t gate release.

wired mode goes direct to USB without any Bluetooth latency. Great for gaming use.

August 29, 2018
We agree that it’d be nice to have a sort of ‘power-sleep’ mode where it could wake in an instant.
For daily covenience, it could go first to power-sleep for say, several hours, and then go to full sleep for bigger power savings in longer rest periods.

Sept 1, 2018
agree that access to boot options from TextBlade while in wireless mode is desirable.
Pretty confident those key codes are indeed already sent by TextBlade to the host.
Likely cause is the same as what we debugged together with Apple for how MacOS handles file vault.
The issue there was that Apple’s keyboards use an older protocol, not BLE (Bluetooth low energy). So MacOS wasn’t loading the BLE driver before logon was already complete. This blocked password logon from BLE keyboards like ours, and the Microsoft folding keyboard.
Apple was very responsive and fixed that MacOS issue once we had provided them documented logs, and now the latest releases handle BLE FileVault unlock just fine. Really grateful to Apple for their detail follow-through to resolve this.
We’ll talk with them about boot options too, to determine if they see the same issue here. If so, it should be possible to move the BLE stack to load at an earlier point in the bootup sequence, so it’s available to handle the boot option selections.

Sept 22, 2018
FYI - we built (and patented) alternate configurations with split keys for index and pinky fingers. So 12 keys total instead of 8. It wasn’t as good as we expected.

Sept 27, 2018
TextBlade has 4 specialized processor cores in a custom-built hi speed, low power intelligent network to achieve finger sense temporal accuracy that’s much faster than legacy key switches. Conventional touch controllers don’t have the sensitivity / noise immunity to meet the performance requirements for our multitouch keys, so we developed our own controllers from scratch.

October 12, 2018
FYI - latest Bluetooth protocol advances are all in the new infrastructure code fork we’re testing internally right now.
This has been an intense focus of dev team’s work that we’ve not yet posted about.

October 16, 2018
Thank you for your energetic and loyal support.
It will be reciprocated with a TextBlade, and some other goodies too. [DBK note: so apparently something is coming with the textblade early orders - but the question is, is it something besides the special gift they referred to in the past].

October 30, 2018
Something better for travel than a cover is in the works, which should cover that need.


Didn’t plan two posts today - just wanted to get at least a month or two’s posts put up each day. But as I started to get a head start on tomorrow’s work, it turned out there wasn’t much in November and December so I can post today:

November 18, 2018
we’ll ship new fork to treg first, and then to GR after treg users confirm.
When we start releasing to treg folks, that’ll give a better feel for GR timing.

test criterion for new infrastructure is to see that it matches current version.
That’s a lot easier to do, and will hopefully go much smoother and faster than the initial treg validation.
That first time around, we had to go from zero to full reliance as the daily typer, so we had to identify and address any emergent needs. That’s an extensive discovery task, which was quite a bit more work than now just certifying the same performance that we’ve already shipped.

November 24, 2018
We will replace all keycaps on all current inventory for general release, using the best performing ink/cure combo.
That swapping process is very quick to do, so we will do it just before GR, to make sure there aren’t any other requests to address.

December 27, 2018
we’re well into the migration to the new code fork now, and aim to get treg validation within winter. [DBK note: Obviously that didn’t happen oas planned].

Already got a lot of functions migrated and testing successfully internally, but still plenty to do for release to user validation.

December 30, 2018
The revised code will greatly improve our ability to respond faster to user requests. It’s rational to get this done before we go from hundreds of users released, to supporting 1000X more.

1 Like

Three more months of info:

January 1, 2019
That metric - how much we reduce wasted hand motion between typing and pointing - that is one of the things we ranked highly in our nex-gen mouse architecture optimization.

January 2, 2019
the new mouse tech is as different from old practice as your TextBlade is from legacy keyboards.

TREG contributors will get early access to validate the mouse.
We have already shipped some other unannounced products to a set of treg users, and they are using them now for validation. User feedback on the pilot build for these other products has been favorable.
We’ll add those products to our public online store after we finish some patent work on them.
Mouse treg will start after general release for TextBlade

January 3, 2019
the new code fork has expanded data structures with much more attribute depth, to allow all boundaries to be adjusted.

January 8, 2019
as to charging contacts, the neodymium bars are plated with two layers of cladding - nickel and gold. Gold, a noble metal, provides very high protection against corrosion.
The charging contacts can be replaced, but that requires an epoxy bond. More likely, if damage happened to your SpaceBlade, the module can be replaced.
One good thing about TextBlade architecture is that each blade is a distinct module and can be replaced individually for a much lower cost. So if you completely smashed one part, it’s pretty easy to fix.

January 14, 2019
Bluetooth is the number one support topic for all peripheral makers, so we figure there’s a great opportunity to make a smarter dongle that ties into our automated diagnostics server.
So if a user has for example, a very noisy wireless environment, this new gizmo will be able help them find the source of noise.
It was surprising to us, but the level of Bluetooth support tolerated within the peripherals industry was not super great, so we see an opportunity to do much better here with a better-engineered smart dongle accessory. It’s on our roadmap of additional products.

February 2, 2019
we’ve made dozens of internal releases of the new fork in the past month, and cleared many testing milestones. Quite a bit of progress has been settled.
Our plan is to let treg users continue to have the full functionality of the current release, while our internal teams find and validate our checklist items for the migration to the new fork. We can iterate builds much faster internally, so this is most efficient.
We’ll switch over to treg user validation once we don’t see anything further from our internal testing. Then the diverse use cases of our treg customers will be highly effective to find any edge cases, and we’ll focus on clearing those to ready our general release.

February 5, 2019
we do have foundation in our platform for a graceful migration to Bluetooth 5, once it starts getting popular for input peripherals.

March 2, 2019
TextBlade has 300+ unique parts, and cost us millions of dollars just to tool the many molded parts.

March 20, 2019
During treg, we’ve received and accommodated a lot of requests for enhancements and extensions of features. The improvements have been very productive, handle many more use cases, and make the product generally more refined and just nicer to use.
As we added these changes, we approached the capacity limits of the system memory and cpu bandwidth.
Each new request for an update required an increasing proportion of coding time for organizing and allocating space, rather than the change itself. We reached a point where perhaps 80% of the work was just to first make space for the change.
Our team reviewed this, and also considered that these requests would continue, and would likely increase dramatically with the diversity of mass users in general release. TextBlade’s new software-based technology platform inherently invites higher expectations for what a keyboard can do.
We concluded that it was wise to find a wholesale solution that provided plenty of space to do whatever users might ask for. Central to TextBlade’s identity is that it’s a software platform, rather than just some soldered switches. So users have an expectation that you can make TextBlade do new things, much like a smartphone can with a new app.
We studied how best to do this, and found that a new firmware infrastructure could give us lots of running room to respond to new user requests, and to code it several times faster. The up-front investment in smarter infrastructure would actually save time overall, because of the relief from the code space burdens.
We resolved that it was wise to get this behind us before general release, so that supporting mass-install would be greatly simplified. We began working on this in parallel to our existing code releases last year, and have now gotten to a point where it will soon reach feature parity with the currently shipping product. We have working test releases in our labs, and will seed it to treg users once we have finished our internal validation.
There are many unannounced benefits of this new infrastructure fork, and we believe customers will be quite excited about them. The primary logic however, behind getting this done in advance, is that it’s a smarter way to manage the mass rollout. It would be quite difficult to bring everyone forward once there’s already lots more older-fork product in the field.
So that’s why we chose this path. Less hassle for customers, and smoother rollout and faster advancing of the platform in the field. TextBlade is really a new software platform, not just a box of switches like legacy keyboards. So settling this foundation upfront is the wisest path.
We think you all will really like what this new infrastructure makes possible. To keep a tight rein on schedule, the rule for our dev team is - no new features until feature parity is confirmed, and we’ve begun general release. The currently shipping release is already far beyond the functionality of typical keyboards, so we don’t need to add features in order to start GR.
But strong foundation must be there to support what treg has proven - there will be predictable excitement, and much demand for extending the platform, once mass users experience what’s now possible with a keyboard.

1 Like

April 11, 2019
We’ll make some official announcements in a few weeks, but features and price will advance.
All existing preorders get to keep their original pricing, and will also gain all the added benefits.
The preorder deal is better than currently announced.

April 14, 2019
High-precision, high efficiency battery charging with smarter monitoring and management - this is one of the areas we are testing right now on the new firmware fork.
It’s looking really encouraging - markedly smarter and more optimized to get the most out of each individual battery cell, with faster-responding, self-managed, independent control loops.
This will give us much more accurate SOC (state of charge) info, detailed battery charge history logs, and more ideal use of total charge capacity, which results in longer running time.
There’s a couple more layers to it, in terms of system power management code, but the goal is to further increase useful operating time from the same cell through smarter throttling of power during typical use.
Refinements to the nuance of how it wakes and sleeps - these may seem like minor tuning, but they actually meaningfully enhance the experience for the user.

April 15, 2019
TextBlade jumps and wakes pretty fast in the firmware you have, but the new fork is built to make both faster.

April 22, 2019
Quick look -
Testing jumps right now, and data from initial testing looks like they’re now about twice as fast.
We think it can be tuned a bit further, but focus first is on full feature-parity with current release.

May 8, 2019
Another nice byproduct of this firmware is longer running time per charge.

Can jump to a remote host via Bluetooth, even while plugged in and charging on local machine. [DBK note: This refers to the wired adapter for the TextBlade].

May 11, 2019
new infrastructure will let us do sticky modkey shifts.
This is another reason we’re making it.
We already support sticky keys on shift and function layers.
We can extend that functionality to many other functions with the expanded data structures that have greater attribute depth.

June 18, 2019
can confirm we bought parts and built blade assemblies sufficient for all preorders in hand. [DBK note: WHat would be good to have clarification on would be whether this means the parts they have made are only referring to the device they expect to ship. Because it is possible that if you count all the different versions they have made and gotten parts for, it may well equal the number of pre-orders, but not with what they expect to actually ship].

June 20, 2019
TextBlade’s platform has lots of running room for OTA updates.

Software defines TextBlade, and we’re making sure our general release will support many field updates for user requests for extended features.
So general release is effectively V2, and you’ll likely get V3 and V4 over the air

1 Like

Well, turns out there wasn’t a lot to go through these recent months so, I’M DONE this report on info WayTools as given between June 20, 2018 and November 16, 2019 with this post:

July 23, 2019
team has everyone focused on manufacturing facilities logistics tasks right now.

Re - acquisition speculations, there’s quite a lot to unpack there, which we may disclose later.
Most important guiding principle for us is to make sure all our customers get the product they want. That is core to our mission. Keyboards can and must move forward.
Prospective partners sometimes have different goals. Coherence with our mission is essential, and we protect that. [DBK note: Well, that can mean a lot of stuff. No idea what, but it is interesting!]

New infrastructure essentials are converging at a good clip.

No dependency on contracts, just physical logistics right now. Software dev team was only briefly involved with logistics, and now remains focused on code dev. These tasks are good things for us, and will give us better control over shipping logistics. Obviously we’re doing them because we’re indeed encouraged with new infrastructure code results, and working to get all our ducks in line to scale shipping.

August 4, 2019
A very busy couple weeks of intense logistics work for us, (including the last three weekends). We’re setting up expanded facilities for shipping and support, so all support staff has joined in to organize and manage the activities.
It’s a big and exciting step forward for us, and will provide many improved resources for better logistics access. That will help us handle larger volumes of physical goods in support of wide release.
Meanwhile, our Dev Team has been charging forward with the new firmware infrastructure, and has locked down several more remaining requirements to configure treg release units for user validation of the new infrastructure code.

August 5, 2019
We do an assay, but final assy = final assembly. That consists of snapping submodules and parts together, the electronic modules having all been built in Malaysia and Taiwan.
After final config of the submodules domestically, we then do a full integrated QA of the configured unit.
That QA is effectively an assay of the end-product

August 29, 2019
More to validate for full feature parity, but what we already have locked and loaded is working meaningfully better than the release you’re using now. [DBK note: That was a post to me, though it would apply to any tregger].

September 11, 2019
More than 80% of all feature parity functionality has been migrated and validated.
New code subsystems are also showing meaningful performance gains.
Faster, stronger, cleaner code, and with more robust self-monitoring.
And super important - new code base is much easier to maintain and extend.

September 30, 2019
Just as a heads-up, there’s an important patent deadline that’s been building, and it’s due this Friday. So that’s got our executive hopper quite full this week.

October 8, 2019
Patent stuff went excellent, so we’ll be putting bandwidth toward editing update for you during this week. Made considerable firmware progress in the meantime

October 16, 2019
Engineering milestone review went well today. Test data is quite encouraging.

October 31, 2019
there’s one more upgrade step in the migration pipeline, and that should provide a few more useful features too.

November 15, 2019
The new release addresses all those, and more. It supports wired mode, always-on, longer battery life, and dramatically increased freedom for customization and mapping.

1 Like

I’ll use this individual post for new info provided since November 17th. I’ll edit this post as new things are given. That should work as long as the thread doesn’t get posts from other people, which would tend to bury this one. So, here we go:

November 18, 2019
we’re now north of 90% feature parity.
Since this was an architecture upgrade, a lot of the work went into rethinking the data constructs. This has made them more fully generalized and robust, and greatly eases extensions on request from users.
Replicating a function is pretty quick, but conceiving and refining a more elegant implementation is the more subtle work, which is what usually takes most of the effort.
The majority of what we want to walk through in the update is drafted, but we need to edit with the most contemporary info about the recent test results, and the benefits they provide users.

November 21, 2019
For TextBlade, the product is very affordable, and our preorder deal is designed to be far better economically than can be offered in general release. There’s more about that in our announcement.
We have to guarantee that it works out very well for everyone who stuck by us during validation. That means the preorder folks definitely have much better terms than those in general release.
Doing that vindicates our mission, and lets us use our success to benefit all those who helped us. That kind of sharing cements our brand reputation. Then all follow-on products (like our nexgen mouse, super-useful accessories, and more) have an instant audience. Once already confident of the company’s values, folks are excited and hungry to get more new advances.
With our lead product delivered in volume, that will spread the word, and begin a virtuous cycle of advances and growth that lets us move very quickly to address other requests and needs. [DBK note: All true, but we know none of it happens until there is actually an tech update. And most happens after that and after it is sent to Treg. So, we need the tech update so we can start looking forward to what comes after it]

November 24, 2019
announcement contains interesting new details on technology for the new firmware release, with some drill-down on that.
We’ll also announce some extra perq’s for all the folks who have preorders with us. Hence the ‘announcement’ moniker. We think folks will like what we have in mind.


I think I figured out why DBK posts so much in this forum. He just likes typing on his TextBlade. :wink:

This gives a good excuse to do so…

1 Like

Actually, that is partly true. Not specific to this forum, but I do like to type on the TB so it isn’t unusual for me to do typing tests, etc, jusc to type on it.

1 Like

Just adding update info to the list that has happened since November 24th.

Dec 3, 2019
You might like how new firmware infrastructure incorporates some link improvements that meaningfully increase battery life.

December 4, 2019
FYI - following general release, we’re making much bigger changes to our TextBlade app, to make it fully platform agnostic.
So we’re not doing more changes to the iOS TextBlade app, and instead focusing on our new app platform. Similar strategy to new firmware infrastructure that we’re doing now. These both address the need to generalize all functionality for the broader, diverse user market.

Dec 9, 2019
liberty to define new chord modes = a fundamental benefit of the new infrastructure.

Dec 16, 2019
new firmware will definitely go to experienced treg users first, on the notion that they will have a keen eye for any variances based on their extensive use.
After a wave of those, we’ll feather in some newbies, for diversity of validation before general release.

fundamentals are good now, but last 10% has its usual bumps, which are typically nonlinear. No science surprises, just the normal work to get the details figured out and tested.
As to time, until you’re really over the finish line, it’s always rough estimates, but weeks-months seems like the range. It’s the exceptions that take the most elbow grease.
The cool thing about the new structure is the dramatic increase in high-level abstraction of SW objects, which makes the code much more resilient, maintainable and extensible, and lowers risk of dwelling on the debug tedium.
Better architecture tends to help reduce long tails for the certification process. From an engineering perspective, it’s very exciting to see how we’ve been able to simplify the process flow for the machine intelligence.

it’s generally true that a second iteration is informed by the first, and is therefore far less scope to achieve.
We think that’s very true here.
Keep in mind that the first TextBlade version we shipped was the first-ever manifestation of this new keyboard technology. So it was the first time anyone confronted all those emergent user needs once the platform had been created and they started using it.
All that work is now under our belt, so this part is a much more manageable task. Still hard, but very reasonable to predict a successful outcome.

December 28, 2019
team is right now focused on instrumenting the new firmware with logging functions for the new architecture. These give us much more fine-grained and cross-platform logging, so that our treg users can send us any edge case data a lot more easily and quickly. We learned many things about diverse user behavior from the release that’s already in the field. We have embraced those needs, and built a much more powerful logging facility, to make supporting 1000X increase in users readily manageable for our team, and more convenient for users.

[DBK note - the following starts with answering a question about privacy of making logs in case you need to send a problem to Waytools]:

all current protections have been retained, but there also are now further protections we’re able to add as a consequence of the new architecture.

These enhancements are responsive to many user requests. Treg users organically have tended to use their macros to encapsulate passwords, and then summon them with gestures on their TextBlade. This is actually a lot safer than the typical practice of typing passwords.

If you think about it for a moment, typing critical passwords on any keyboard in the open, while in say, a coffee shop, it’s kind of ludicrous. The typical Starbucks has an array of security cameras recording everything that happens, with sufficient resolution to read your keystrokes.

If your personal 1.5 oz keyboard can abstract your passwords, and store them securely, such that they can’t even be stolen even by grabbing your TextBlade, now that’s very useful.

Your iPhone can hide passwords by linking them to Face ID, but that won’t unlock a website on your laptop, or your other machines.

A personal keyboard is universal across all your machines, and forms a kind of secure token that works in each of those cases.


While I would agree that your editing of my post makes it look “neater” (paragraphs separated by a blank line), I actually was trying to use a specific system. That is:

Label the first post each day with the date.

I described this in the first post of the thread:

“Meanwhile, the following are the statements about upcoming updates. If there is not a blank line between statements, it is from the same post. If there is a blank line, it is from the same date, but a different post.”

Not very neat, but there was a functional reason for it.

Dbk - yes, often formatting gets squashed when pasting, so restoring line breaks can help.

No, that wasn’t what happened. I deliberately removed the line breaks if I was quoting parts of the same post. I used line breaks to separate DIFFERENT posts that were on the same date. All my posts in that thread followed that set of “rules”. Looks sloppy maybe, but since it followed a pattern, the consistency let people tell what was a different post.

Ok, perhaps demarcate the different pastes with a separate date / timestamp header.

That way rather than editing it, the quote can preserve its original content form, which separates concepts.

In any case, the compilation is useful and much appreciated.

At the time I got tired of putting in dates and sure didn’t want to add time stamps. Not going to redo them all now!!!

No worries :ok_hand:t3: