if you ignore the slurs and pretend the piece is written in 4/4 (which I do for the sake of this), the last measure actually could plausibly precede the first measure (this happens where the sheet music shows the direction "du bout de la pensée"). But I don't think it would be as interesting a listen, and it wouldn't have been a very fun project.
Well, it depends on how you feel about "appropriating" the original vs. feeding it to a Markov chain. I don't think less code/no code is necessarily boring, nor would a more complex LSTM model of the music necessarily be more interesting.
I was thinking of a non-digital piece by Rodney Graham, where he retypeset a few pages of a book so that a looped reading became possible:
"In Lenz of 1983, for instance, Graham appropriated an unfinished novella by Georg Büchner in which the mentally unstable protagonist, Lenz, wanders through a forest. The artist reset the type on pages one to two and on pages five to six of an English translation of the story, to set up a situation in which the page breaks at the same phrase ‘through/the forest’, which establishes a loop whose effect is to cause Lenz to endlessly repeat his journey by returning from page five to page two; in 1993 (fig.6), Graham had a reading machine constructed for this version of the text to facilitate the repetition, and the hardcover version of the 1983 work was a book bound with eighty-three repetitions of these pages, which in principle can be continued forever."
this kind of broad situation is hard to fix; usually a particular thought has a particular solution. Similarly, using a synonym lookup may hold you back. Look at what you want to say, not what individual words you'd pick without any constraints.
Most difficult is accounting for, and introducing into a chat, folks wholly unknown to anybody you talk to.
A trick is to try to say how you know of such folks, finding a path or paths along which you can form a link, such as "my dad's mom's son" or "my pal's husband's pal" or "a woman who knows my boss from an old job" or "I know of a particular lady's writings from a class I had at school".
This social platform's author own account within said platform shows an additional gimmick or option, viz., translation, insofar as you'd normally hail said author as "[small gray animal with a tail]", but within this platform's constraints as "[said animal, only in Latin]".
This is not so hard for participants whom you call with words common to kinds of things, kinds of animals, jobs, and so on, but possibly difficult for folks lacking a commonality of naming of this sort (viz., with "nomina propria").
(Sorry if "viz." is illicit on account of what it actually stands for... you can just think of it as "in particular" if you want.)
I was okay with using "imo" and "lol" in words in this discussion as full forms also lack taboo glyphs, and I concur that such with said glyph is tantamount to a violation.
A good point and strong advocacy, though @mus, who thought up this particular handiwork and built it from scratch (not all of lipography, just this journalistically-fascinating lipography discussion forum), and also said in this discussion, supra, "this kind of broad situation is hard to fix" and so on, was so bold today as to post "300" in a toot purporting to follow lipographic norms. Ipsa dixit!
But if you say "300" in words and not digits, you would say two words both lacking suitability for that forum. So I ask, possibly oratorically: by what logic is "300" OK if "viz." (or "BRB") isn't?
Words do not contain glyphs during annunciation. A man pronouncing a word is not a man pronouncing glyph 1, glyph 2, glyph 3 but sound 1, sound 2, sound 3.
So 300 is okay: I do not recoil from a foul glyph in it.
If you think so, don't you find "BRB" and "viz." OK too? My post's dad-post (though not by you) calls for avoiding such short forms on account of matching long forms' violations of lipographic norms.
Take the blockchain out of Etheruem, and you still have a pretty cool deterministic state-transition machine. My understanding of Urbit is very limited, but I believe it has a similar concept of Ethereum without a consensus protocol.
They're probably worth distinguishing somehow for newcomers. They're both transaction logs.
Ethereum is a transaction log with a consensus mechanism. Anyone can append to it. It's a scroll: any group or society can use apps that check the scroll to come to conclusions about the state of their interactions.
Urbit is a transaction log that only the owner can append to. It's a journal: users can safely append to their journal with any app, and their apps can read the whole journal to display data from multiple apps in desirable ways.
Which begs the question, why is Urbit necessary? It would be relatively simple to port Ethereum's consensus protocol to "only a user with key X can sign new blocks" and each block would contain exactly 1 transaction.
Mainly because (as Vitalik says) "the whole Ethereum network has the power of a 1999 cell phone."
Although Urbit (like Ethereum) is precisely defined without dependencies, Urbit is not a consensus computation platform. It's for processing your own data on your own (virtual or physical) machine.
Consensus computing is incredibly inefficient and should be used only where absolutely required. Where consensus is not absolutely required, computing should be localized under the user's control. People often forget to include this component in their designs of the decentralized future. But in fact, Ethereum needs something like Urbit and vice versa.
One way to think about the difference between Ethereum and Urbit: it's like the difference between a superconductor and a regular conductor. On the one hand, superconductors are qualitatively different and fundamentally more powerful. On the other hand, there are no superconductors in your iPhone.
I'd actually put Blockstack in the same category as Ethereum. From a transactional log perspective, it uses the Bitcoin blockchain for consensus on the log and from an application development perspective, you can build apps using Blockstack (gives you naming, auth, and storage).
