greatest-ape

I’ve achieved great preliminary results with this in https://github.com/greatest-ape/aquatic#io_uring

If you run your tracker on Linux and an info hash whitelist approach would work for your use case, it might be worthwhile to have a look at aquatic_ws [0]. It relies on tungstenite [1] for websockets and achieves around 20x the throughput of the reference implementation when running with four threads.

I don’t know of anybody who runs it in production, but its sister implementation (BitTorrent over UDP) handles 80k responses per second with lower load averages than opentorrent.

[0] https://github.com/greatest-ape/aquatic

[1]: https://github.com/snapview/tungstenite-rs

(I am the developer of aquatic)

That’s a great idea, I will definitely consider it! I have a couple of sample sounds/tracks at SoundCloud: https://soundcloud.com/octasine

OctaSine is a frequency modulation based VST2 synthesizer plugin that I’ve been developing over the last couple of years. It has now reached a somewhat stable state, so I wanted to share it here. The typical way of using it would be to load it in your DAW of choice (Ableton Live, REAPER et cetera).

Features:

  * Works on macOS, Windows and Linux
  * GUI with Iced
  * Four operators with independent parameters such as volume, panning, modulation index, feedback, three different frequency modifiers (ratio, free and fine) and ADSR volume envelope parameters. The operators can be independently switched to white noise mode
  * Flexible routing allowing setting the output operator (with some limitations) as well as the percentage of signal that is simply added to the final output, enabling additive synthesis. By default, operator 4 is routed to operator 3, operator 3 to operator 2 and operator 2 to operator 1.
  * Modulation panning (!), not present in FM8
  * Master volume and master frequency parameters
  * Four LFOs capable of targeting most operator parameters as well as most parameters of lower index LFOs.
  * 128 voices
  * Fully automatable
  * Preset handling
  * SIMD-accelerated audio synthesis with runtime feature detection

Thoughts on development:

When I came across vst-rs, I realised that I could try out writing an audio plugin. Since I was already familiar with FM synthesis from Elektron Monomachine and FM8, I decided to go with it. It has worked out pretty well.

I though I’d write about some things that happened along the way.

At some point, I decided that I wanted to accelerate the synthesis with SIMD. I started out with using packed_simd, but switched to simdeez to abstract over vector widths and enable runtime detection. However, I wanted more flexibility and the option of splitting SIMD code into multiple functions. My solution was to skip frameworks and instead use custom traits and the duplicate crate to abstract over Rust simd instrinsics for different instruction sets. I use sleef for fast sines.

I eventually decided that I wanted a GUI. The Rust GUI situation is not very mature and special considerations required for vst plugin windows complicate the situation further. I discovered baseview at some point. With the mentoring of wrl and others, I was able to contribute code to get it working on macOS.

I went with iced for the GUI, using the excellent iced_baseview. Iced has been a pretty good experience so far, but the high resource consumption due to how GPU calls are (not) batched is a pain point. If I started over, I might consider other options such as egui.

Preset and parameter handling with VST is tricky since locking must be avoided. It took a while to get there, but I think my current abstraction is workable.

Author here.

I wrote a BitTorrent tracker in Rust a few years ago. A while ago, I found out about the dashmap crate (providing a concurrent hashmap) and thought that I could use it for a new implementation, which could be both performant and simple. I tried using it, but due to blocking, I had a hard time reaching good performance. My realization was that since BitTorrent tracker requests are highly skewed towards popular torrents, even a map which only locks on accesses to the same key would not scale well when used like this.

I experimented and settled on a design with many threads each opening a socket with SO_REUSEPORT and using mio to wait for requests. The requests are read, parsed and sent through a crossbeam channel to request workers, which collect a number of them before locking the mutexes guarding shared state and doing work required to generate responses. These are sent back to the socket workers, which encode them and send them back over the network.

This solution is quite performant and during heavy load testing, I couldn’t even get a lone request worker to reach full CPU utilization. (Adding more would likely not bring much improvement anyway since they would block each other most of the time). Results in terms of responses per second indicate that aquatic scales a lot better with more threads than the established project opentracker, being able to reach more than twice the throughout at best, at the price of using many more threads. (Benchmarks are available in the README file.)

I’d like to thank (in particular) the authors of mio, crossbeam, hashbrown and indexmap for making this fun project possible.

Unsurprisingly, smoking seems to be a huge risk factor [1]: “[..] the multivariate logistic analysis indicated that age (OR, 8.546; 95% CI: 1.62844.864; P = 0.011), history of smoking (OR, 14.285; 95% CI: 1.57725.000; P = 0.018), maximum body temperature at admission (OR, 8.999; 95% CI: 1.03678.147, P = 0.046), respiratory failure (OR, 8.772, 95% CI: 1.94240.000; P =0.016), albumin (OR, 7.353, 95% CI: 1.09850.000; P =0.003) and C-reactive protein (OR, 10.53; 95% CI:

1.22434.701, P = 0.028) were risk factor for disease progression [Table 4].”

[1] https://journals.lww.com/cmj/Abstract/publishahead/Analysis_...

With a few minor exceptions, such as Aquinas, Descartes, Voltaire, Locke, Hume, J.S. Mill, Russel..

The syntax for accessing records (dot notation) is a lot nicer in Rust in my opinion. This makes a huge difference in practice, since I don't have to have ridiculously long accessor functions. Though I haven't learned how to use lenses in Haskell yet, they're supposed to alleviate some of that pain.

I know you left out performance, but it's very nice to have code that can be easily profiled.

IntelliJ IDEA with the vim plugin. This gives me great code completion, auto imports, go to definition etc. And the ergonomics of vim.

It's not bad to be generally interested in many things, and not only in one subject.

On the same note, reading Wittgenstein and realizing there is not a single system of logic underpinning reality, but a hodgepodge of different systems that may or may not have to do with each other.

points / time_elapsed ^ 2 ?

Wow, people are getting very emotional about this. You know, Apple doesn't have an obligation to create the perfect product for your unique snowflake use case. And you don't have an obligation to buy any of their products either. Like, what are you people expecting from Apple?

A few thoughts of mine:

Pros: - Beautiful, thin, lighter design - Great screen (could of course have been even better) - Fast enough processor for most pro tasks - Judging by Apple's history, very good build quality - Up to 10 hours of battery life - A great OS mixing UNIX and support for professional programs

Neutral: - Touch Bar: might be amazing, might just be an irritation. We don't know yet. I for one think it could be nice for music production and DJing, but likely not for programming. A few people actually use the function keys a lot. As before, they will be available while pressing the fn key. But people might want real keys. Since I use vim a lot, it's irritating that the Esc key won't necessarily always be where I expect it to. Sure, it will be available in the terminal, but in IntelliJ with the vim plugin? I might have to remap Esc to Caps Lock. An irritation but not a major deal breaker for most people. - Only thunderbolt ports. I think this is the right move and in line with expected Apple behavior, but I guess some people want to be able to simply connect old/current generation USB peripherals without any adapters - No more MagSafe. - Faster AMD graphics. This is of course nice, except for CUDA people and people who want to install Linux on their MacBooks (but seriously, why would you want to do that?) Also, positive: good support for external screens. But only for certain ones? I'm not sure about this, has anyone figured out exactly what screens can be used? - New keyboard, which some people will like and some won't.

Negative: - Maximum of 16 GB of RAM, wtf? This is the only major deal breaker I see that applies to many people. - Hefty price. But we're talking about Apple here, folks. Pay to play

To conclude, a great but expensive premium notebook with the major flaw of being limited to 16 GB of RAM. If you really need CUDA support, real function keys or have to be able to plug in various peripherals without adapters, this might not be the right computer for you.

Since you probably already know the various establishment newspapers such as The New York Times, WSJ and The Economist, I would suggest watching speeches by and interviews with Noam Chomsky. Is he neutral? No. Nobody is. But he has a completely different perspective. And in line with the other comments in this thread, I think you need to check out different perspectives to get closer to the truth.

Edit: also, check out The Guardian and The Intercept.