chipaudette

You have a non-deterministic failure in your system. The debugging technique that I'm suggesting is to keep removing elements of your program until you've got the most minimal example that still has the issue. At that point, the problem usually...

In your update function... void AudioCustomFilter::update(void) { audio_block_t *block; block = receiveWritable(); if (!block) return; if (enabled) { if (proc) { __disable_irq(); proc(block)...

Yeah, this is a tough one. In my typical minimalist approach, I was simply going to assert that destroying inputs and outputs was not allowed. In effect, I'd kick the can down the road, if you will. For my own uses, I have no need to...

Or, to solve so many of these problems even more simply, we could move the update list (and its other associated data members) out from being `private` and, instead, make them `protected`. This would give derived classes access to the update...

I'm very familiar with the latency issue. Been working with it for years and years. It just isn't relevant in most situations that I deal with. Occasionally, latency is relevant...like in my hearing aid experiments. But, in those cases, I...

Regarding your first two points, they are points that I agree with. However, to get dynamic destruction to work *at all*, I propose that we go with the minimum changes. This is the classic debate over whether it's better to offer a number of...

I had seen your work before, but I had not realized how deeply you had pushed your dynamism. In my mind, I was seeking something a bit more modest. As I'm hoping that Paul might choose to include a basic destructor in the next release, I think...

Over the last bunch of years, there's been great work done to enable dynamic audio connections. Fantastic! But, as freely acknowledged, this work was limited to creating/destroying AudioConnection instances. Destroying Audio objects themselves...

I agree that it doesn't need the whole board, but it does need some processor-oriented elements. As two examples, it needs the data type truncation / overflow behavior of the ARM core as well as have simulations of the ARM CMSIS DSP routines.

Even a simulator for this ARM core would be nice to know about. It would be great to simulate Teensy audio library processing algorithms on my PC before moving to the Teensy itself. So, even if it is not for the whole Teensy 4.1 device, might...

By the way, after I created the OpenAudio library, I created the Tympan library, which uses all the same approaches. Its examples better maintain the changing of sample rate and block size. You can see a good example here...

I haven't been the one maintaining the OpenAudio library...I haven't been the maintainer for years and years, so its examples look quite different than I remember them. I'm having difficulty finding an example that uses AudioSettings to change...

Yes, if you are mixing the Teensy Audio Library classes (with it's Int16 data) with the OpenAudio library (with its Float32 data), you must conform to the limitations of the Teensy Audio Library. This means you can only run at 44.1 kHz and 128...

Hi, The second one doesn't work because, in your setup(), you only allocated AudioMemory_F32. If you are using the non-F32 audio library (which is the regular Teensy Audio Library), you also need to explicitly give it some memory, too. So...