This is highly impractical and it is evident that the author has no idea how IFR navigation and oceanic routes work. When flying on oceanic routes and even on land, you have to intercept certain waypoints and vectored into/around airspaces.
I hate to be discouraging, but maybe the author should make an attempt to understand navigation before cooking up something like this.
I've always been impressed by the controllers in centers and TRACONs. They can have multiple frequencies they're monitoring in each ear, and no matter how polite we try to be we (pilots) have no way of knowing if we're stepping on a call on another frequency. They just have to deal with it. Not to mention communication amongst themselves to some extent as they hand people off, though I haven't been in a tower for a very long time, that may be automated/digital now.
And it's not like pilot/controller conversations are about weekend BBQ plans. It's as information dense as possible without sounding like a METAR report.
The drive through window staffers at restaurants do this, and it’s crazy. They will tell me my order and total, accept payment, and send me to the next window, all while listening to the next person tell them their order.
That tracks. As a teacher I sometimes find myself conversing with multiple kids simultaniously as well. If it's nothing too deep that requires full focus, it works. (Though I do find it tiring and avoid it.)
Perhaps a dumb question but are they center panned (or mono, i.e. talking over each other) or is it split left ear/right ear when they come through the headset?
They are mono, but I was trying to say that with practice, you can process 2 independent audio streams simultaneously irrespective of whether they are mono or stereo. For example, I am able to keep track of 2 people talking at the same time. I obviously can't respond to both but can maintain independent contexts.
I think it was wondered whether you were having the independent streams panned hard to the left and right ears and if that had something to do with hemispheres of the brain and the processing efficiency.
That’s a super interesting question. I don’t think I isolate one stream to each ear since I can process them through headphones as well. Also routinely when I am working as a radio officer, I have conversations with live humans in the room while listening and responding to audio over RF through the headphone.
To be honest, I can’t articulate how I do it. I just somehow manage to do it.
I wonder if reading techniques (i.e. human TTS) are also a bit like this. You have to "read ahead" and maintain a mental buffer, in order to parse the sentences so that you can put emphasis in the correct places, timing etc. So the eyes and mind are ahead of the speech.
Airplane radios are generally broadcasting and receiving mono. There are modern headsets that can also play stereo, but only for onboard music or intercom purposes, if the plane supports it. But in planes with 2 radios you can usually configure their I/O individually. So you can listen (and also talk, although that makes sense less often) on two frequencies at the same time.
Yes of course, the transmitted audio would be mono. I meant one radio in one ear and another radio in the other ear, or if you mix them and they both play in both ears. But it sounds like they're mixed (talking over each other in a single audio stream).
Yes. I have never seen any system (planes or elsewhere) that splits multiple voice communication inputs so you hear different streams in different ears. How would that be different (let alone better) than having both streams in both ears? It's not like your brain can process each ear separately.
There are generally 4 ways you can deal with presenting two independent mono sources to one person using headphones:
1. Mix them together into one mono channel and send that to both ears.
2. One in each ear.
3. Make separate mixes for each ear. For each ear's mix make one of the sources louder than the other, picking a different source to make louder for each ear.
4. Like #3, but also add delay in each ear's mix to the source that is weaker in that ear.
#2 is generally better than #1. Personally I'd find it annoying because it is very unnatural, but it makes it a lot easier for the brain to separate the sources, makes it easier to focus on one and ignore the other if you need to do that, and prevents the auditory masking you can get when two sources are in same place in your perceived audio space.
#3 fixes the masking problem with #1 but #2 still because it is still easier to focus when you need to. Also, in each ear the weaker signal is unnatural and the brain expends some effort to filter it out, which is fatiguing over long periods.
#4 is by far the best. It solves the long term fatigue problem from #3 because our auditory system is built to expect a weaker version of anything one ear hears first to arrive shortly later at the other ear, and automatically filters it out instead of having to do it at a higher level. The delay shifts the perceived source of each voice to somewhere outside the head instead of somewhere inside, which is more natural, which is much less fatiguing than the "one voice" per ear approach (the brain almost always does more work when something seems unnatural).
Many military planes use #4, as do some Airbus models.
> It's not like your brain can process each ear separately.
If you've ever seen a dance music DJ (Tomorrowland is streaming on Youtube right now!) - that's exactly what many of them do.
To DJ a continuous mix as is the norm for this style - generally you'll have headphones on, but only covering one ear. You'll listen to "currently playing" though your right ear, through the venue sound system (well, it's monitors). You'll also be listening to "up next", on the other record/cd/mp3 deck, through the headphones to your other ear. And you'll work the pitch slider, trim controls etc and hopefully produce a good mix!
Not everyone does it like this, some have the headphones permanently on and mix in stereo both tracks at both ears. Or split ears, headphones only - that is an option on the usual Pioneer mixers. But it's surely the most common mental image of a club DJ to have them holding their hand to their headphones on one ear only, I'm sure!
Different voice inputs in different ears wouldn't help since our brain processes auditory input on left/right side of brain based on the type of input, not which ear it came from. Speech is processed on the left side, and non-speech (music etc) on the right side.
But of course your brain can process each ear separately. You have a holistic conscious experience, but that is like a hallucination constructed by your brain for your own benefit.
The raw signals are indeed "in stereo"
Light weight has become a marketing term that targets software developers who have gotten sick of bloat and want their software to run fast and take less resources. It used to mean a trade-off between feature rich and speed. It's been so over-used now that i automatically ignore it unless there's demonstrated reason(s) for it being called light weight.
You’re right that "lightweight" is a loaded term. For this project, I don't mean a small memory footprint—after all, it's Electron.
What I’m aiming for is "lightweight" in terms of perceived performance and simplicity. I wanted to match the near-instant startup and the snappy typing feel of a basic text editor (like Notepad), while still having the Emacs keybindings I love.
By stripping away the heavy IDE-like features and focusing on core editor responsiveness, I'm trying to make it feel "light" for daily, quick tasks.
I just can’t resist myself when airplanes come up in discussion.
I completely understand your analogy and you are right. However just to nitpick, it is actually super important to have a weight on the airplane at the right place. You have to make sure that your aeroplane does not become tail heavy or it is not recoverable from a stall. Also a heavier aeroplane, within its gross weight, is actually safer as the safe manoeuverable speed increases with weight.
If someone adds more code to the wrong places for the sake of adding more code, the software may not be recoverable for future changes or from bugs. You also often need to add code in the right places for robustness.
Just to nitpick your nitpick, that’s only true up to a point, and the range of safe weights isn’t all that big really - max payload on most planes is a fraction of the empty weight. And planes can be overweight, reducing weight is a good thing and perhaps needed far more often than adding weight is needed. The point of the analogy was that over a certain weight, the plane doesn’t fly at all. If progress on a plane is safety, stability, or speed, we can measure those things directly. If weight distribution is important to those, that’s great we can measure weight and distribution in service of stability, but weight isn’t the primary thing we use.
Like with airplane weight, you absolutely need some code to get something done, and sometimes more is better. But is more better as a rule? Absolutely not.
right, thats why its a great analogy - because you also need to have at least some code in a successful piece of software. But simply measuring by the amount of code leads to weird and perverse incentives - code added without thought is not good, and too much code can itself be a problem. Of course, the literal balancing aspect isn't as important.
This is a pretty narrow take on aviation safety. A heavier airplane has a higher stall speed, more energy for the brakes to dissipate, longer takeoff/landing distances, a worse climb rate… I’ll happily sacrifice maneuvering speed for better takeoff/landing/climb performance.
Again, just nitpicking, but if you have the right approach speed, and not doing a super short field landing, you need very little wheel brake if any. ;)
Sure, as long as you stick to flying light aircraft on runways designed for commercial air transport. I would also recommend thinking about how you would control speed on a long downhill taxi with a tailwind, even if you didn’t need brakes on landing.
> the safe manoeuverable speed increases with weight
The reason this is true is because at a higher weight, you'll stall at max deflection before you can put enough stress on the airframe to be a problem. That is to say, at a given speed a heavier airplane will fall out of the air [hyperbole, it will merely stall - significantly reduced lift] before it can rip the wings/elevator off [hyperbole - damage the airframe]. That makes it questionable whether heavier is safer - just changes the failure mode.
> That is to say, at a given speed a heavier airplane will fall out of the air [hyperbole, it will merely stall - significantly reduced lift] before it can rip the wings/elevator off [hyperbole - damage the airframe]
Turbulence, especially generated by thunderstorms, or close to it.
Yes, get a trunk from someone like BulkVS, SignalWire and run your own freeswitch or asterix. You can set up arbitrary “allowed” lists. Hell you can even get fancy with lookups and decide on the fly to allow a call or not.
There are other comments about providers, but my way is way cheaper and you can run you EPBAX on a pi or even get a pre made VM from Azure, Amazon, etc.
Whoa, love this. Do you have any recommended resources if I wanted to try this out? Any comments about FreeSWITCH vs Asterisk, or BulkVS vs Signalwire for a simple setup like this?
Freeswitch is more complicated and has a steeper learning curve, but you can pair it with FusionPBX and it will make things a lot more palatable. Asterix is the grand daddy of this stuff. The community is stronger for Asterix. Freeswitch is pretty much infinitely customizable.
SignalWire is the primary sponsor of Freeswitch but is mainly geared towards HUGE installations. BulkVS is cheaper and better in my opinion. You can also look at AnveoDirect, which is more raw than BulkVS, but you can become really really fancy with it. Like, call center fancy.
> Bulk of the instrument flight training is "mindgames" anyways - you see nothing other than instruments, your "seat in the pants" is likely to cheat you..
Eh, I guess I can flex a little. Living in the Pacific North West, I do not have to play mind games. I can almost get IMC delivered on demand. :P
I hate to be discouraging, but maybe the author should make an attempt to understand navigation before cooking up something like this.
reply