Skip to content

Releases: Combadge/Spindoctor

v0.0.8 - This is now a Combadge Server

16 Nov 14:58
d257cf8
Compare
Choose a tag to compare
Pre-release

It has been 84 13 years. I'm sorry, do you want to read these release notes or not, Mr Lovett?

It has been thirteen years, and I can still smell the fresh packaging. The buttons had never been used. The speaker had never been listened to. They called the Combadge the communication system of dreams, and it was - it really was. Not that I had any way of knowing, since as far as I'm aware, this release is the first time it's been possible to have a voice call between two Combadges without the OEM Voice Server, which is not accessibly priced for the hobbyist.

What we have is pretty limited - if you make the right API call from CURL, you can trigger a call between two badges. It can't be done from the badges themselves (the agent does nothing but transcribe badly), and you can't call or broadcast to multiple devices - but the basic function of the Combadge is now a function of Spindoctor.

There's a lot to do, of course - somehow Robin must become a real voice agent, multi-badge calls and unidirectional broadcasts must be implemented and much, much more - but as of right now, the Combadge project has functional Combadges and after 13 years I'm very glad we've reached that milestone.

Note: Rerelease with some rather cleaned-up code. No functionality change, it's just tidier and the libraries have been renamed.

v0.0.7 - Login/Logout now fully functional

31 Oct 13:12
e96eebf
Compare
Choose a tag to compare

Relatively small release again, but a really important one - the server can now properly handle basic user states for badges. This means you can now log in, and log out, by calling the API at port 1031. Consequently, I've also removed the automatic login of a dummy account - on connection, if a badge does not have a previous login state, it will not automatically log in as a fake user, but remain logged out until otherwise requested by the API.

v0.0.6 - Now with API for Login

28 Oct 22:22
caf0d7a
Compare
Choose a tag to compare
Pre-release

This build now adds a simple web API that can be used to log-in any arbitrary username to a badge, regardless of whether the badge currently has an active user. This sets the "idle" text to the "Pretty Name" and sets the Info menu and badge.properties. Other than that it has little use, however this is the first time that badges can be configured in real time.

To-do:

  • Log out.
  • Meaningful concept of what a "User" is.
  • Badge-badge calling.
  • Everything else.

v0.0.5 - Way overlarge PR to merge agent into Combadged

13 Oct 16:02
Compare
Choose a tag to compare

Pretty spectacular update in the code, but a relatively small one in functionality. The main difference is that agentd.js has been merged into combadged.js - so that speech recognition happens automatically during a call, and outputs to the server console.

I'm going to try and restrain myself a little in the next couple of PR's so that we get a more incremental process, but I won't be creating a release for each one. The main things I want* to achieve for the next release are:

  • Full multi-agent support for handling more than one badge at a time.
  • Proper streaming (with VAD) recognition for STT to avoid my current "chunking" hack.
  • Calls between multiple badges (not necessarily triggered by speech).
  • Some kind of basic login functionality (not necessarily triggered by speech) that can handle multiple badges.

* No promises I'll get all of these.

v0.0.4 - Finished the big cleanup job.

10 Jan 21:38
5c0e174
Compare
Choose a tag to compare
Pre-release

I could have waited to drop v0.0.3, but I wasn't sure how long this would take. As it happens, I got it done in one evening and fixed some other things while I was at it.

  • Big change: The packet classes now have a Summary which gives a brief human-readable overview of the key data in the packet, and Combadge instances now log this information to the console - which is useful for debug. Long term, the debug messages need to be a flag, but this is fine for now.
  • Medium change: The constructor "api" for packet classes has been unified somewhat by switching to an ES6 kwarg-inspired model for all the optional parameters. Obviously, most of the parameters will vary by class - but at least position is now entirely up to the user, and can't be accidentally varied between classes in any way that matters.
  • Small change - but the only "functional" alteration: The AP BSSID is now properly decoded - for some reason, the Combadges return the BSSID with an increment of 18 on the first byte. I have no idea why, but the code "corrects" that. Long term, this will be used to update the badge's "Location" field in the Info menu, as well as to locate the badge - important for beaming unwanted goods away from the warp core.

v0.0.3 - The Oversized Code Cleanup release!

09 Jan 22:12
Compare
Choose a tag to compare

This has been a weeks work and I think adds up to something like writing as many lines of code as I have ever done on every version of this project private or public... again. But it was so worth it.

The whole project has been converted to an ES6 module, with accompanying strict checking, which has dramatically improved the code. If that wasn't enough, I've started the long planned refactor to put the Combadge protocol code into it's own library. We're not quite at the point of splitting it off into a separate repo and publishing it on npm, but it has been a big jump - including separating the "dirty work" code of handling packet-level interactions with the badges, from the "command" code which defines the structure for how to interact with the combadge. This gives us a few things - it means that we only have one place where we decode or encode packets, whereas before the host application had to do some packet hacking in order to get the badge MAC before anything else can happen. Now with the static method CombadgePacket.from, the host app gets an appropriate packet from an appropriate class to appropriately assign to an existing or new Combadge instance and all it has to do is feed the UDP message into the library.

The other major benefit is simply one of readability. CombadgePacket ends up big, but relatively simple - while Combadge remains complex - but is blissfully short by comparison.

There will be more changes to come, I want to edit the packet constructors to a unified interface of (MAC, { kwargs}) for consistency - and I still need to sort an appropriate way of programatically generating Agent threads - and allowing instructions to be passed back from them.

But there's far more work to do overall. Small steps!

v0.0.2 - Now, with Speech to Text!

09 Jan 22:12
Compare
Choose a tag to compare
Pre-release

Code-quality wise, this release makes v0.0.1 look clean by comparison, but I thought it was important to pack it, given the progress over the last day.

We now have the beginnings of inferencing! I still haven't refactored the agent (had a play with it this morning, but it was just a mess) but I've started breaking the RTP stuff into a more structured library. It's going to be simple and incomplete, but that's fine for now.

This is a project of two halves. Writing the combadge code is deceptive - while reimplementing a protocol based only on captured packets is difficult, it's not inherently complex. The real task is in the speech and NLP side of things that actually decide what you're asking them to do. That's going to be the bigger half, in the long run! But a fun one, and it's nice to be edging a first toe onto that path.

Enjoy!

v0.0.1 - Initial test code.

09 Jan 22:12
Compare
Choose a tag to compare
Pre-release

And we're off to the races! This release does almost nothing, but it does it in great detail. You can associate an already-logged-in badge, and start a call with the agent, which will play a test tone until the file ends and the server crashes, or until the badge is powered off.