MiCom Bug Thread

Hi @profezzorn,

Thought it would be cleaner to keep all bugs/adjustments needed in one thread vs making several posts. With the latest update I am having an issue with the Question (Directory function). If I hit a question I can get responses to play after, however (this only applies to a trigger 1 response “tnclka1” it will keep repeating, the directory doesn’t clear unless I hit “cancel” trigger 8.


  • I hit trigger 5 “t5clk1” for a question
  • I then hit trigger 1 “t5clka1” for a response to that question
  • If I hit trigger 1 again, I am wanting t1clkn but instead I get the question response “t5clka1” until I hit cancel

I will be emailing you our new Vader template so you can demo/play with the fun set up.


Will have a look at this later today (after work).

1 Like

Actually, wait…

I thought trigger one was supposed to be “repeat question”? I kept in the answer mode intentionally because of that. All the other triggers should exit answer mode.

In the previous versions we has discussed keeping it an answer not a “repeat”. All the versions I’ve tested until yesterdays allowed me to do it. We also talked about If we wanted to repeat the questions we could duplicate the question file and place it in the tnclka1 spot or any other trigger answer location.

I think there’s been some miscommunication here.

My intention was that you can use tnclka1 to repeat the same question, but possibly a different sound file. Something like:

  • are you loyal to the empire? (t5clk1)
  • what?
  • clicks T1: are you deaf? I said: Are you loyal to the empire?!? (t5clka1)

If you don’t have specific repeat messages, then you could just copy t5clk1* to t5clka1*.
I didn’t mean that duplicating the files would trigger any special behavior.

Now, if we want to make any trigger capable of being a repeat, we probably need to use a special sound category for it, like “t5clkr1” or something. But honestly I think it would be confusing. It seems like it would always be better to have the repeat on the same button, wouldn’t it?

1 Like

I follow you now. I think this is a good set up, we can leave the tnclk1 as the repeat until either another response is chosen or canceled (t8) out of the question. Sorry for the confusion!

Hi @profezzorn,

I’m doing some audio testing and have found the volume is lower on the teensy/audio shield compared to the adafruit board we were using in our previous model. I have the volume set to 2500 (still new to Proffie OS) but most cosplayers use speakers that are 4W-30W. Is there a suggested amount I can raise the #define VOLUME using a powered speaker?


Unfortunately, we don’t really know what the right volume is for the audio shield, because it’s not what most people use. 2500 might be reasonable though.

However, the audio shield has it’s own volume control that can be adjusted here:

0.5 was the default in the teensy code, but maybe a higher value would be better?

1 Like

I adjusted the amplifier.h file from .5 to .75 and that certainly made the difference. With the define Volume at 2500 and the amplifier.h file at .75 it’s slightly louder than what we had on the adafruit board.

I’m not too familiar with what is the best practice for the define volume in the config. I guess what I’m asking is where should I pull back on my current settings to keep the users speakers safe from blowing (if that even is an issues)? The amplifier.h file volume or the config define volume?

Thanks again for your help!

Since the MiCom produces an “audio out” signal rather than a “speaker out”, the concerns are slightly different than for a proffieboard. Basically, it’s a question of compatibility and fidelity. I don’t have the answers, but I have some ideas of what to avoid.

The VOLUME define governs the digital signal between the CPU and the audio chip. If it is too high we get clipping. Some clipping can actually create a nice effect in some cases, but for the MiCom I don’t think we want that. If the VOLUME is too low, then we are not using all the 16 bits per sample that the amplifier has available, which means less fidelity.

The 0.5/0.75 value governs the volume of the audio-out signal. If it’s too high, we risk clipping, or possibly overloading the input port on the amplifier, which basically also results in clipping. If it is too low, then we loose fidelity to analog noise.

So basically; the goal for both values should basically be the maximum that doesn’t cause clipping.

There are some standards for what line level are expected. If you have have true-RMS multimeter you can measure the output level and see how it lines up with the standards. Of course, since nothing is ever as easy as it should be, there is more than one standard…


For those following the thread I found the following values to be optimal with the MiCom:

#define Volume 1700 (config)

amplifier.h to 0.7 (in the sound folder)

1 Like

I changed the 0.5 to 0.7.


Been trying to get this installed onto multiple computers with no luck. Same errors every time.

Arduino: 1.8.16 (Windows 10), TD: 1.55, Board: “Teensy 4.0, Serial, 600 MHz, Faster, US English”

In file included from C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\Audio/control_sgtl5000.h:30:0,

             from C:\Users\templ\OneDrive\Documents\ProffieOS\sound\amplifier.h:9,

             from C:\Users\templ\OneDrive\Documents\ProffieOS\ProffieOS.ino:1648:

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4/AudioStream.h:120:7: error: redefinition of ‘class AudioStream’

class AudioStream


In file included from C:\Users\templ\OneDrive\Documents\ProffieOS\sound\sound.h:10:0,

             from C:\Users\templ\OneDrive\Documents\ProffieOS\ProffieOS.ino:366:

C:\Users\templ\OneDrive\Documents\ProffieOS\sound\audiostream.h:6:7: error: previous definition of ‘class AudioStream’

class AudioStream {


Multiple libraries were found for “SD.h”

Used: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SD

Not used: C:\Program Files (x86)\Arduino\libraries\SD

Error compiling for board Teensy 4.0.

Have tried one computer that Arduino/ProffieOS works perfect with Proffieboard programming as well as Arduino Pro Mini, and tried another computer that had no previous Arduino IDE/ProffieOS install. Same errors on both computers when attempting to compile the sketch. Not sure if I have a config that’s not correct or where the issue is.

Looks like I might need to rename AudioStream in ProffieOS to avoid collisions with the teensy audio libraries.

What version of teensyduino are you using?

1 Like

The latest one, 1.55, Arduino IDE 1.8.16. Still on ProffieOS 5.9. Thanks!

Also to add - I can bounce back into the original ProffieOS that I use for programming Proffieboards and it will compile a sketch just fine, so I feel like it’s gotta be a naming issue in the ProffieOS that’s being used for the MiCom.

Ok, I’ve renamed the ProffieOS AudioStream class to ProffieOSAudioStream, which seems to make everything work again.

Alright. Does the ProffieOS MiCom master need re-downloaded again then or do I just need to do a filename change somewhere?

Also, just quick insight. I installed Arduino IDE 1.8.13 along with Teensyduino 1.53 and then used the ProffieOS MiCom master that TheTruth777 sent me and was able to flash the board properly. This time the Teensyduino updater popped up as well. Those are the software versions TheTruth777 currently has installed on his computer that would allow a proper board flash.

Thanks for the help Fredrik!

You would need to download ProffieOS from github, because that’s where I made the change. Unfortunately it’s not as simple as just renaming a file.

Ok cool, no worries! Thanks Fredrik!