That same graph had me jump towards the sampling theorem - playing back an animation with linear interpolation creates hard edges, e.g. frequency spikes. I‘m not sure if the movement space is comparable to audio here, but I can‘t see why not.
so; if the sampling theorem applies; having 2x the maximum movement „frequency“ should be enough to perfectly recreate them, as long as you „filter out“ any higher frequencies when playing back the animation by using something like fft upscaling (re-sampling) instead of linear or bezier interpolation.
(having written this, I realize that‘s probably what everyone is doing.)
I don't know of one, but you seemed to doubt not that it's actively being done, but that it's even possible, which is a very different proposition.
Remember C++ actually implements checks at compile time for the modern std::format function. That is, if you mess up the text of a format string so that it's invalid, C++ gives you a compile time error saying nope, that's not a valid format.
You might think that's just compiler magic, as it is for say printf-style formats in C, but nope, works for custom formats too, it's (extremely hairy) compile time executed C++.
What are the golang- packages about in OpenSUSE? Go doesn‘t support dynamic linking (except for non-go-pieces like glibc or via cgo). Do they contain source-code? Or pre-built .a‘s? Both would have a hard time not conflicting with go‘s own build tooling, right?
I've just installed `golang-github-burntsushi-toml` that should be the well known Go TOML library; asking `rpm -q -l` shows mainly `*.go` files, thus I assume they are mainly used as build dependencies?
Hmm… That makes sense. Though if you are building from source, the only gain you have over regular go tooling is downloading from your favorite mirror rather than github&co. I hope it doesn’t install these source-packages for prebuilt binaries…
I believe they don't allow internet access during the build (so everything needs to be vendored, or things stuck into GOPATH); those packages are probably for the second option.
My impression is that OpenSUSE go packaging is a bit behind though. But I'm not an active packager so this may have been fixed.
If you want to use this as a toy, sure. But please don’t rely on it for messages you want to actually get delivered: These gateways frequently drop messages for random reasons, or block your IP if you send more than a few messages at a time.
Also, in countries other than the US, expect the gateways to be long gone, or completely unreliable.
I work with HVAC software and so many of our customers want important alarms on their mobile devices. They don't want it in email because nobody has notifications on for email so they want a text and they are aware of the carriers SMS gateway. Five years ago this worked ok but with the rising spam wars these similar alerts we send out get caught up in spam filters easily and customers blame us.
It is very simple to use something like pushover and API alarm delivery to them, and so much more reliable. Still it's shocking to see; wait that requires us to pay pushover? Nah, we'll take our chances with email@SMS for our multi million dollar chiller plant in our hospital alarm notifications.
Exactly. That's why you don't want to use these free open relays, ever, for anything that you actually want to get delivered. There are a lot of companies out there that specialize in SMS delivery and have built really smart/complex route selection, retry, failure handling and cost optimization logic to get to a reasonably high delivery %.
/spam: my friend runs https://messente.com that specializes in global SMS delivery and they are, honestly, quite good at it. (Let me know if you ever start using them so I can let him buy me a referral-beer at the pub)
> The price for a replica starts at 0.001 ETH. Each time a particular NFT piece is replicated, its next replication cost will double. So be sure to replicate popular pieces early!
So who gets the replication fees? Is this just a cash grab by the authors of the site?
Looks like SaaS to me. Looks like the funnel is superior and small too. We should just be discussing the revenue multiple, since the same standard should apply. What year does that start?
I'm the creator of the app. I just wanted to create something that was fun/useful with some very mild sense of urgency and scarcity to it. With a starting price of 0.001 ETH per replica, I highly doubt I'll even recoup the >$400 in gas fees I paid to deploy the contract.
My understanding is that minting an NFT always costs money (gas fees that go to the broader mining network to pay the miners for doing the processing). So the cost isn't solely for the benefit of the website maintainers, though I'm sure they're taking a cut too.
Looks _horrible_ on non-retina (read: most external) monitors with macOS.
Browsers have sane defaults for every OS! Please retain them rather than making me install TamperMonkey just to read your blog.
I'm not convinced congestion pricing will actually fix the problem. Once public transit exists and is more useful than your own car, people will use it.
I consistently notice this when visiting larger cities in Germany. Good public transit => I'll take the bus/tram/subway every day. Slow or unreliable => I'll gladly take an Uber or buy my own car.
Maybe surge pricing could be use to finance investments into public transit. Just make it a function of the horsepower-to-people ratio. Anything below 90HP/person is free. If you can afford a nice car with lots of power and don't carpool, pay up.
so; if the sampling theorem applies; having 2x the maximum movement „frequency“ should be enough to perfectly recreate them, as long as you „filter out“ any higher frequencies when playing back the animation by using something like fft upscaling (re-sampling) instead of linear or bezier interpolation.
(having written this, I realize that‘s probably what everyone is doing.)