But we can simplify this.

I'm not putting finished effects into standalone metal #boxes at this point; I'm #experimenting, not producing a product. So I have a simple #modular system I cooked up to connect arbitrary effects #experiments together. One of the things it does is handle the power-supply stuff, so each effect board doesn't need to do any of that. It just receives a nice 0V and buffered #Vcc (9V) it can rely on, along with a buffered 4.5V to use as a #bias voltage when AC coupling #signals, since this is a single-supply system.

So we can chop out all the power stuff from the schematic, which fills basically a ninth of the image - divide it into 3 rows and 3 columns, like the Brady Bunch intro, and the left-middle square is basically the power section.

But there's a bigger chunk we can strip out. Boss (and many other) pedals of the era frequently used "soft switching" to enable / disable the effect while playing. If you go back in time, real physical #switches were used, so the signal was actually totally disconnected from the effects circuitry when in the "off" position. This is called "true #bypass", as opposed to the soft switching.

#Soft #switching involves having two signal paths through the effect. One applies the characteristic effect, and the other basically just buffers the signal and bypasses the rest of the effect stuff. This is implemented with transistors and latches.

2/x

Solved!

This was a pretty "interesting" bug. Remember when I invented a way to implement #async / #await in #C, for jobs running on a threadpool. Back then I said it only works when completion of the task resumes execution on the *same* pool thread.

Trying to improve overall performance, I found the complex logic to identify the thread job to put on a pool thread a real deal-breaker. Just having one single MPMC queue with a single semaphore for all pool threads to wait on is a lot more efficient. But then, a job continued after an awaited task will resume on a "random" thread.

It theoretically works by making sure to restore the CORRECT context (the original one of the pool thread) every time after executing a job, whether partially (up to the next await) or completely.

Only it didn't, at least here on #FreeBSD, and I finally understood the reason for this was that I was using #TLS (thread-local storage) to find the context to restore.

Well, most architectures store a pointer to the current thread metadata in a register. #POSIX user #context #switching saves and restores registers. I found a source claiming that the #Linux (#glibc) implementation explicitly does NOT include the register holding a thread pointer. Obviously, #FreeBSD's implementation DOES include it. POSIX doesn't have to say anything about that.

In short, avoiding TLS accesses when running with a custom context solved the crash.

There’s much to be said about this title page of the French journal La science et la vie. It comes with all the ambivalent connotations of gender, telephony, labor and automation history. We can still see a shadow of „la demoiselle du téléphone“ in the center of the image. Yet, the telephone girl or „Fräulein vom Amt“ has become a non-human switching machine in 1927. https://netzeundnetzwerke.de/la-science-et-la-vie

Color lithograph, May 1927.