I'm Deaf and read lips.<p>Thanks for this extremely intriguing idea to use emoji to depict a talking person visually.<p>You know, some animated films get it right. Sometimes I clearly see utterances like «Thank you!», «Okay», but more often not. Especially older animations don't care and just let the character move the mouth in very simplistic ways: «Babbabbabaa Baababba ba baaa.»<p>Similarly for that emoji. It is moving the mouth in quite arbitrary ways. It looks like: «Sobbabbabee be <grin> seebee <grin> <frown> babbaa».<p>To solve this problem we need about twelve emoji for utterances: «ah», «ay», «ee», «oh», «oo», «b», «d», «f», «l», «n», «r» and «s». The «r» emoji must be animated (so we see the trilling tongue). The other sounds are either invisible like «k» or cover several different sounds like «b» also covering «m» and «p».<p>«Okay» would be rendered by: «oh», «oo», «oo» (standing for «k» wich is invisible) «ay» and «ee».<p>Edit: Add «th». This is an extremely simple sound to lipread. I remember my delight when I learnt English in my youth and in an movie suddenly realised that an actor said «Thank you».
One improvement might be to use a pronunciation dictionary and map the emojis to actual sounds rather than characters. Having recently needed such a thing, I found that there are two widely available datasets: CMUdict and Moby Pronunciator:<p><a href="http://onlinebooks.library.upenn.edu/webbin/gutbook/lookup?num=3205" rel="nofollow">http://onlinebooks.library.upenn.edu/webbin/gutbook/lookup?n...</a><p><a href="https://github.com/cmusphinx/cmudict" rel="nofollow">https://github.com/cmusphinx/cmudict</a><p>The problem is that they'd be pretty hefty payloads to load on the client, so you'd want to do the text -> phone mapping elsewhere. Then use your character mapping as backup for words that aren't in the dictionaries.
> an emoji, in reality, looks like this: “\xF0\x9F\x98\x81”<p>… well, that’s one encoding of the UTF-8 encoding of the Unicode code point.<p>> This is because setInterval(_=>{ },99) executes the function every 99ms<p>This is categorically wrong. You can’t trust setInterval to heed your request precisely at all: it’s a request that browsers take as a minimum only. Most browsers will call your function after the number of milliseconds you requested plus up to 16ms more, but some might wait even more than that (I think Safari in power saving mode doubles its tick time, to operate at 30fps; and background tabs typically won’t fire more than once a second these days).<p>Try running this snippet in your dev tools; it logs the number of milliseconds between calls:<p><pre><code> t=Date.now();setInterval(()=>console.log(-t+(t=Date.now())), 99)
</code></pre>
On Firefox I’m getting mostly 108–111, with the odd one a little higher, and a couple of 99s after running it for a few minutes.<p>(Some trivia on similar techniques for this measurement: `+new Date` is rather slow, `Date.now()` is about 7× faster in at least Firefox and Chrome, and `performance.now()` gets you microsecond precision (it returns a floating-point number in milliseconds, tied to an unspecified epoch instead of real-world time), and is a little slower than Date.now().)
Makes me think of Microsoft Comic Chat[0] this is kind of cool looking though, and definitely different.<p>[0]: <a href="https://en.wikipedia.org/wiki/Microsoft_Comic_Chat" rel="nofollow">https://en.wikipedia.org/wiki/Microsoft_Comic_Chat</a>
> Instead iterating through every byte like ""[n]<p>Pedantic note: JS iterates through UTF-16 2-byte code units. It's that way for compatibility reasons (used to be UCS-2), but it's the worst of both worlds: not as good as UTF-8 for ASCII, can't do operations in O(1) time like UTF-32.
This idea originated in the jsgolf community and dwitter (a site where you post 140 character js snippets that generate interesting visuals). See <a href="https://www.dwitter.net/u/aemkei" rel="nofollow">https://www.dwitter.net/u/aemkei</a>