Hacker Newsnew | past | comments | ask | show | jobs | submit | evo's commentslogin

I think there's a close linkage between "predictable" and "stationary". Ultimately, if you strip everything away, either there's a core where the future looks like the past (which is equivalent to being stationary), or there isn't. That core could be "the laws of physics and base conditions are stationary", and everything else is deterministic functions applied on top, but the fundamental process is trying to find that stationary core.

In the finance space, the stationary core is often some 'stylized fact' that you're hypothesizing will hold true. This could be e.g., the momentum factor, that if you strip away the noise, there's an underlying trend that will hold over an extended duration.


That's a bit of a vacuous statement. Stationarity makes sample statistics meaningful due to the LLN, sure, but almost nothing is stationary (and even if something is, there is no way to know anyway, you can only assume). If you condition on enough variables and do enough transformations you may get something seemingly stationary and therefore trivially predictable. But all the practical complexity is in that structure you need to specify. The true prediction "problem", when people work on such "problems", really is in the stuff besides the thing that you can just use averages to predict.


32-bit float has become popular in filmmaking/field recording equipment lately because, with a microphone preamp that supports it, you can capture the entire dynamic range of the microphone--there's no accidental clipping if you drive the gain stage too hard.

It's a bit redundant for a skilled technician, they're already used to setting the gain staging, inbound compression, and feathering the mics to avoid this in 24-bit, but if you're handing a boom mic to a novice and have a scene where e.g. someone's whispering and another person's screaming, it can be nice to not have to worry about it.


24/192 is also great for digital synthesizers--if you're generating a waveform like a sawtooth that has theoretically instantaneous transitions, they can eat as much frequency as you can give them. Running at 44khz loses noticeable high-end content.

Most modern digital synths have already caught onto this and run internally at much higher sampling rates even if their output gets downsampled, but sometimes you run across a vintage plugin that runs at the host audio rate and working in a higher sampling rate is audible.


Hydrasynth aliases like a mad thing. My flagship synth ended up being Summit, and its oscillators are digital but run at a crazy high sample rate. Did likewise with some Chord Organ modules: that Teensy board it was built on could do chord audio at 300k and over a megahertz if you were just generating one wave as simply as possible. The freedom from aliasing really helped the sound, for all that it's a 12 bit analog output. A squarewave is a 1 bit signal…


> 24/192 is also great for digital synthesizers--if you're generating a waveform like a sawtooth that has theoretically instantaneous transitions, they can eat as much frequency as you can give them.

So if your synthesizers do not use proper band-limited oscillators then 192KHz is _FAR_ too slow. You'd want to be running at hundreds of KHz, perhaps a few MHz.

In reality synth software that doesn't sound like crap uses band limited oscillators and should work okay at 48KHz too. That said, even if the oscillators are band limited it may be the case the varrious modulations aren't band limited properly, as getting those wrong won't sound instantly wrong (in particular because you have to modulate to make it wrong, and the underlying change of the modulation may make it harder to tell its wrong).

Though also in those cases if you're not counting on every step being properly band limited then 192KHz may be an improvement but you're still probably getting some meaningful aliasing. I think given how fast computers have become relative to digital audio there is probably a good case to just make any "modular synth" run at 32-bit 480KHz or even 4.8MHz through every stage that could process the audio.

Maybe 192KHz really is enough to suppress the aliasing artifacts but I think to be convinced of that I'd want to see a system that supported both and validate that the difference between a downsampled 48KHz output from the two modes was below -90dB or something.

Or otherwise you can just declare that the aliasing is part of the sound and then there are no right choices... 24khz sampling, 48k, 192k ... who cares, use what you like best. :)


> I think given how fast computers have become relative to digital audio there is probably a good case to just make any "modular synth" run at 32-bit 480KHz or even 4.8MHz through every stage that could process the audio.

1. It should run at FP64 if you want to preserve filter resonances, etc.

2. At 10x/100x fixed-rate oversampling, even a modern "fast" CPU will have very few cycles per (higher-rate) sample to run the DSP for 1 "module" of the software modular. Forget about interconnected modules, multiple tracks, or polyphony. For this kind of "analog"-style processing, it's better to run adaptive-rate algorithms (think SPICE) instead of wasting compute on unnecessary extra audio samples.


so an 8-core zen4 should be able to sustain more than 300 gflops of 64-bit multiply-adds. At 480khz that's 625k operations per sample. I'll grant the 100x oversampling was probably too ambitious. :P

For adaptive rate I think the issue there is you have a hard-realtime constraint for this usage (even if you wouldn't mind rendering offline, you kinda have to hear it realtime to tweak it-- after all you might tweak it in a way that brings out an artifact you like and then be disappointed by the render). Also in the case of a whole modular system having all sorts of different parts needing to be part of the adaptation loop seems pretty hard to me.

My thinking was just in general that 192k is really not enough to prevent aliasy algorithms from messing up. If you are alias safe you can probably run at 48k and be fine. If you're not, you really want to go much higher.


I'm travelling without my Zen 4 machine, or I could test it. ;) Oh well, Compiler Explorer is enough to look at these microbenchmarks on your own.

These simulations are single core to avoid core-to-core latency. Number of cores isn't relevant unless you want to run independent voices/channels and sum them at the end.

So you start with a very optimistic ~90 GFLOPs of 64-bit FMA on Zen 4. Unfortunately, not all operations are clean multiply-adds. Realistically, you'll need trigonometric functions and LUTs, which are quite slower. Btw, the tradeoff between when to compute vs LUT is very fragile and can change due to a ton of factors (notably integrator algorithm).

Then the data you are operating on won't fit cleanly in AVX-512 registers, requiring spills to L1 cache. Ok, still fast on a modern core.

Of course, the peak theoretical number assumes clean vectorization with double-pumped AVX-512... which also won't happen in practice. Classical DSP will fare better (https://www.youtube.com/watch?v=Ssq0a-YdamM) but SPICE integrators are inherently branchy and divergent. Especially for adaptive integrators, you'll waste a lot of operations trying to "lock in" at the exact time point where the waveform turns a corner. Apple Silicon is better at this messy, branchy code.

So yeah, it's possible-but-hard to hit hard-realtime under these conditions.


You can generate perfect band-limited sawtooth waves at 44.1khz, there are multiple techniques for doing this and most production digital synthesizers use them.

Oversampling gives you headroom for aliases for the rest of the synth that is more vulnerable to it.


Yeah, I was oversimplifying a blit, the raw waveforms are usually okay, but I distinctly remember old-school VSTs where you couldn't achieve a nice saw lead at 44.1.


It's tough to tell without specific names, but I imagine a lot of particularly old* VSTs were written to use naive sawtooths rather than perfect band-limited ones, which would have terrible aliasing at 44.1 khz. Oversampling those would help a lot!

* Some people are still making this mistake, despite information on the (many) ways to do it the right way being widely and freely available!


I wonder if there's also distortion or ring modulation stages where some of the energy above hearing range might spill into audible sidebands if they're not nyquist-limited first.


Yeah, that's the "rest of the synth" part that's more vulnerable to aliasing.

There's some ways to do band-limited distortion but...they aren't nearly as widespread, easy, or universal as band-limited oscillators.

Ring modulation is funny though because you'd ideally want the sidebands to modulate down by default rather than filter them out, that's why you're using it.


No synth generates sawtooths by literally drawing a saw tooth in PCM. The distorsion you get if you do that is not subtle at all.


Could be this (from the article): "Another scenario I can think of is that the financial model for the building requires spaces to be filled by “credit tenants,” meaning name-brand businesses of a certain caliber and creditworthiness."

Might not be available unless your name ends in 'tarbucks'.


Yep. The owner assigns much higher value to leasing to a large national chain. They often hold out for one, refusing to lease to more risky businesses.


Would it make sense to frame this as a Baumol's Cost Disease problem? E.g., the labor of child rearing has been historically offset by the inherent emotional surplus of the task, but the march of productivity in other sectors gradually increases that imputed loss until we reach a breaking point.


I think that's a fair take. We could also frame it as society in the past has carried a lot of the burden of raising kids.

Tribes and communities helped raise kids. That's no longer true in an individualistic and institutionalized society.


I wonder if this is a nuclear proliferation risk--could it be used for AVLIS/SILEX?


Can’t wait til someone makes a Gemini prompt to find these public keys and launch a copy of itself using them.


I wish them the best, but to my knowledge most metal laser sintering setups involve powders so fine as to be both a fairly serious health concern and (depending on the metal) a plausible fuel-air explosive if there's sufficient concentration in the air.

It's not something that instills me with confidence when they self-describe as "scrappy", I'd like to see extra vigilance into the safety concerns.


One of the big use cases for Genlock these days is when you're doing virtual production with LED walls; you want to make sure the screen refresh of the wall is locked to the shutter of the camera. It's almost like 'vsync' in video game video settings, without it you risk seeing tearing in the backdrops.


Another way I like to think about this is finding 'closeable' contexts to work in; that is, abstractions that are compact and logically consistent enough that you can close them out and take them on their external interface without always knowing the inner details. Metaphorically, your system can be a bunch of closed boxes that you can then treat as boxes, rather than a bunch of open boxes whose contents are spilling out and into each other. Think 'shipping containers' instead of longshoremen throwing loose cargo into your boat.

If you can do this regularly, you can keep the _effective_ cognitive size of the system small even as each closed box might be quite complex internally.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: