alias fx="sox - -t wav -"
cat foo.wav | fx overdrive | fx reverb | play -
considering that sox has existed since the early 1990's, I'd wager that the demand for that isn't exactly huge
(note that in practice you'd directly use sox's play command to apply effects as it's certainly muuuuuuuuuuuch more efficient than to spin up a ton of processes which'll read from stdin/stdout)
I've never actually used sox for fx, I wonder how good they are. (I have used it plenty for resampling, normalization, trimming, etc). But regardless, there's thousands of VSTs out there -- a lot more options than whatever sox has built in.
That's an interesting idea that you should be able to build on top of Pedalboard -- i.e., implement a CLI that accepts input and output file paths (and optionally support piped data, as in your example) and expose the VST plugin names and their options i.e.
That's easy to do if you first strip the WAV formatting stuff and then at the end add back the format information.
You can't really do it without that, because sound.wav contains both actual audio data and "metadata".
In the real world however, almost nobody who has done this sort of thing actually wants to do it that way. The processing always has a lot of parameters and you are going to want to play with them based on the actual contents of sound.wav. Doing this in realtime (listening while fiddling) is much more efficient than repeatedly processing then listening.
I find that red delicious actually tastes quite good if you manage to eat it before it becomes mealy. Sweet, juicy, crisp bite. The problem is just that they become mealy relatively quickly.
>Instead, Open.HD configures the Wi-Fi adapter in a way that is closer to a simple broadcast, much like analog video transmission hardware you may be using already.
Would this be able to broadcast a video which multiple clients could playback in sync? In the 90s, when you were watching TV, if you had a TV in the kitchen and a TV in the living room, if both were tuned to the same channel, they'd play back exactly in sync. Would this project enable something similar?
Modern TVs (anything that doesn’t have an analogue-only path all the way to the display, which is probably almost every TV sold in the last 10-15 years) are designed in a way that (unintentionally) disregards the importance of predictable signal-to-visibility delays.
Basically this is because all modern displays have a digital path from their (primarily digital) inputs which always (even if it’s “disabled”) includes signal processing to convert the incoming signal (of varying resolutions, refresh rates, color spaces, etc.) to signal(s) which can be sent to the LCD (either through the TCON embedded in the side of the LCD or through some custom ASIC that directly generates the analogue waveforms to drive the matrix of Liquid Crystals), backlight driver(s) (because artificially-measured contrast ratio numbers can be seriously enhanced for marketing), audio outputs, etc.
That’s on top of the extra image processing features that many TV’s advertise (“smooth motion”, “200hz”, etc.) which generally require the video DSP to buffer one or more frames to perform the processing (and maybe generate intermediate frames). These additional features can often be disabled by enabling a “gaming mode” which is (usually) designed to reduce perceptible input latency but this is not always implemented correctly by the manufacture and most reviewers don’t perform end-to-end latency measurements so there’s not much incentive for manufacturers to do much better than “ok”.
Analogue-only CRT TVs didn’t have nearly the same complexity (or features) in their signal processing and could reliably be trusted to display a given input with a minimal delay, mostly due to the fact that they didn’t have any (significant) form of memory to buffer signals for processing.
If I recall correctly, there was an era in analogue broadcast where the signal that was generated in the studio broadcast camera became the synchronisation signal for every TV that was tuned to that channel which essentially means that a TV tuned into that broadcast would actually scan the electron beam across the CRT at exactly the same rate and time as all the other TVs on the same channel. This required careful signal design to ensure that a “cheap” TV with poor timekeeping could still synchronise its operation with the incoming signal but it was far more practical/affordable than trying to buffer an entire frame given the technology at the time.
To answer your question directly, it might allow you to have synchronised broadcast to multiple TV’s but it may require playing with the output resolution/refresh rates of your OpenHD receiver and with the settings on the TV (try looking for a “gaming” picture preset).
i think the issue there is that modern displays decode the signal at different rates, depending on their changing hardware (HDMI/display technologies). with old TVs, the signal was not really decoded, but projected directly onto the "glass".
so i imagine it would still not be in sync unless you have two of the same TV.
Unfortunately, last I checked, shellcheck is not compatible with M1 macs yet. I love the tool so much that I while I wait for compatibility, I manually check my shell scripts at the web UI.
Yeah, there are still issues with Haskell and the new Mac architecture. Pandoc and ShellCheck are two of the essential tools affected. In the case of ShellCheck, I just downloaded an x86 binary from the GitHub Releases page and put it in /usr/local/bin. Good enough for the time being.
That type of exception is explicitly stated in the CEOs blog post:
>We focus minimally on causes not directly related to the mission
>Policy decisions: If there is a bill introduced around crypto, we may engage here, but we normally wouldn’t engage in policy decisions around healthcare or education for example.
I enjoyed this article. It also included links to other studies indicating how often doctors and nurses wash their hands and studies about the effectiveness of hand washing.
Sure, but I read the whole thing and while it was amusing, I still have no idea "why" doctors don't wash their hands. They forget? They don't want to? They don't believe it's worth it? The article doesn't say at all.
The article provided a WHO list of "barriers to adherence with hand-washing guidelines", but that isn't the same thing as explaining the behaviour.
What does explain the behaviour? Nobody knows for sure yet, hence the article exists. If we investigate the profession of medicine in the same way as we might approach a diagnostic examination of any other profession or occupation, we uncover a whole category of possibility that the article doesn't explore.
Before I put forward this conjecture, which may shock and repel some of you at first, let me point out that it doesn't necessarily have to be occurring in a conscious mode. With that said, consider the business model of doctors.
Doctors are trained to diagnose and treat disease. They aren't trained in nursing. For that, they rely on nurses, who are their reliable, ever present subordinates. In terms of hours spent at the wheel, doctors are scarcely trained in disease prevention and hygiene at all, which account for only a tiny % of the curriculum in medical schools.
Do you want to know how to eat right, live healthily, and ward off a whole host of diseases? Consult a nutritionist. Doctors aren't trained in nutrition.
