follower

Instructions unclear, here is your buzzword list link: https://github.com/words/buzzwords/blob/main/index.js#L1

This is so great--both in terms of the project & the write-up. Thanks for sharing your work! :)

A "quick" dump of some thoughts it provoked:

(1) Really like the "meaning-nonsense continuum" concept--and that neither extreme is explicitly labelled in the image immediately following where the term is introduced. :)

(And, yes, "Gravity learns about regret." is indeed kind of beautiful.)

(Aside: Adding alt text to the generated images would be beneficial both for copy/pasting & accessibility reasons. :) )

(2) This statement made me smile: "If you don’t enjoy reading and contemplating these sentences like this, we are simply very different people." Because while I very much fall into the category of "enjoy reading and contemplating these sentences" I can also imagine people who definitely don't. :D

(3) Part of the reason for (2) was because I'd already encountered a couple of the "don't work" examples where my immediate thought was "wait, how about in this situation though?". e.g. "Aligning with compass."

Which then got me thinking about stylistic, metaphor or time-period related aspects of grammar, e.g. pirate treasure map instructions written in cryptic sentence fragments.

(4) Which leads into the whole "procedurally generated diagrams/documents" aspect of the project that I also think is particularly cool. It immediately got me thinking of being in a game and walking into an inventor character's lab or a magician's library and finding all manner of technical or arcane drawings generated for either environment or game mechanic purposes (e.g. in a detective/mystery game like "Shadows of Doubt").

Then again, since I was a kid I've always had an interest in browsing technical component and, err, office stationery catalogues, so maybe it's just me. :D

It also made me think back to "Interminal" an entry to the 2020 ProcJam procedural generation game jam, which generated an airport terminal including duty-free stores with procedurally generated perfumes (including "name, visual identity and smell"): https://nothke.itch.io/interminal

(5) The "physicalization" aspect of the project to render it in a tangible form is also cool--particularly because (at least to me but maybe also to all those vinyl-owning kids with no turntable :D ) a physical form seems to the amplify the "meaningfulness" of a message...

The underlying "digitalized cursive handwriting" project was also of interest--though I only skimmed its write-up in an attempt to avoid yet another rabbit hole. :)

The handwriting system seemed like it might also be amenable to animated use--which then made me think, "Wait! I've seen something about that recently...", had no idea what, but then some background retrieval process just produced the answer as I was writing, it was Noclip's recent "The Making of Pentiment" documentary: https://www.youtube.com/embed/ffIdgOBYwbc

(6) With regard to the technical execution/implementation side of things: I've observed that a project's need for text generation often raises a question of what implementation approach to use, in terms of a DIY vs pre-existing solution.

One issue which affects text generation specifically is "general solutions" often seem to tend toward specialization over time (e.g. "text generation for interactive fiction", "text generation for branching narrative-driven games", tools such as Yarn Spinner[0] & Ink[1]), which ends up making the solutions less suitable for simpler/different use cases & increases difficulty of the learning curve.

This was something I ran into during a small sub-project[2] last year where the text generation was somewhat "incidental" to overall project goal. I started out with a "quick DIY" solution but still ended up spending enough time on that aspect that I started to wonder if I'd be better not entirely re-inventing the wheel.

Around this time I ran into the "Blur Markup Language"[3][4][5] project which has the tag line "write text that changes" and--while I haven't yet used it--seems like it might be a promising "mid-level abstraction" solution for text generation, so thought I'd mention it as a potential option for others with text generation needs.

(7) In terms of other helpful text generation related resources, I've found various "word lists" to be of use, so thought I'd mention this "weasel words" list as a starting point: https://github.com/words/weasels/blob/main/data.txt#L14

(The repo README also links to other word lists under the same org including word categories such as "buzzwords", "filler", "hedges" & words listed in order of associated positive/negative sentiment.)

Thanks again for sharing your work & look forward to seeing where your projects go in future, should you share more in future. :)

---- footnotes ----

[0] https://github.com/YarnSpinnerTool/YarnSpinner

[1] https://github.com/inkle/ink

[2] I wanted to generate "scripted dialogue" samples[2a] to demonstrate the 900+ individual Text-To-Speech speaker voices in the Piper TTS[2b] LibriTTS voice model[2c], in a form that is: useful for evaluating the voices; not incredibly tedious to listen to; and, makes it possible to identify which speaker you are currently hearing.

[2a] Subset of resulting generated[2d] speech output can be heard in the second example here: https://rancidbacon.gitlab.io/piper-tts-demos/

[2b] https://github.com/rhasspy/piper

[2c] https://huggingface.co/rhasspy/piper-voices/blob/main/en/en_...

[2d] Text generation script: https://gitlab.com/RancidBacon/larynx-dialogue/-/blob/featur...

[3] https://bml-lang.org

[4] BML intro/overview: https://bml-lang.org/docs/guide/language-basics/

[5] Online BML editor with syntax cheat sheet: https://bml-lang.org/sandbox/

> [...] waiting for one or more terminal emulators to get together and add some ridiculous new escape codes [...]

I'm definitely of the opinion[0] that we haven't yet reached the limits of the "terminal emulator" UX paradigm.

The past few years do seem to have seen a resurgence in terminal emulator innovation due in part to a combination of new languages, the prevalence of GPUs, and a realisation that many of the existing terminal emulators weren't interested in any innovation in certain directions.

I've particularly been interested in the possibilities provided by the Terminal Graphics Protocol (which I discuss more in the linked comment).

A couple of years ago I switched to WezTerm[2] due to a combination of its graphics support, implementation language (Rust) and that its main developer seems to be interested in a combination of both solid support for existing standards & opportunities for innovation.

WezTerm also provides opportunities for customisation both in terms of shell integrations and of the application itself[3].

> [...] new escape codes [...]

Also, on this aspect, it may not even be necessary to create new escape codes--recently I discovered the `terminfo(5)` man page actually makes a pretty interesting read[7], in part because it lists some existing escape codes that seem like they have potential for re-use/re-implementation in the current day's more graphic-based systems.

---- footnotes ----

[0] As I mentioned in a recent comment on a thread[1] here:

"Motivated by the thought that at the current point in time perhaps the 'essence' of a 'terminal' is its linear 'chronological' presentation of input/interaction/output history rather than its use of 'text'."

[1] https://news.ycombinator.com/item?id=40475538

[2] https://wezfurlong.org/wezterm/

[3] While I'm definitely not a fan of the choice of Lua as the extension language, I have now at least hit my head against the wall[4] with it enough that I can actually get more complex custom functionality working.

[4] I've started to write up some of my Lua-related[5] notes & more general WezTerm[6] notes so hopefully it'll eventually be an easier road for others. :)

[5] https://gitlab.com/RancidBacon/floss-various-contribs/-/blob...

[6] https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...

[7] As one does. :) It was a fascinating/amusing time capsule in terms(!) of mentions of weird hardware terminal quirks that at one time ("before my time") needed to be worked around; interesting escape code discoveries; and, the mention of a term I had not thought of for decades but was at one time of importance: NLQ! :D

The linked video is an in depth and step-by-step explanation of Disney's "Principled"[0] BRDF shading model.

The latter part includes a really great explanation and visual demonstration of each of the controllable parameters--which is very also helpful for artists who use BRDF in 3D packages such as Blender.

(Includes math/maths content but presents it in a more accessible manner than one might anticipate.)

Fair warning: Acerola's stylistic choices may be... an acquired taste but the content of the videos is absolutely worth acquiring the taste for. :)

[0] Including why it's called "Principled"--which I hadn't realised I did actually want to know. :)

Also, nifty: https://github.com/alexqfredrickson/vcvj :)

(I've done some VJing in my time, so it's always cool to see related projects--I particularly like the effect on the ping-pong ball in the examples with its bounce path trail. :) )

Understandably, it's such a great resource! :)

> I also would prefer to set up the programs once and then switch them with physical buttons. [...] The bad app experience is honestly a reason for me to look at other brands for my next pair.

While the latter is probably the preferred approach for dealing with the issue, I'll admit my mind first went to:

If you've got time for a side-project maybe consider reverse engineering the Android app's Bluetooth support... and, you know, "just" re-implement the same thing in some stand alone hardware. :)

There may even already be a project related to your device--I'm aware of multiple health/medical-tech/device related reverse engineering projects that were primarily driven people with programming/hardware experience wanting to avoid crappy vendor apps & have control of very personally relevant devices.

> [...] ADHD people who will hear everything you're saying, ask "What?," and then a second later I've finished processing the audio in my head and am ready to continue the conversation.

You know, until you mentioned it, I'd never thought that that experience might have an ADHD-related component to it. Interesting.

> suppose i don't think ADHD has anything to do with my hearing loss or issue;

I wouldn't be so quick to dismiss that as a potential factor, auditory processing issues are known to something that can be connected to ADHD in some people. (Also mentioned by a few other people in the comments.)

Couple of links that go into more details:

* https://en.wikipedia.org/wiki/Selective_auditory_attention

* https://en.wikipedia.org/wiki/Auditory_processing_disorder

* https://en.wikipedia.org/wiki/Cocktail_party_effect

> Additionally, i cannot watch any tv or film produced after about 2000 or so without subtitles, regardless of how fancy the "5.1 surround" center channel DSP is.

IMO that's potentially more because audio engineers for home movie releases are... ok, well, let's just say, "have different opinions on how to mix audio with dialogue than me". :) It's a very common compliant.

> I should have worn hearing protection more when i was younger

Shouldn't we all? :) Still worth trying to protect what you have now--I've used the "Etymotic" brand ear plugs mentioned elsewhere in the comments which are intended to more evenly reduce sound levels without just "muffling" everything.

> but when i can't hear music i enjoy i'll be pretty sad about that.

Indeed. Understandably.

These have been mentioned elsewhere in the comments but in case it's helpful:

* https://en.wikipedia.org/wiki/Selective_auditory_attention

* https://en.wikipedia.org/wiki/Auditory_processing_disorder

* https://en.wikipedia.org/wiki/Cocktail_party_effect

Mentioned elsewhere in the comments but in case it's helpful:

* https://en.wikipedia.org/wiki/Selective_auditory_attention

* https://en.wikipedia.org/wiki/Auditory_processing_disorder

* https://en.wikipedia.org/wiki/Cocktail_party_effect

My interest in TTS is around "indie" game creation, animation and "radio plays".

A couple of years ago I started development of a tool to help with the generation of game audio such as NPC dialogue, "barks" or narration for those without access to/budget for human voice actors: https://rancidbacon.itch.io/dialogue-tool-for-larynx-text-to...

One thing I found interesting is that writing a small "scene" and then hearing dialogue being spoken by a variety of voices often prompted the writing of further lines of dialogue in response to perceived emotion contained in voices in the generated output. Plus it was just fun. :)

The version of the tool on that page is based on Larynx TTS which has continued development more recently as Piper TTS: https://github.com/rhasspy/piper

I'm yet to publish my port which uses Piper TTS though: https://gitlab.com/RancidBacon/larynx-dialogue/-/tree/featur...

Though I did upload some sample output (including some "radio announcer" samples in response to a HN comment :) ): https://rancidbacon.gitlab.io/piper-tts-demos/

Obviously there's variations in voice quality, and ability to control expression is currently limited but beats hearing my own voice. :D

The repo does claim that something is "open source" but the only included license text is "CC-BY-NC-ND" and the README seems to restrict permissions even further.

In addition, the Hugging Face repo[-1] states the license as "Creative Commons Attribution Non Commercial 4.0" (lacking the "ND").

Unfortunately, this combination of license imprecision and restrictiveness seems par for the course with a lot of academic TTS projects. (And, even for commercial "Open Source" TTS projects it's often the case that while code might be OSS licensed, none of the the voice data/models are.)

The current version[0] of the README repo states:

* "The open-source version on HuggingFace is a 40,000 hours pre trained model without SFT." (Presumably refers to model.)

* "At the same time, we have internally trained a detection model and plan to open-source it in the future." (Not directly relevant.)

The included "Roadmap" indicates related completed & uncompleted tasks:

* "[x] Open-source the 40k hour base model and spk_stats file"

* "[ ] Open-source VQ encoder and Lora training code"

* "[ ] Open-source the 40k hour version with multi-emotion control"

However, as noted, the current LICENSE[1] file states:

* "Attribution-NonCommercial-NoDerivatives 4.0 International"

And the README also contradicts the license:

* "This repo is for academic purposes only. It is intended for educational and research use, and should not be used for any commercial or legal purposes."

* "The information and data used in this repo, are for academic and research purposes only."

And this part of the "disclaimer" would make me concerned about potential licensing issues in regard to code and or data from other sources:

* "The data obtained from publicly available sources, and the authors do not claim any ownership or copyright over the data."

The code in the repo itself appears to have no license information contained within it.

My go-to actually Open Source licensed Text-To-Speech project (with a range of voice[2] model licenses[3]--including Public Domain & CC-BY[4]) is Piper TTS: https://github.com/rhasspy/piper

---- footnotes ----

[-1] https://huggingface.co/2Noise/ChatTTS

[0] https://github.com/2noise/ChatTTS/blob/f4c8329f0d231b272b676...

[1] https://github.com/2noise/ChatTTS/blob/f4c8329f0d231b272b676...

[2] Voice samples: https://rhasspy.github.io/piper-samples/

[3] Though I would also caution that (at least by my interpretation) some of the voices listed as CC0/PD or CC-BY also note that they've been "fine-tuned" on models which have more restrictive licenses and thus probably can't inherit the voice data's more permissive license.

[4] However, these Public Domain and/or CC-BY voices do appear specifically created to be data license-compliant: https://brycebeattie.com/files/tts/

Would you settle for as "horrible" as new open source TTS systems? :D

My current go to is Piper TTS: https://github.com/rhasspy/piper

It's MIT-licensed, supports ~30 languages and multiple voices[0]/quality/licenses.

Voice output samples: https://rhasspy.github.io/piper-samples/

Discovered just now that recently there's also been some efforts to train Public Domain/CC-BY licensed voices specifically for Piper TTS too: https://brycebeattie.com/files/tts/

---- footnotes ----

[0] e.g. One of the English voice sets has ~900 voices(!).

> Last time I looked into TTS systems for German, Google was the only game in town. What I wouldn't give for a viable alternative! It doesn't even need to be open source, I'd be quite ready to pay top dollar.

Will you still pay top dollar if it is open source though? :D

Piper TTS[0] (MIT Licensed; developed by main dev of Larynx TTS, Mimic3 TTS & Rhasspy voice assistant) has support for ~30 languages, at least some of which have multiple voices available--in a range of quality & data licenses.

And, particularly fortuitous for your needs, potentially, there's at at least one German voice that was recorded[1] specifically for Piper[2] (with emotion variants and CC0-licensed, no less :) )...

Check out `thorsten` & `thorsten_emotional` on the samples page: https://rhasspy.github.io/piper-samples/

I can't speak to the quality of the German voice specifically but for English at least I've found Piper's quality & range of voices of use[3].

---- footnotes ----

[0] https://github.com/rhasspy/piper

[1] https://www.youtube.com/playlist?list=PL19C7uchWZeojjI5FUk3q...

[2] In addition to other German voices based on other sources: https://huggingface.co/rhasspy/piper-voices/tree/main/de/de_...

[3] Somewhat of an understatement.

> I am a former Google SAD-SRE

From long enough ago that I should apologize to you for libgmail: https://libgmail.sourceforge.net ? :D

"Pros always use this one weird trick Brotli compression hates." :)

> There are several different xterms.

Based on my understanding of the situation this claim seems to perhaps be... a little lacking in nuance? :)

In a different context perhaps we'd be talking about "genericization of trademarks" but, at least as a term *cough* referring to a specific software application, well, "the" "xterm" docs[0] think there is "only" "one":

* "xterm (pronounced 'eks-term') is a specific program, not a generic item. It is the standard X terminal emulator program."

Then again, even with a narrow definition of "the standard X terminal emulator program", the xterm moniker can apparently apply to two "implementations"[1], variously[1][2] referred to as "xterm-new" (a.k.a "based on XFree86 xterm" a.k.a. "modern" a.k.a "based on the X11R6.3 xterm, with the addition of ANSI color and VT220 controls") and "xterm-old" (a.k.a "the X11R6 xterm" a.k.a. "xterm-r6").

And, indeed, the docs do use the phrase "other versions of xterm"[3] in reference to:

* other programs "based on xterm's source"

However, it also distinguishes between those programs and programs in two further categories:

* "similar programs not based on xterm's source, which are compatible to different degrees"

* "programs which set TERM to 'xterm', in the hope that applications will treat them the same as xterm" (which apparently includes some whose developers think that by "[...] copying from xterm [source code], they are entitled to do this whether or not the program actually matches xterm's terminal description").

Which segues nicely into...

> they all call themself the same TERM=xterm by default

A habit that the main developer of xterm since 1996 appears to have, um, some additional thoughts about: :D

* https://invisible-island.net/ncurses/ncurses.faq.html#xterm_...

* https://invisible-island.net/xterm/xterm.faq.html#xterm_term...

Hey, maybe we should replace `TERM=` with `USER_AGENT="$TERM (Compatible with xterm)"`, cos that worked out great on the web! :)

Now, some people may respond "No, we should be using feature detection!", to which I might respond, "Hey, yeah, like, we should have a way to find out what features or capabilities the current terminal emulator supports!".

Problem solved!

Guess the only question now is whether we should call it "The Terminal Capabilities System" or "The Terminal Information System"...

...wait, no, those names don't sound... "unixy" enough.

Let's call it "terminfo". Yeah, let's use "terminfo"!

To which I imagine, at least one person might reply, with a sigh, "I wish you would":

* https://invisible-island.net/xterm/terminfo-contents.html#ti...

* https://invisible-island.net/xterm/terminfo-contents.html#ti...

* https://invisible-island.net/xterm/terminfo-contents.html#ti...

* etc

Wait, so, why doesn't this system "work" then? Well, turns out, apparently its "easier" to just tell someone to set `TERM` to a value which might charitably be called "aspirational" and hope it all works out.

(Spoiler: it doesn't[4].)

> xterm is not a standard.

If xterm ain't a standard then why everyone always try to bite its style? :) (Or, whatever the kids say these days...)

So, yes, in one sense, "xterm" is not a standard, it's one specific program, with a specific set of behaviours.

In another sense, well, while some people set out to write a program to emulate a "DEC VT100" terminal behaviour in a compatible manner, other people very much do set out to write a program to emulate "xterm" terminal behaviour in a compatible manner--which suggests the behaviour of "the xterm" is at least a "de facto" standard.

And the problem comes when those developers claim their implementation is so accurate that it is "indistinguishable" from "the real xterm" that `TERM=xterm`, when that's, umm, definitely not the case[5][4].

Heck, even xterm itself isn't so brazen as to set, say, `TERM=vt220`! :)

The good news is that if setting `TERM` to a realistic rather than "aspirational" value is too hard, the author of `xterm` even provides a tool that terminal emulator developers can use to validate & improve some of their compatibility with the "one & only, definitely not a de facto standard, xterm": https://www.invisible-island.net/vttest/

And, personally, I think, all those terminal users out there, when they ask for "xterm" it's not unreasonable for them to expect to get the Real Thing(TM) and not a knock off "we've got xterm at home". :)

But, hey, I probably only first used the xterm in 1994 at the earliest so I could easily be missing some relevant historical nuance. :D

---- faq ----

q: Did this comment really need to be this long?

a: No. But, you know, thanks for reading it. :)

---- footnotes ----

[0] https://invisible-island.net/xterm/xterm.faq.html#what_is_it

[1] https://invisible-island.net/ncurses/ncurses.faq.html#no_xte...

[2] https://invisible-island.net/xterm/xterm.faq.html#forward_hi...

[3] https://invisible-island.net/xterm/xterm.faq.html#other_vers...

[4] https://invisible-island.net/ncurses/ncurses.faq.html#xterm_...

[5] https://invisible-island.net/xterm/xterm.faq.html#compare_ve...

Based on my (limited) understanding of Kitty's image protocol[0] (a.k.a the "Terminal graphics protocol") video support could be potentially implemented via multiple approaches, including at least:

(1) Draw image repeatedly using the "don't move cursor" cursor movement policy[1a][1b].

(2) Draw image replacing an existing image with the same id.

(3) Use animation configured to use "loading mode"[2] ("in this mode when reaching the last frame, instead of looping, the terminal will wait for the arrival of more frames").

An actual terminal graphics/image protocol enables some IMO[3] pretty cool possibilities:

* A while back I implemented a proof-of-concept that displayed a simple interactive egui (a Rust immediate mode GUI project) GUI within WezTerm via the protocol.

* Later I discovered someone had gone as far as making a port[5] of the OpenGL gears demo to kitty terminal graphics protocol.

* And there's even a "full graphical web browser for Kitty terminal with mouse and keyboard support"[6][7].

---- footnotes ----

(Content advisory for links: Kitty terminal graphics protocol spec includes a sample image whose subject has requested that the image no longer be used for such purposes.)

[0] https://sw.kovidgoyal.net/kitty/graphics-protocol/#terminal-...

[1a] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlli...

[1b] This approach appears to be the method used by the mpv implementation: https://github.com/mpv-player/mpv/commit/874e28f4a41a916bb56...

[2] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlli...

[3] I'm aware that not everyone will think static or dynamic image display is something a terminal "should do" but to me it seems better to have actual image support in terminals rather than use (already currently used) existing "hacks" that provide a poor facsimile of support[4].

[4] Then again, I'm also of the opinion[4a] that perhaps terminals should support actual graphical UIs rather than the poor facsimile of them delivered by TUIs. *cough* :D

[4a] Motivated by the thought that at the current point in time perhaps the "essence" of a "terminal" is its linear "chronological" presentation of input/interaction/output history rather than its use of "text". (See also: "lab notebooks" & some tiling window manager features.)

[5] https://github.com/michaeljclark/glkitty

[6] https://github.com/chase/awrit

[7] Which I imagine DEC is turning in its grave about. :)

...though with the slightly unexpected side effect (for Brotli, at least) that your executable may end up containing (~200KB, from memory) of very unexpected[-1] plain text strings which might (& has[0]) lead to questions from software end-users asking why your software contains "random"[1] text (including potentially "culturally sensitive" words/phrases related to religion such as "Holy Roman Emperor", "Muslims", "dollars", "emacs"[2] or similar).

(I encountered this aspect while investigating potential size optimization opportunities for the Godot game engine's web/WASM builds--though presumably the Brotli dictionary compresses well if the transfer encoding is... Brotli. :D )

---- footnotes ----

[-1] An aspect also previously mentioned on HN: https://news.ycombinator.com/item?id=27160590

[0] "This needs to be reviewed immediately #876": https://github.com/google/brotli/issues/876

[1] Which, regardless of meaning, certainly bears similarities to the type of "unexpected weird text" commonly/normally associated with spam, malware, LLMs and other entities of ill repute.

[2] The final example may not actually be factual. :)

My personal favourite GIF-related explainer:

* "What's In A GIF": https://www.matthewflickinger.com/lab/whatsinagif/

It's a five part explanation that includes both great visualisations and bespoke analysis tools[2].

Here's a direct link to the section on LZW compression[0]:

* https://www.matthewflickinger.com/lab/whatsinagif/lzw_image_...

[0] Which somewhat confusingly credits "John Barkaus's LZW and GIF Explained" which actually turns out[1] to be... the text of "LZW and GIF explained----Steve Blackstock" via a news group post by John Barkaus (and is the text at OP's HN post URL).

[1] http://web.archive.org/web/20050217131148/http://www.danbbs....

[2] Including this fantastic example of visualizing individual sections of a multi-part binary file format, the UX/UI of which I think would be a great addition to a "hex viewer" application: https://www.matthewflickinger.com/lab/whatsinagif/gif_explor...

For an alternative perspective on testing & game development, here's a video I've seen from few years ago:

* "Automated Testing of Gameplay Features in 'Sea of Thieves'": https://www.youtube.com/embed/X673tOi8pU8?si=uj_lcMEC9nvMpa6...

~via https://www.gdcvault.com/play/1026366/Automated-Testing-of-G... :

"Automated testing of gameplay features has traditionally not been embraced by the industry, due to the perceived time required and difficulty in creating reliable tests. Sea of Thieves however was created with automated testing for gameplay from the start. This session explains why automated testing was the right choice for Sea of Thieves and how it could benefit your game. It shows the framework that was built by Rare to let team members create automated tests quickly and easily, the different test types we built, and what level of test coverage was found to be appropriate. The session also contains best practices for making tests work reliably and efficiently, using clear worked through examples."

Looks like there's also related talks in later years (which may or may not be currently available as free-to-view--I've not watched these ones):

* "Lessons Learned in Adapting the 'Sea of Thieves' Automated Testing Methodology to 'Minecraft'": https://www.gdcvault.com/play/1027345/Lessons-Learned-in-Ada...

* "Automated Testing of Shader Code" (GDC 2024): https://schedule.gdconf.com/session/automated-testing-of-sha...

> And I won't even start on all the things wrong with "just map both to up arrow" holy cow.

Could you humour us with just a couple of the things wrong with it? Cos I'm certainly interested to learn more about it. :)

BTW, with regard to specifying "true" RGB colour related escape codes, note that there's currently a couple of... "issues" with the content in this section: https://www.arp242.net/safeterm.html#true-colours

1. The format of the escape codes given for "True color" is "incorrect"[0], as it "should"[1] use `:` as the separator between the individual red, green & blue values supplied.

2. There is a minor typo/copypesto in "Foreground", where "R" is incorrectly listed twice and "G" is missing.

--- footnotes ---

[0] By "incorrect", I mean "not spec compliant", however, given the author expresses a sentiment of/preference for "I don’t care what some spec says; I care about what works" this presumably motivates their inclusion of the "non spec compliant" form in preference to the strictly spec compliant form[2]. :)

[1] The TLDR being that the entire colour specified by the "RGB" values is a "parameter" (and thus should be separated/surrounded by ";") but the individual "R", "G", "B" values are "parameter sub-strings" (a.k.a. "sub-parameters") and thus "need" to use a different separator: ":", the parameter sub-string separator.

However, for reasons[3], historically ";" was initially incorrectly used by some terminal emulators ("xterm", in particular) as both the parameter separator and the parameter sub-string separator. This error was apparently eventually discovered & corrected in xterm but the correction was not necessarily implemented/propagated to other existing/new terminal emulator implementations--or other tools that parse or generate the colour-related escape codes[4].

[2] This sentiment/preference is not shared by everyone, however, for example, the developer of WezTerm notes in its escape code reference documentation: "The colon form is unambiguous and should be preferred; the semicolon form should not be used by new applications and is not documented here in the interest of avoiding accidental new implementations"[8]. :)

[3] Money, or rather, lack thereof. The reason for the original error has been explained as "We [incorrectly] used semicolon [...] for separating the R/G/B values in the escape sequence, since a copy of [the related standard/specification] which presumably clarified the use of colon for this feature was costly."[5][6]

[4] The distinction between use of ";" vs ":" is also not only of "academic"/historic relevance--within the past month (while developing a customization[9] for WezTerm) I ran into an issue caused by spec-compliant vs non-spec-compliant implementations[7] between WezTerm (which generated spec-compliant colour escape codes) and at least some version(s) of `journalctl` which failed to parse & display a log message formatted with the spec-compliant colour and instead displays `[89B blob data]` (by default). This necessitated "munging" the correct escape codes into an incorrect abomination[10] in order for the log message to be formatted & displayed as intended by `journalctl`.

[5] See: https://invisible-island.net/xterm/xterm.faq.html#color_by_n...

[6] For the "Too Long; Did Write:" version of the explanation see the two comments I wrote a year ago when I last fell into this particular rabbit hole, :D here: https://news.ycombinator.com/item?id=35157058 (When the digging leads to learning about the connections to conventions originating in the era of telegraph operators & Morse code, it's probably time to turn around. :D )

[7] To me this suggests one reason to continue using terminfo as a layer of abstraction even when e.g. "all current terminal emulators do the same thing", is that it's one way to reduce the risk of unintentional future deviations in behaviour by existing or new terminal implementations.

[8] The WezTerm escape code reference document is another useful resource for terminal escape code information (written from the perspective of an implementer) that also links to similar reference documents both for other terminal emulator implementations & an attempt to "catch them all": https://wezfurlong.org/wezterm/escape-sequences.html

[9] Reimplementing the Mac Terminal.app ability to display a "faded" scrollback history/context for each tab when restoring a terminal "session"--which is one of only a couple of things that I miss since moving from Mac to Linux as my primary computing environment.

[10] Which was obviously--being the "person of a certain disposition" that I am--both deeply upsetting, and, just, wrong. :D

On the subject of replacement parts cost vs total Apple 1st party repair cost, a recent video I watched by UK YouTuber "Mrwhosetheboss" did a comparison of cost, turnaround time and other aspects between three different iPhone repair options and highlighted some of the dynamics at play:

* "Phone repairs are getting ridiculous - Here's why.": https://www.youtube.com/watch?v=oreZytDYoEU

From my admittedly biased outside perspective, the repair process he experienced (and previous coverage by multiple other outlets about "DIY repair with official Apple tools") certainly strongly suggests that Apple is trying to do as little as possible in terms of pricing & availability to support 3rd party or DIY repairs to meet their legal/PR obligations.

So, if official 1st party parts pricing isn't competitive with total 1st party repair cost I'm going to assume it's intentionally obstinate behaviour and that the blame lies wholly at Apple's feet.

Note that it seems some details of the spec have changed since the blog post was written, so the linked blog post is slightly outdated/lagging behind the actual spec document here: https://man.sr.ht/~bitfehler/m2dir/

(Which I discovered when I ran into this project yesterday.)

via conversation on the mailing it seems there are currently two WIP Rust crates/libraries being developed to implement the spec--one by the primary spec writer & another by an "email-interested" :) 3rd party, developed independently (AIUI) in part as an exploration of library API design space.

> so i'm far less concerned with the answer.

In that case, let me definitely take the time to provide you an answer then... :D

The linked blog post outlining the spec is slightly outdated/lagging behind the actual spec document here: https://man.sr.ht/~bitfehler/m2dir/

The updated detail relevant to your query being: the `:` separator was replaced by use of `,` (comma) as the separator instead: https://man.sr.ht/~bitfehler/m2dir/#parsing-filenames

More detail on the reasons for the change is given in the associated commit message [informative commit messages? what a novel concept! :D ]: https://git.sr.ht/~bitfehler/m2dir/commit/100b7683f53899c836... [TL;DR: bash & NTFS/ADS]

> empowered people to make lots of small useful utilities

Specifically related to this aspect, currently the closest thing I'm aware of that comes to mind is the Godot "game" engine: https://godotengine.org

While it's not an exact match for Hypercard in many aspects, three of the related areas where it is a particularly strong contender are:

* A small initial download size (<100MB) and short load/launch load time.

* Supports an "iterative"/hacky development process well--GDScript is very well suited to the initial "exploratory development stage" of "making something that works". (As GDScript itself evolves it's also getting better at being robust over time via recent additions such as gradual typing.)

* Godot's distribution/installation story is very strong--I would posit that it is light years ahead of any other ecosystem[0] in this area: Download the export templates (which are generic platform-specific binary executables) for the platforms you want to support and then export your project (which packages your project-specific code/resources for use with the executable)[1].

Currently, I would say the place where Godot is currently most lacking (somewhat surprisingly) in comparison to something like Hypercard or ("classic") Visual Basic is in relation to a lack of "drag and drop UI" creation. Godot has a quite powerful UI system (albeit at times... opaque) but the current UX for building the UI forces one to be very conscious of the scene's node tree rather than being able to just drag and drop widgets from a toolbar, or similar, onto a window.

(This UX is also an aspect that seems could be improved "relatively easily" via an Editor Plugin and maybe one day I'll get around to prototyping something for that particular rabbit hole. :) )

Obviously, it's not a perfect solution for numerous reasons I won't go into now but it's certainly my default choice for any GUI-based utilities these days--some of which I actually finish enough to "release". :D

[0] This aspect is where Python in particular falls down catastrophically.

[1] This also extends to being able to produce WASM exports for the web which opens a two-pronged distribution approach where people can initially use a web-based version of your utility and, if it's useful enough to them, they can also download an executable for local use.

After some brief research it seems the issue you're seeing may be a known bug in at least some versions/release of espeak-ng.

Here's some potentially related links if you'd like to dig deeper:

* "questions about mandarin data packet #1044": https://github.com/espeak-ng/espeak-ng/issues/1044

* "ESpeak NJ-1.51’s Mandarin pronunciation is corrupted #12952": https://github.com/nvaccess/nvda/issues/12952

* "The pronunciation of Mandarin Chinese using ESpeak NJ in NVDA is not normal #1028": https://github.com/espeak-ng/espeak-ng/issues/1028

* "When espeak-ng translates Chinese (cmn), IPA tone symbols are not output correctly #305": https://github.com/rhasspy/piper/issues/305

* "Please default ESpeak NG's voice role to 'Chinese (Mandarin, latin as Pinyin)' for Chinese to fix #12952 #13572": https://github.com/nvaccess/nvda/issues/13572

* "Cmn voice not correctly translated #1370": https://github.com/espeak-ng/espeak-ng/issues/1370

Yeah, Pink Trombone is awesome[0]. :D

Thanks for the link to the programmable version--I don't think I'd been aware of that previously...

[0] And, from personal experience, also rather difficult to "safely" search for if you don't quite remember its name exactly. :D