I'm just glancing at it right now. Note, all of these are suggestions. If it is not worth the return on investment, feel free to drop stuff.
I'm beginning to wonder it if would be better to have each of the major categories (input, output, mixer, play, record, synth, effect, filter, analyze, control) to be pull down menus. It is getting unwieldy to scroll down through all of the different entries. Of course it will make it slightly more complicated. It would be helpful if the entries list what Teensy is supported when you hover over the entry.
For many people, it would probably be useful to have an entry for the audio shield that adds all of the necessary interconnects. Perhaps a Prop Shield also.
As we have discussed before, we really need a FILE layer to go between the audio readers (RAW, WAV, etc.) and output. Otherwise, we will need a N*M matrix to support all of the different readers (RAW, WAV) and file system combinations (SD revision 1, SD-beta, SPIFFS, etc.). In addition, we should think about having multiple instances of say SD readers (i.e. on the Teensy 3.5/3.6/4.1, you could possibly want to use both the built-in SD card reader, and the SD card reader on the audio shield).
With the Teensy 4.1/3.6, we should support reading files from removable devices like USB flash memory sticks. This may be a longer term thing. Even longer term might be incorporating networking.
Also longer term, but possibly worth thinking about, particularly with a FILE layer, is having standard output devices to write WAV, RAW, etc.
It would be nice if we could include FrankB's MP3 reader in the basic set.
It would probably help some people to have a Teensy box that says what Teensy you are building for, and then all of the devices that don't work for that Teensy will be grayed out. For example, I answered a question today about a user trying to use AudioOutputAnalogStereo on a Teensy 3.2. Obviously, you do want a combination Teensy that will allow anything.
Once in awhile, I've wanted a mixer that had more than 4 inputs. Yeah, you can add multiple mixers, but it can be useful to have one object. Particularly now that you have hex and quad inputs and outputs it would be helpful to have mixers with more inputs.
Having an amp that reads from an analog pin (instead of having the user do the appropriate read and call the function) can be useful. For a volume switch, it would be useful if the same analog pin could apply to multiple inputs and pass them on to multiple outputs.
It would be nice if the Export function did not automatically include SD.h and SerialFlash.h unless the user actually configures those devices. In particular, the threads that complain about wanting to use SdFat-Beta, while the tool always puts out SD.h.
I presume SPDIF2/3 are for use with the Teensy 4.0/4.1.
For the standard SPDIF, it mentions using pin 22. It is probably helpful to clarify that this is for the software S/PDIF that works on any digital pin. I don't know if we want to automatically switch to using pin 14 on the Teensy 4.0/4.1 to use the hardware S/PDIF automagically, or suggest that the user use one of the other S/PDIF modules. In any case, it would probably be useful if we could provide an override for the pin used.
It is good to see that all 5 of the I2S1 pins are now being handled by the tool.
Given that the Teensy 4.1 has alternates for OUT1A and IN1 (pins 39, 38) we probably should have some way to override using the standard pins 7/8. I2S and others should mention this.
In the I2S description, we say:
Normally, this object is used with the Audio Shield, which is controlled separately by the "sgtl5000" object.
I would suggest changing this to something like:
Typically, this object is used with the Audio Shield, which is controlled separately by the "sgtl5000" object. It can also be used with other I2S implementations as well. Some other I2S implementations might provide CODECs that you can control, others might just use the basic I2S stream.