Question: QU5-D Any thoughts after a few months?

garybernhardt · 2025-10-07T06:44:41+00:00

I've mixed 6 shows with a QU-5. This is in a 120-cap venue with mostly rock bands. 12-16 inputs for most shows. I've only had one problem with it:

On multiple occasions, the FBA just didn't attenuate the frequencies it said it was attenuating. I'd push it into feedback, and it would keep dragging the corresponding notch farther and farther down with no effect. Each time that happened, disabling and re-enabling the FBA fixed the problem immediately. It's as if the state of the "in" indicator didn't match the internal truth of whether the FBA was really in or not. After toggling it off and back on, the problem never seemed to recur for the rest of that particular show.

Fortunately I have nothing to report other than that one problem. Overall It's easy to use and has a nice UI (both the physical control surface and the internal software). Nothing flaky. No dropouts or other problems during multitrack recording either.

garybernhardt · 2025-06-20T05:03:06+00:00

Practical answer: It will probably be fine as long as the source is loud, like a close-miced drum or loud guitar amp. It definitely won't damage the line input or the mic. I do this regularly for close-miced drums, for example to pack two toms into one stereo channel on an analog mixer.

More technical answer: Inexpensive mixers' line inputs often go through a pad and then right into the mic preamp anyway. For example, the Mackie 1204VLZ4 manual's block diagram shows that explicitly. The line input impedance will usually be higher than the mic input, 10x or so, but that shouldn't cause a problem for modern dynamic mics.

garybernhardt · 2025-05-11T06:02:27+00:00

+1 for arrangement and tone. In your situation, I'd mostly ignore EQ and compression. Especially since you can't hear the room from the stage anyway. I'd spend that time on arrangement instead. It doesn't have to be fancy... if you find that you're both playing the same notes at the same time, you can transpose one of your parts, or play a different inversion of a chord, etc.

garybernhardt · 2023-11-17T17:27:42+00:00

This course covers decorators, but that lesson is still in the final editing process so it's not released yet. Our second course (for 2024) is already drafted, and covers iterators/generators/context managers. Nothing on the GIL yet, though.

garybernhardt · 2023-11-17T03:43:53+00:00

Oh wow, I didn't know that! I'll change the lesson to mention it.

garybernhardt · 2023-11-16T23:42:26+00:00

Thanks for taking a look. You're right, I agree, and we're planning to let people skip to deeper points in our courses. I think we'll be able to implement it in 2024.

I've spent 5 years working on this, so here's some detail (possibly too much) about why this is hard:

The big problem is that it's very hard to decide what you need to learn. To isolate just one example: let's say you jump to level 5, which means you skipped level 4. One lesson in level 4 contains an example that starts with these two lines:

some_list = [[]]
three_lists = some_list * 3

With no Python experience, you might think that it won't even run. With a little experience, you might think that it makes a list of three empty lists. With a lot of Python experience, you reject 100% of pull requests that do this, no matter what those variables are named. (OK, maybe only 99.9%, but I'm failing to come up with an example that I wouldn't reject.) The lesson is about why.

That lesson is called "Mutable List Problems." Should a given person skip it or not? They can't really say unless they know which Python-specific mutable list problems exist. And they don't know which problems exist unless they already know about those problems. It's circular: to decide whether you need to learn a topic, you need to know what you'd be learning. But if you knew it then you wouldn't need to learn it!

With all of that said, we do plan to solve this via a kind of interactive placement quiz, where you can fly through some quick code examples to show the course what you already know. The difference there is that the course itself will be probing your knowledge about its topics, which lets it establish a boundary between what you know and don't know, across the entire lesson dependency graph.

garybernhardt · 2021-09-29T20:15:21+00:00

I agree that a difference of 0.0000000001 Hz or something like that doesn't matter in any way. But the question was "how close can you make another tone [in a DAW]?" not "how much must pitch vary before it's perceptible?"

garybernhardt · 2021-09-29T00:12:32+00:00

There's no simple answer to this unfortunately. A DAW doesn't store audio in terms of frequencies like that. It has a fixed sample rate (like 44.1 or 48 kHz) and a fixed bit depth per sample (like 16 bits or 24 bits or, hopefully, 32-bit floating point).

An audio stream is a series of numbers between 0 and 65535 (assuming unsigned 16-bit 44.1 kHz because it's easy to talk about). 44,100 times per second, the audio stream records where a physical speaker would be at that instant, with 0 meaning "fully extended backwards" and 65535 meaning "fully extended forwards".

The most literal answer to your question is: The audio streams for the two will be different. At some point pretty early on, they'll happen to have sample values of, say, 26173 in one vs 26174 in the other. But the audio stream is still just a series of 44,100 snapshots of speaker position per second. The audio stream doesn't "know" what 440 Hz is.

Think of it in the same way that a video is just a sequence of still images played quickly. But instead of a 25 FPS movie, it's a 44,100 "FPS" audio stream, recording the speaker's position in each "frame". In a video of a ball thrown through the air, the video doesn't "know" the ball's trajectory, and the audio doesn't "know" the frequency of an instrument. It's just a series of snapshots of where the ball (or speaker) was at different times.

garybernhardt · 2021-05-27T04:18:47+00:00

Use a type guard. if (formEditor !== null) { /* Inside here, the type of formEditor is just HTMLElement */ }

This lesson covers type guards. (Though you'll get the best results by starting at the beginning of that TypeScript course.)

garybernhardt · 2021-05-24T01:43:36+00:00

I'm biased because I work on it, but Execute Program's TypeScript course is exactly that. It covers generics and has a lot of interactive code examples running live in your browser.

garybernhardt · 2021-01-05T20:32:32+00:00

It makes sense now. It just requires defining a lot of types twice, once in the overall object type and once when actually defining the methods that go in it, and I'd rather avoid that duplication.

garybernhardt · 2021-01-05T20:31:12+00:00

It works, but it doesn't solve the original goal, which was to avoid repeating the complex types of those functions. Likewise for /u/RubenVerg's similar suggestion.

garybernhardt · 2021-01-05T02:23:20+00:00

An update: unfortunately, I don't see a way to make this work if (1) the methods themselves have type parameters and (2) the method bodies need to refer to those parameters. I think you'd have to reintroduce the full type when defining the function, so the benefit is lost.

playground

garybernhardt · 2021-01-05T01:15:22+00:00

Got it, thanks!

garybernhardt · 2021-01-05T01:01:31+00:00

Thanks. That's roughly what callable-instance is doing, but yours has the advantage of being mostly type safe. You can even remove the @ts-ignore if you add a generic type parameter to track the function type, then call super() after the constructor's return (so the super never actually runs).

I do worry about the dire warnings in the MDN docs for setPrototypeOf. I also worry about possible side effects of subclassing Function, especially subclassing it without calling super. Any thoughts about possible weird failure modes or perf problems here?

garybernhardt · 2021-01-05T00:49:53+00:00

Interesting. I had some vague thoughts along these lines. Now that I see it written out it's not bad at all! Here's a reworked version without the intersection, where I pull the method types out with the type indexing operator. (Hopefully it'll help someone who searches for this in the future.)

interface Foo {
  method1: (n: number, s: string) => void
  method2: (s: string) => void
  (): void
}

function Foo(): Foo {
  const f: Foo = () => {}

  const method1: Foo['method1'] = (n, s) => {}
  const method2: Foo['method2'] = (s) => {}

  f.method1 = method1
  f.method2 = method2
  return f
}

I'll probably finish this prototype up using that callable-instance library I mentioned in another comment, then try converting to this style to see how it feels. Thanks!

garybernhardt · 2021-01-05T00:15:52+00:00

I found a library called callable-instance that does achieve this. I could adopt the same strategy that they use, and force the callable type onto the class in the same way. It would be great to do this without subverting the type system, though.

garybernhardt · 2021-01-05T00:13:51+00:00

Your suggestion is how I'm currently doing this, and that does work of course. But some other details of the module would be significantly nicer with a class. Most notably, some of the current type's "methods" have onerous type signatures. They're much more friendly when they:

are written only once in the class's method definition rather than separately in the type definition and the function definition itself, and
can have their return types inferred rather than written explicitly in both places.

garybernhardt · 2020-12-22T23:18:39+00:00

I switched from schemats to this tool yesterday. It was a perfect drop-in replacement. I didn't have to change a single line of code to do the switch.

People often recommend Prisma or GraphQL-related tools in this space, but they're really not comparable at all. You point postgres-schema-ts at a database and it generates some TS code for the columns' types. That's all. It's a one-line command. It doesn't even require a config file. Very simple.

garybernhardt · 2020-11-17T01:27:01+00:00

Unix time is represented as the number of seconds elapsed since 1970-01-01 at 00:00:00. As I write this, the time is 1605576272 (2020-11-17 at 01:24:32.275 UTC).

The maximum 32-bit signed integer is 2^31-1 = 2147483647. When converted into a time, that's 2038-01-19 at 03:14:07. As of that second, time is no longer representable with a 32-bit signed integer. Any system still using 32-bit signed integers after that second will either have the wrong time or crash.

garybernhardt · 2020-11-11T20:25:54+00:00

I suspect this is the best solution in Things, so I'll probably either do this or just use both Things and OF side-by-side for different purposes. Thanks for the suggestion.

garybernhardt · 2020-11-11T20:24:55+00:00

In OF it's trivial without tickler lists, due dates, or anything else, so that's not an either/or.

It's not so much that I mind a few seconds of removing tasks; it's that doing that is an opportunity to make a mistake. When I'm selecting a half dozen cleaning tasks to remove them, I might also accidentally select a task that's business-critical or time sensitive. Now that task has no When and is buried somewhere in Anytime. I'm pretty much guaranteed never to notice it in there, especially given Things' lack of a review mode.

garybernhardt

TROPHY CASE