This looks like it might bring windows on par with OSX for MIDI, but while windows has that terrible driver architecture that allows for one hardware driver to interrupt another hardware driver I'm afraid audio will always be second to OSX.
These "Deferred procedure calls" are ever present and make windows audio completely unpredictable. Having random audio buffer underruns because your video card decided to do something that stopped the OS from sending data to your sound interface is really a big problem.
This is awesome! I started experimenting with LLMs and Ableton over the break too. I used a few off the shelf VST templates to create a VST that leverages an LLM that can create LilyPond format music. This creates multi track VST output (MIDI) from the parsed LilyPond. I have a system prompt that explains LilyPond to the LLM (it already knows anyhow), and then I give it a prompt like "Megaman, 64 bars, ice man level", and it pumps out 4-5 tracks of MIDI that is just what I asked for. I get nice sheet music on top of that.
I like this because I'm really in the creative process still, it feels like a tool like "Scaler" (nice tool btw) where you're picking origin notes, but really putting the song together yourself. It can suggest "Synth Bass" but I'm the one assigning it from one of my other VSTs sounds, mixing, picking, etc.. And if all goes well playing some lead on the guitar or seaboard and then deleting it all and starting over.
> "As the letter states, based on the agency's thorough review, neither the Numident database nor any of its data has been accessed, leaked, hacked, or shared in any unauthorized fashion," an SSA spokesperson told The Register. Again, no mention of that copy.
Wouldn't "any of its data" qualify as an answer to the question: "was the data in the database leaked"? It seems like SAA did answer, but we needed to generate clicks.
I'm not at all surprised that the majority of top level comments are saying things in the spirit of "Trump is trying to kill us to make money!" when if you were following along this _multi decade long regulatory battle_, and knew about the not-so-recent Chevron Deference rulings you could have predicted this. You wouldn't even need to leave HN to keep up, it gets posted here all the time!
And these comments have an air of erudite smugness about them that can only come from a person completely without doubt of their convictions - even while being completely devoid of any value to the conversation.
The title is at best hyperbolic and at worse at outright lie - in any case the pattern of the title was intended to stoke whatever mental illness we see at play here: "I speculate endlessly on my own world view to the theme of the article title so I can signal to my peers that I'm doing righthink.".
But this is what makes the article get engagement, so to hell with communicating ideas, let's stoke division and get those clicks!
Conspiracy theories coming true are going gangbusters as of late. Maybe they should be re-labeled "narratives that while they are true might disrupt the current power structures so we will paint anyone who believes them as a loon.". For every "we didn't land on the moon" there are several fairly devastating theories that turned out to be very true:
Ahhh yes, the current conspiracy theory that is about to crack. Watch the propaganda at full power. Better than the wiki article do a web search for "covid 19 origin" and watch as "Eco Health Alliance" pops their sponsored ad at the top of the search results, for those not studying the topic ecohealth is the the group that created the virus project (https://theintercept.com/2021/09/23/coronavirus-research-gra...) DARPA said it was too dangerous so they rejected it, so they went to the NIH who gave us COVID19. The NIH has already been caught dead to rights paying specifically for "gain of function research on bat coronaviruses in the Wuhan lab" from which the virus escaped. And if you read that wiki article, it still a "conspiracy theory". (https://abcnews4.com/news/nation-world/nih-letter-conflicts-...).
I wonder if the wikipedia editors will allow you to update the page with this "new" information. Something tells me this page is locked. So with this one we can watch the "conspiracy theory" slowly turn into just a plain old boring "conspiracy" and everyone can say "See! We all knew the whole time! It was super obvious!" like the rest of the list.
Crazy how these very true super evil transgressions by our own government get balled in with "the earth is flat" huh. Almost like it was intentional. Oh right operation mockingbird, duh!
> In March last year more than 180 staff wrote a letter to leadership expressing “serious concerns” about the organisation’s approach to diversity after it appointed four men to senior roles.
If you change the sex and it becomes a sexist statement, it was always a sexist statement.
I politely pointed out that this previous submission "Stop using REST for state synchronization" (https://news.ycombinator.com/item?id=43997286) was not in fact ReST at all, but just an HTTP API and I was down voted for it. You would think that programming is a safe place to be pedantic.
It's all HTTP API unless you're actually doing ReST in which case you're probably doing it wrong.
ReST and HATEOAS are great ideas until you actually stop and think about it, then you'll find that they only work as ideas in some idealized world that real HTTP clients do not exist in.
The Sloot Digital Coding System is an alleged data sharing technique that its inventor claimed could store a complete digital movie file in 8 kilobytes of data — which, if true, would dramatically disprove Shannon's source coding theorem, a widely accepted principle of information theory that predicts how much data compression of a digital file is mathematically possible. The alleged technique was developed in 1995 by Romke Jan Bernhard Sloot (27 August 1945, Groningen – 11 July 1999,[1] Nieuwegein), an electronics engineer from the Netherlands.[2] Several demonstrations of his coding system convinced high-profile investors to join his company, but a few days before the conclusion of a contract to sell his invention, Sloot died suddenly of a heart attack. The source code was never recovered, the technique and claim have never been reproduced or verified, and the playback device he used for demonstrations was found to have contained a hard disk drive, contrary to what he told investors.
> 1. Do you use the CRDT document as the source of truth or as just synchronization with a database as the source of truth. If the document is the source of truth, do you keep data in it or copy the data into some other format that's easier to query?
The DB is the source of truth (DynamoDB, spanned binary chunking) and holds the YJS binary document which is also the source of truth, so I guess the doc? I keep a number of copies of this document in different states because of my aforementioned distrust of computers. 1) Per edit event is recorded as S3 JSON, 2) per edit binary document is kept in dynamoDB, 3) per edit serialized JSON of the document content in S3. This trail of breadcrumbs keeps my anxiety down and has in the past helped recreate documents when "something bad" happened. Something bad was always _my_ poor implementation of YJS causing the document to either grow too big or start throwing warnings - both of which are catastrophic IMO if you're maintaining documents for 3rd parties. The document is kept in sync with a vector state exchange lambda that loads the "latest" document from dynamo and compares the client vector state to the server's "latest" in the DB and responds with a delta. All of this is binary which is a bit unnerving. YJS provides ways to dip into that data stream but it's equally unnerving to unbox the complex CRDT schema in the guts of the lib. When writing data I use dynamo DB's exclusive write mode where conflict writes (based on a version number) will go into a retry mode which at worse costs a few extra ms. This ensures that "latest" never loses an event with concurrent overwrites. I rely on this and the CRDTs communicativity to make sure no writes are ever lost. Since the lib is "local first" all this interaction is transparent to the user.
> 2. How do you handle changes to the schema of the CRDT documents?
I defined a new hypermedia specification, basically HTML as JSON. {id, parentId, type, props, events, acl, childIds}. I make a flat map and build a hierarchy for my editor, then flatten it back out to save it saving the child's Ids to maintain order when building the linked list from the ymap object (hashmap).
This makes it so the core schema never changes, only the type (aka tag) changes and the props/events def from that type. This all is defined in a swagger doc which allows for this type of schema definition. This is reused at runtime for schema validation.
To introduce changes I introduce new types (aka tags) so if I had "type: ThingV1" now I have "type: ThingV2" with a new contract. This also helps with the downstream artifacts from the programs as the devices that get the schema can ignore types they don't implement and use the ones they do, and we can put them both on the same response who's core endpoint should always be v1 because the core schema never changes (thanks W3C for the idea).
> 3. How granular do you go with documents in the spectrum of "one per user" to "one per object"?
It depends on the requirements for the projects, but in all cases the documentId is the partition key for the dynamoDB allowing proper scaling. The content of the document is many per user, sometimes hundreds of documents per user. There is absolutely no query surface for these documents, you can only look them up by direct ID. There is another system that keeps track of the document directory and I would add a query surface of some sort there via event projection if I needed to query my documents - which I fortunately do not.
So far so good! The only thing that is pricy is the breadcrumbs which I'll start tuning to store less as I'm probably coping the same data 5x or more.
If you're hesitating to use YJS take the word of someone who took the plunge, it's totally worth it on the other side.
I've written several apps now with it now. Very easy to use and quite robust to failures. It's a bit of a mental load to take on at first but it's totally worth it for the problems it solves out of the box. I've tried other things too from rolling my own ES stack to OT and more.
Lately I've got it running on AWS API Gateway V2 over websockets to lambdas + DynamoDB with a small army of daily users. The only expensive part is the event audit logs I keep due to my inherent mistrust of all computers.
What part of this implementation is ReST? I see a CRUD API that uses HTTP verbs. State transfer implies multiple steps at least, where I call the initial API which then returns several other API endpoints "transfering the state" typically in a HATEOAS style - perhaps that part isn't required.
> ... although this term is more commonly associated with the design of HTTP-based APIs and what are widely considered best practices regarding the "verbs" (HTTP methods) a resource responds to, while having little to do with REST as originally formulated ...
Ah, I see, the industry has taken to just calling HTTP ReST for no apparent reason.
As far as not being sure about CRDTs, these protocols were made to overcome the obvious and terrible shortcomings of CRUD APIs (lack of communicability and idempotency). Who ever wants to see "the data on the server has changed, do you want to overwrite the data on the server or overwrite your local copy". If you're not doing some sort of event sourcing for state management (ES, OT, CRDT) you're probably doing it wrong or doing it for a simple project.
It's a popular non-netflix/google video streaming app that you've maybe heard of. HTML5 apps/sites/whatever are just part of our supported clients. All clients are supported by a largish SOA. All of the HTML clients are indeed sites, SPAs on a CDN to be more specific, and not "apps" but this is the sickly nomenclature our industry has adopted. But I really should have called them sites if I want to motivate others to do the same, thanks for the correction.
Very nice! I wish this was the world we lived in. I'm from the before times, when W3C stuff was all we had, and it was miserable because it was so immature, and we hired people who "knew jQuery, but not JS". But if I'm being honest post query selector frameworks don't have a strong cost benefit argument - testing frameworks notwithstanding, which are quite lovely.
I run sites that serve hundreds of millions per day and we pour a ton of resources into these projects. We're trapped in a framework (react) prison of our own creation. All failures are those of complexly. Highly coupled state machines with hacked, weaved, minified, compiled, transpiled, shmanzpiled etc. into unreadable goop in production. Yes I know source maps, but only when needed, and they are yet another layer of complexity that can break - and they do. How I long for the good old days before frameworks.
Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework.