Are you sure about that?

If each core can process 1 "video artefact" every minute, with 8 cores that's 8 artefacts per minute. If they can now produce 16 artefacts each per minute, that's 120 artefacts per minute. That's still just 16x quicker it seems?

Surely you mean an "Emulsified high-fat offal tube"? https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3F...

This specific copyright troll has also been covered in some detail by copyright lawyer Leonard J. French in his YouTube videos. He and his co-counsels recently managed to overturn the first case to reach jury trial (or more accurately just before it reached jury trial, naturally!)

He wrote a brief article about it on his site: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Ftorrentdefense.com%2Fdef...

There indeed seems to be a conflation of 2 themes here. I grew up with manual transmissions, but have driven autos for about the last 10 years - in fact my current car has the ZF-8HP discussed above. I wouldn't change it for the world - it works reliably, and makes my daily commute crawling down the motorway infinitely more tolerable. Is it "better" than the manual it's replacing? I would say almost certainly! There's no clutch plates to burn out, I don't have to worry about shifting all the time in traffic, it's responsive and it can shift far quicker than I ever could, and indeed I can use the paddles to engage whatever gear I want to and have it stay right there (as long as I don't bang it off the rev limiter actually, but then that's the manufacturer for you, as you said).

The advantage here, therefore, isn't about the performance of the gearbox. It's the "tactile" component of driving a manual. The feeling of being more a part of the driving experience and being in total control of the amount of torque you're putting into the wheels through the combination of gear choice, clutch and accelerator. The total control over the RPM of the engine. It doesn't make you a "better" driver, it probably won't make the drive more efficient, it won't enable you to change gear more quickly, but it puts you in one-to-one direct control with the drive, and that's something you just don't quite get with an auto box imo. Yet with all that said, I'll stick with my auto as being a far more practical choice.

Leaving aside the question of whether such an artificially produced sound is a desirable thing or not, I find the actual implementation here somewhat underwhelming. I watched the linked video to hear it in action, and it sounds just too synthetic and unrealistic.

As a point of reference/comparison, I recently watched a video where someone had created an engine simulator specifically for the purpose of replicating the noise from it (not just V8, but potentially other configurations too). While not perfect, it's an incredibly neat trick and sounds pretty good in my opinion, especially in that it can attempt to replicate engine braking/overrun too.

The TL;DR wow-factor is that it works by making use of rigid body physics simulation as well as fluid dynamics simulation for airflow. It's these elements that feed into the audio synthesis to produce the audio waves which are then fed into a chain of audio filters. Apparently it's accurate enough to be able to calculate torque/horsepower curves for a given engine (to within a claimed 10%). Impressive stuff!

The video link is here: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3F...

And yes, it's open-source too: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fgithub.com%2Fange-yaghi%2F...

While I absolutely agree with this, I would also wistfully opine that the best thing (imho, of course) that could have happened to JavaScript but never did... was ES4.

As a former ActionScript 3 developer, I was always a little sad that JavaScript skipped ES4 for ES5, but thankfully it looks like things are finally catching up, even if 16 years late! ES6 brought classes 9 years after AS3 (lacking interfaces and namespaces, however), and TypeScript built upon those features nicely, even before its finalization a few years later.

While I don't actively use AS3 (obviously) or TypeScript myself much any more in my day-to-day coding, I do encounter TypeScript often enough to see it evolving into a pretty workable and usable language that I quite like, unlike JavaScript alone which I really don't. These days I still do C and C++, but for my scripting needs I lean towards Python, for all its sins!

It's almost certainly not the aircon that requires the chip (they even state in TFA that it works fine when controlled from the front of the vehicle). It's the controls themselves that are the problem.

Pretty much all vehicles built in the last 20? 30? years make extensive use of the CAN bus (many/most have several busses). So if you think about something as trivial as your electric window switches, instead of having to run cables from each of the four corners of the car to each other (to set up 2-way switching to allow the driver to control all the other window in the car, for example), and then back to the motors in the respective doors, they simply run a single pair of wires from each to the nearest control module connected to the CAN bus. This then sends messages to the module responsible for handling the windows (the Body Control Module typically) which then controls the window motors.

The benefits of this are that when you press and hold the lock button on your remote control (received by the BCM too), it can roll your windows up whilst also locking the car. Or if you have a crash, the windows can be rolled down automatically. And all this achieved using less copper wire running through the vehicle, making for less weight and usually less cost.

Now multiply that by lighting, reversing cameras, sensors, locks etc. Makes for quite the reduction in wiring and increases the opportunity for centralised automation.

As I understand it, the device (or RPi or whatever you like) doesn't *just* connect to "diagnostic" ports, but actually operates in a "man-in-the-middle" mode between the front control panel and the machine's controller (i.e. able to "press" the buttons and intercept the SPI/I2C data from the LCD display). This enables it to automatically enter the "hidden" diagnostic menu, obtain the cryptic information contained within (by automatically going through the obtuse sequence of button presses required to do so), and then present this in a Web 2.0 interface to the franchisee in a way that actually makes sense - very similar in that sense to presenting OBD2 data as others have suggested.

I don't remember where exactly I saw that detail, so take with the usual grain of salt, but I believe that's actually an integral part of how it works. Might have been a Leonard French YT video on the initial legal shenanigans, but can't remember. Tony

I own and use a second-hand Oculus Rift CV1, almost exclusively for use with flight sim MSFS 2020 (when it works, that is). Hardly the most cutting-edge of VR headsets, and frankly the resolution is fuzzy at best, but for the price (around 150 pounds) it can't really be beaten. It's hard to justify spending much more on a niche product.

I'll occasionally fire up a game of Beat Saber, or Moss; I've dabbled with Fallout 4 VR but didn't really find it particularly playable, but the killer app for me is definitely Flight Sim where depth-perception is intrinsically important to the experience.

I'm not sure what causes the issue, or if it's been resolved yet, but at least one or two updates ago, it stopped working correctly in MSFS 2020 - the menu works fine, and you can enter the plane just fine, but the moment you start flying the display turns off/black (although the game still shows it rendering on the main monitor). Have tried using both Oculus and Steam VR as the OpenXR runtime without any difference, so hopefully it's something that will get resolved in due course.

My understanding is that:

In Europe (via the EOBD interface) or the US (via OBD2 interface), essentially identical in protocol, the _basic_ (i.e. generic) error codes are indeed standardised, and must be made available to the consumer (or indy repairer). The OEM however is free to add additional OEM-specific codes (and they do!) and while information can often be found on the internet for those codes, they're not part of the standard.

In Massachusetts, the 2012 Right-to-Repair initiative extended that so that the consumer must have access to the _same level_ of diagnostic information available to the OEM. I'm assuming this would extend to the extended error codes that are more specific?

By basic code, I mean a code which might indicate an "ignition fault" as opposed to an OEM code which might indicate what the actual fault is - is it a voltage issue, a short-circuit, premature ignition firing etc., something much more useful for diagnosis. (Probably a poor fictional example there, but that's my way of seeing it).

I don't believe for a minute that people are looking for the ability to upload custom firmware to the various modules in their vehicles - sure that might be cool, but I can see how that could be a safety issue - but being able to re-flash original signed firmware should certainly be possible, as should reading out whatever information is required to diagnose a problem, and to perform whatever coding actions are required to replace parts and/or modules. Currently such things are often dealer-only and that often means $$ rip-off prices.

On a related note, I doubt this is solely about repairability anyway - for instance, if you have a relatively recent BMW you may discover that you don't have the ability to play music via bluetooth from your phone, despite having the "Bluetooth prep" package installed. Of course, this is solely because that feature is charged separately and has nothing to do with hardware. Can it be enabled later? Absolutely, as long as you have the right adaptor and the appropriate software - it's as simple as setting the right flags to enable it. But given the moves in the industry to switch to subscription-based models, as well as these software-lock based feature sales, that's probably among the larger concerns the industry has around making things accessible? Or perhaps I'm being too cynical in my old age?

Tony

While this is a valid question, I think what's more appropriate to ask is much more basic: "Should any and all parts of smartphones be available and the manufacturer be prevented from restricting their availability?". I'd settle for simple availability of [OEM] parts first rather than quibbling about how long those parts should be made available for.

Or how about the missing option there: "As long as they want to keep manufacturing and selling them and/or for however long there's a market for them?" I'd rather not be hung-up on the disconnect between where the parts should come from and for how long, and the basic premise of actually being able to obtain parts without being prevented from doing so by the device manufacturer whether by stifling of the supply chain via legal threats, or by applying unnecessary software locks to replacement parts, for example. The supply logistics are just that - logistics. If there's a demand, the "free market" will solve that by itself. What's much tougher to resolve is legal barriers and needless DRM obstacles, and it's this latter part that warrants due scrutiny and regulation/legislation.

Not sure if you're joking, but it's a 32-bit unsigned integer. It just happens to be representing a value which humans prefer to read as a fixed-point value (which is just the value scaled by a factor of 10000). The integer value is therefore absolutely an integer which is counting the number of hundredths of a cent - how that is displayed is irrelevant.