Here's one way that seems to work, you set a time to change a function-scoped variable and return out of the function when that changes.

function thisShouldTimeOut() {

  var shouldIStopDoingThis = false

  setTimeout(() => {
    shouldIStopDoingThis = true
  }, 2000)

  for () { // some loopy stuff
    if (shouldIStopDoingThis) {
      return
    }
  }
}

Edit 2019-04-07: This does not work!

In order to get a less jumpy page, I'm looking at how to render just a sub part of a Riot.js tag. According to this conversation it should be possible. The example given is this:

var item = this.tags['big-data-tag'].tags.item[0]
item.first_name = 'jack'
item.update()

I think it could be adapted to work like this, untested by me:

<maintag>
    <subpart>
        { onlyupdatethis}
    <subpart>
Some other stuff that is static

   <script>
   const tag = this

     this.on('mount', function () {
       stateManager.subscribeToUpdates(function(state){
          tag.tags.subpart.update()
        })
       }   
      )

   </script>

</maintag>

These are just some notes jotted down for my memory, so not authoritative at all, not even inside my own head yet :)

Remove noise → Compress → Normalize

After having watched one of Curtis Judd's videos it was clear it is a good idea to compress/limit before normalizing. There may be some peaks otherwise in your recording that would make the normalizing not be good enough. Also I noted that Judd eyeballs on the left hand dB scale where to put the compressor's knee. That makes sense too.

And completely on my own I realized that noise reduction should go first in the chain. Chances are your noise is at a certain level and it's easier to remove it before compression has introduced a varying noise floor.

Automix

Finally in this post, I have seen that some newer digital recorders and mixers have "automix", that is they mute the microphones of those not talking. This I think would be a great feature to have in post-production! Imagine having six tracks and you just tell the software to automix it. I guess that exists somewhere. Otherwise it would be fun to write an algorithm for it, for post production. You could do voice detection (is this voice?) and amplitude detection, reverberation detection, phase and distance detection (like in a microphone array) and so on.

Update 2019-04-24

Julian Krause has just released a video with his workflow, it's a bit different: https://www.youtube.com/watch?v=GVovXsbCjjU

He normalizes the audio first to a certain LUFS level, then removes rumble and proximity effect with high pass filters, then applies a compressor and a noise gate. What is most interesting for me here is that he sets the attack of the compressor to 1ms and the decay to I think it was 100ms, settings that are on the shorter side but that he argues make sense for voice. Gotta try that.

I just looked through a list of thumbnails on YouTube and I think I know now what kind of thumbnails I prefer at least:

There should preferably be two people on the thumbnail, facing each other

If there is only one person, there must be text, and the text must not be continuous

 

Start a new document in VS code, and before saving, type:

Worklist
Describe how the certificate registration works

Hit return, and the line now says (my bold):

Worklist
Describe how the certificate registration WorkList

At least on my machine. That is insane! VS Code has no idea of what I am trying to code or write or even in what language yet.

You can get rid of this behavior in settings by disabling:

"Editor: Accept suggestions on Enter"

And I won't buy them because I want the USB and power connectors to be internal to the box, since I will plug in a sound card there and a power bank, and I want those to be integral to the box.

However if that weren't the, uhm case, then these would be on my shopping list:

• One with a built-in screen: Aluminium Case KIT for Raspberry Pi 3 with 2.2" Screen / programmable buttons - Audiophonics
• Aluminium Ultra Thin Case KIT for Raspberry Pi 3 / Pi 2 - Audiophonics
• Aluminium Case and Accessories for X400 Module and Raspberry Pi - Audiophonics

Going deeper into the world of Raspberry Pi and sound I have discovered some new options. Modep (Meet MODEP - MOD DUO Emulator for Raspberry Pi)  is a ready-made operating system image with almost 200 plugins installed. I haven't tested it yet, but I am very curious as to how well they solve the optimization issues. I'm downloading it right now. There are even two de-essers among the plugins! I suupect though that many of the plugins are made for guitar effects and are hence in mono.

Modep is hosted by the Lithuanian Blokas guys who make the Pisound high-quality sound sound card for Pi. Buy Pisound - Sound Card & MIDI Interface for Raspberry Pi. At around €100 I will refrain to buy it at this point in time, since I think it is the processing limits of the Pi itself, that sets the limits for me. Still cool though!

Review: Blokas PiSound, Audio & MIDI Interface For Raspberry Pi : Ask.Audio

Modep seems to be created by the guys behind the super pedals  Mod Duo and Mod Duo X. Their stuff looks close to what I would like to create except they do guitar effects.

Finally, since I have problems with the processing power of the Pi, maybe it's time to look at PureData, maybe the bare bones approach would yield more powerful results, suitable for a headless configuration?

Update 2019-03-10: Couldn't boot with Modep from a USB stick with a Raspberry Pi 3 B+. It complained about things being on different partitions or something. Either the Modep image cannot handle the 3B+ hardware or it cannot handle being on a USB, I guess.

First of all, kudos to the porters and maintainers for making all of these run on the Pi!

However it seems to me that it is the Rakarrack that actually runs well, given the constrained resources of the Pi. And this is not so strange given that I think Rakarrack was made with the ARM-powered Pi in mind!

When running the two others, Jackd seems to give up eventually. It starts outputting lots of clicks, like rain. I think that happens when many samples are dropped so that the result has huge discrepancies between adjacent samples in the output. Then it goes downhill from there and locks up. Basically these two seem to strain the resources of the PI. Maybe their plugins are inherently more computationally complex, or they have not been properly optimized for the ARM architecture.

Thinking about it, I actually only tested the Calf plugins for Jack Rack and Calf Rack. It may be that they are extra difficult on the Pi: Plugin performance on RaspberryPi 3 | rncbc.org

I got here:

https://lucidbeaming.com/blog/setting-up-a-raspberry-pi-3-to-run-zynaddsubfx-in-a-headless-configuration/

In a quick test this morning it seemed to make a difference although some of the adjustments had already been made. Jackd had already prioritized up things. The things I did that were new were the following:

1. Disable the internal audio card by commenting out the "dtparam=audio=on" :

sudo nano -w /boot/config.txt

...

# Enable audio (loads snd_bcm2835)
# dtparam=audio=on

2. DBus security policy (disclaimer: I have no idea what this one does in this context):

sudo nano -w /etc/dbus-1/system.conf

...
<!-- Only systemd, which runs as root, may report activation failures. -->
<policy user="root">
<allow send_destination="org.freedesktop.DBus"
    send_interface="org.freedesktop.systemd1.Activator"/>
</policy>
<policy user="pi">
    <allow own="org.freedesktop.ReserveDevice1.Audio0"/>
</policy>

3. Default configuration to use the USB card:

sudo nano -w /etc/asound.conf

pcm.!default {
 type hw card 0
 }
ctl.!default {
 type hw card 0
 }

4. Force the pi to always be alert, by telling it so on startup:

sudo nano -w /etc/rc.local
...
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo "performance" > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo "performance" > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
...

It seems clear now that I have succeeded in building a headphones protector with a Raspberry Pi 3B+, Jackd and Rakarrack.

However some very practical problems remain, and they would actually remain for whatever solution I would have chosen, namely: How do I know I'm feeding the compressor at the right level? If the input signal is too low, the compressor/limiter may not kick in.

So I need an indicator, a VU meter that it is indeed being fed at a good level. I could go the route of having a VU meter directly monitoring the input before it reaches the Pi, but that would be a lot of tinkering.

Since Rakarrack already has built in meters for input and output, it's probably better to outfit the Pi with a small screen, and then create a viewport with xrandr that ensures that those meters of Rakarrack are displayed. And it should be a touch screen so the sliders adjacent to the VU meters can be used.

The second problem is the output level. I would really like to have an analogue potentiometer to be able to adjust the volume there, outside of the Pi. However making a voltage divider with the headset as a part in it, will introduce weird non-linear responses, since headphones vary in impedance depending on frequency. I better go and check to see how much headphone impedance does vary with frequency…