New TechTalk Update Coming

Awh_tokyo - 3PL makes sense in many cases for commoditized goods.

In our case, there are a few other considerations that favor some wholly-owned domestic operations -

  • There are final-stage configuration processes that require product-specific labor (like keycap config)
  • TextBlade is very modular. The 3 blades, as well as their subassembly parts are simple to click together.
  • This allows us to aggregate parts and subsystems from many global suppliers, for final config in the US.
  • The labor cost is a relatively small percentage of overall cost compared to the silicon cost.
  • We already do automated test and final QA all in the US.
  • We want in-house hands-on and eyes-on final assy to assure quality.
  • Due to uncertain US/China trade right now, it has become wise to maintain some operations in the US.

Logistics should presumably not be a core competency, but given the above, we don’t think farming everything out to start wide release will be reliable enough for our standards.

We think other firms are coming around to this same point of view now, and rethinking their all-China sourcing arrangements.

Hope this gives some insight into our planning.


Well, that is interesting, especially where it seems everything is assembled in China!

THIS is the update I’ve been waiting for since June. It’s clear, concise and informative. Please continue to keep us posted with these short-and-sweet updates. Thank you, @waytools! :+1:


Do you mean you want a “final assay” to assure quality and does the relate to the consistency of your magnetic parts?

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.


I smell what your step’n dude. thanks for clarifying!

Very exciting. I was one of the first Treggers having ordered my TextBlade in March 2015! I loved it but left it in a plane seat pocket about 2 years ago and have been in mourning ever since (I keep my typing fingers dressed in mourning black).

To think that there is a realistic expectation of GR has my fingers dancing for joy.

The only sad thing is that when I checked for my original order the screen showed today’s date rather than March 2015. Maybe a Gremlin entered Waytools’ system. We all should check that those of us that ordered years ago, get to keep their place in line.

Sorry for the loss, @tskwarek.
There’s a new topic on the status page date change:

How goes it Waytools?


IPdude - thanks for asking. Busy with distractions on lots of admin responsibilities, but engineering on new infrastructure release is looking pretty darn good.


Glad to hear it. Could you elaborate a little? I mean, from your statement we don’t even know if it is hardware engineering, software engineering, or both, let alone what the progress is or what is remaining. No, I don’t expect extreme detail.

Oh, reread and you said “infrastructure release”. But that can still mean a lot of different things. Heck, it would be great if something could be said like, "The hardware and firmware are close to being done, but we need to beef up our infrastructure to handle mass shipping an support for customers before actual GR.

dbk - that’s the dev team’s new infrastructure code fork that I was referring to above.

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.


Trying to remember how other things were described. I think maybe when you referred to stuff to make shipping and post GR support work better, you might have used “logistics” and I thought it was “infrastructure”.

So, “infrastructure” is about the code fork. Which brings us to:

I don’t suppose you can tell us the stuff that is better (or even as good since you previously said if it wasn’t for the problem of low free memory available, which would greatly complicate support, that the present version would probably have been good enough), that is up to snuff :slight_smile:

Or, conversely, what isn’t. Or both!

Right off hand, I can only think of one thing you have specifically said is better than before, and that was that jumps were about twice as fast.

You’ve made other comments about plans - which would be before or after GR was never clear - such as more jumps. More boundaries, etc. So those are some things right there that could be at least partially referenced.

If I was in a position to know and had to write an update, without taking much time, I might say:

Jumps are at least double the old speed and we don’t need any more improvement on that issue before GR.

We feel we have been able to create more jumps, however, the plan for now is to not turn on that ability until after GR out of caution that many people testing it in Treg could find a problem. So the intention is to do GR without those new jumps, but have treg users give them a workout in later betas first.

We have created the framework for a few more boundaries - those which seem to have the most need - but the present schedule will have those added after GR.

The ability to edit the shift keys now exists (useful for those to change a shift key if they only use one all the time now) and will be in GR.

We have also made it possible to assign modifier keys (also in combination) to a key without also requiring another key to it. IOW, you could turn the right shift key to be “command/control”, thus letting you just hit that one key and then whatever other key you need for a special action. Right now you’d have to hit three keys to do that so this will give more flexibility for those who need it.

Of course, all the above are just wild examples, based on things you’ve posted about here and there over the years. But if they all happen to be correct, you could just post, “You have everything right” :slight_smile:

1 Like

Considering how much you like to write on here, Mark should just give you a brain dump every 30 days and let you translate it into long rambling posts :wink:

If I had the info, my tendency would be to try to make a simple list of changes - and later write long posts discussing the importance of each! Or unimportance as the case may be.


@waytools, at least now can you give a percentage of features that have been ported to the new infrastructure fork enroute to feature parity with the latest TREG build? One number, that’s it - no explanations, no demand for detailed updates. I just want a number to put “making steady progress towards feature parity” in perspective.


Hrishi1379 - excellent, elegantly simple query.

Answer: 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.

After user satisfaction was proved, we’ve focussed on making all inner workings rad-hard.



About the remaining 20%, obviously they aren’t at “parity”, but are any of them really causing problems to solve before being “good enough”? For example, all BT can have problems with interference, etc. But it seems that will not be completely solved since no one has done it. So that is an example of something that may still be an issue, but also be “good enough”. Or maybe not good enough if it isn’t as good as the prior version of the firmware.

Probably didn’t describe that well, but it’s the best I can do at 2:00 AM!

There’s an old saying in software development (and probably other areas as well) that 80% of the final results represent 20% of the total effort, while the remaining 20% of the results take the remaining 80% of required effort…

I’m not saying this is the case with Waytools/Textblade, but (more than) 80% doesn’t mean that we are near or far from GR in case anyone is expecting to get a timeline from reading between the lines (I’m not).

I’m eager to get my hands on the thing, yes (and as many others here, I also applied for TREG) but I’m on the bandwagon that only expects the blade to hit the shelves by 2021, solely based on my experience as a developer (and code seems to be the main work currently underway at Waytools).

And why would you insist on feature parity on a product that is 4 years late and never reached General Release?

Why isn’t 80% parity good enough for General Release?

Just like why would you scrap your firmware that from TREG reports was generally stable and worked.

How in the world does WayTools make business decisions? They make no sense to me.

I would be absolutely stunned if you answered any of the questions.