Problems w/ Tone.h and MusicWithoutDelay.h Compiling

Status
Not open for further replies.
@nathanSuperStar- I connected a Teensy Touch pin that uses Teensy's [LC, 3.2, 3.6] single wire touchRead() as a button. I just started using that because it works well and easier than making a real button to push. I saw you had a SensorToButton.h class - Being a 'c' guy too lazy to make my own class layout - I rewrote that to accommodate the capacitive nature and use of that touchRead() function and it works to encapsulate what I was having to do manually in the earlier test code - it does work with that library wasPressed and wasReleased so I left them and it works in the song_with_MOD sketch.

Can you tell me if I should leave it pointing you with MIT license as it stands? :: View attachment TouchButton_src.zip

I just looked at IDE's verbose - there are many screens of ' warning: narrowing conversion':
// …
"T:\\arduino_1.8.6_TYC\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -Os --specs=nano.specs -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -fno-exceptions -felide-constructors -std=gnu++14 -Wno-error=narrowing -fno-rtti -mthumb -mcpu=cortex-m0plus -fsingle-precision-constant -D__MKL26Z64__ -DTEENSYDUINO=143 -DARDUINO=10806 -DF_CPU=48000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IT:\\TEMP\\arduino_build_489881/pch" "-IT:\\arduino_1.8.6_TYC\\hardware\\teensy\\avr\\cores\\teensy3" "-It:\\tcode\\libraries\\TouchButton\\src" "-It:\\tcode\\libraries\\MusicWithoutDelay\\src" "T:\\TEMP\\arduino_build_489881\\sketch\\TchSong_with_MOD.ino.cpp" -o "T:\\TEMP\\arduino_build_489881\\sketch\\TchSong_with_MOD.ino.cpp.o"
In file included from t:\tcode\libraries\MusicWithoutDelay\src/synth.h:13:0,

from t:\tcode\libraries\MusicWithoutDelay\src/MusicWithoutDelay.h:32,

from T:\tCode\TouchRead\TchSong_with_MOD\TchSong_with_MOD.ino:29:

t:\tcode\libraries\MusicWithoutDelay\src/tables.h:289:1: warning: narrowing conversion of '-3' from 'int' to 'char' inside { } [-Wnarrowing]

};

^

t:\tcode\libraries\MusicWithoutDelay\src/tables.h:289:1: warning: narrowing conversion of '-6' from 'int' to 'char' inside { } [-Wnarrowing]

t:\tcode\libraries\MusicWithoutDelay\src/tables.h:289:1: warning: narrowing conversion of '-9' from 'int' to 'char' inside { } [-Wnarrowing]
//...
 
Does that matter critically or helpfully? Or does that PWM output provide the kind of signal the AMP is expecting?

TL;DR = should be ok.

But it's not quite the expected signal. The amplitude is pretty high, so you'll probably get a very loud sound from the speaker. The prop shield does have a low-pass filter, but it was designed with the 44.1 kHz sample rate of the audio library. This code uses 20 kHz, so you would probably want the filter to be a little lower.

These minor differences are probably ok, assuming you're ok with the output so loud. Quite a lot of the 20 kHz will get to the speaker, which is probably ok for almost any ordinary speaker. Most speakers can't respond that high, and humans can't hear that high even if the speaker is able to reproduce it.

If you send the output to a stereo system, the strong presence of 20 kHz PWM carrier might be an issue.
 
TL;DR = should be ok.

But it's not quite the expected signal.

Thanks Paul. Volume is okay, not so loud - and with .setVolume() I have been turning it down as it is just repetitious as I play with touchRead() button - which annoys my wife … like with Talkie queue. I'll look to add the filtering.

"TL;DR" : not seen that in a while … funny … twice in the last week and on short questions too …
 
Something else to keep in mind is the PWM waveform and especially the pulsing class-D output of the prop shield amplifier can play havoc with capacitive sensing if the wires get too close.
 
Something else to keep in mind is the PWM waveform and especially the pulsing class-D output of the prop shield amplifier can play havoc with capacitive sensing if the wires get too close.

I was wondering if noise might bite me at some point - so far I have two buttons … a pair of resistors poking up from a female header. will keep that in mind as I expand.
 
Being a 'c' guy too lazy to make my own class layout - I rewrote that to accommodate the capacitive nature.
Can you tell me if I should leave it pointing you with MIT license as it stands? :: View attachment 14645
I just looked at IDE's verbose - there are many screens of ' warning: narrowing conversion':

1. Why rewrite the whole class when you can use SensorToButton's Capacitive example? You just need a big resistor, like a 1 Mega ohms between two pins. Doesn't Teensy's touchRead do the same thing? My SensorToButton library will work as long as there is a continous stream of data to read in the loop().

2. It would be nice if you point the library, with the MIT license, to me :)

3. Yeah, I got those warnings too :\ These warnings keep catching up to me somehow. When I compile with Arduino Uno, I get no warnings, but when I use the Teensy, I get narrow warning. But I fixed it now. I'll release it soon.

Does that matter critically or helpfully? Or does that PWM output provide the kind of signal the AMP is expecting?

It really depends...you may get less volume. I personally don't even have the resistor connected in my circuit because I wanted more volume. Also my library sounds pretty nice on Paul's Teensy :)
 
1.> As noted the alternate lib { I was planning to do already if just for practice }: " uses Teensy's [LC, 3.2, 3.6] single wire touchRead() as a button " - I just discovered it and would point to doc's but I don't find any but the PJRC touch.c code.

With your post - the second 'read(uint16_t reading)' makes sense now to send in an analogRead() or touchRead() value in combination with threshold. I saw the digitalRead() in 'read( void )' and was put off. That explains debounceIt() too.

The Teensy MCU's hardware ties a 'CAP' to a pin internally - and a simple wire/resistor, or just touching the pin's PCB metal with no external second wire to a surface. It has a library for that style sensing - though not debounced I suppose like the separate button library - I never looked.

I'm extending and customizing it to internalize/support for calibrating it - last thing I did was to internalize counting 'repeat rate' along the lines of that done in your sample 'song_with_mod' as I was capturing repeats in my first sample - which is why I was thinking of making a library. The Teensys that have those Touch pins have 11 or 12 of them - for ~20 bytes each I could make one class to support them all as an array - there is interrupt support but I haven't gotten as far as figuring that out yet.

2.> this changes my view of the SensorToButton lib 'Used for sensors' that I didn't get from the readme - will see what I end up with on my changes.

3.> I'll look for an update for the verbose cleanup
 
re the comment from @nathanSuperStar
Click File > Preference and use the drop-down list to turn on all warnings. Then you'll see them!

Just compiled BASIC for UNO and no warnings - when T_LC selected there are a stream of them, so it is the tool chain catching something that passes UNO types in some fashion.
 
I made a small change under Paul's #ifdef code { Pull Request } that allows code to provide any Teensy PWM pin. Paul's conversion works on the T_LC I hooked up - but is hardcoded to PIN_3 - and still defaults to that pin.

Since there is a .begin( ###, … ) function for the two AVR pins I just took/stored that as a PIN# for the calls to :: analogWriteFrequency and analogWrite.

@Nathan - maybe this was found? In tables.h Verbose Warnings the issue is "char" versus "int8_t"

If these char are made int8_t [like the last in this list] the warnings go away - assuming that is defined for UNO::
line 31 >> const PROGMEM char SinTable[]=

line 291 >> const PROGMEM char TriangleTable[]=

line 551 >> const PROGMEM char SquareTable[]=

line 810 >> const PROGMEM char SawTable[]=

line 1069 >> const PROGMEM char RampTable[]=

line 1328 >> const PROGMEM int8_t NoiseTable[]=
 
Yeah, I figured out the narrowing warnings. Also, changing the pin is a nice feature to add.
Sorry I didn't update the github code yet. I was adding support for other boards to my library. I have created stereo support on the Arduino Uno and Arduino Mega, and teensy. Also, I've added support to the atmega32u4 chips, such as the pro micro and the teensy 2.0; that's for Paul :)

Since you made a feature request, I guess I could change a few things to allow 4 channel Support on the teensy 3.+ and LC.

I'll have it up on github in about 4-5 hours.
 
Nice to see that and other features added. I was wondering how the [4] instances of MusicWD shared info when I found the global :: globalInstrument.
Then wondered why Teensy was stuck on pin3 and saw the opportunity to expand that in that similar way.
 
MWD v3.5.0

I've updated the library now, and I like the acronym "MWD" ;)

Here it is: MWD v3.5.0

I've made the readMe easier, so it should be straightforward on what to do(with the addition of the Table of Contents)

Paul's conversion works on the T_LC I hooked up - but is hardcoded to PIN_3 - and still defaults to that pin.

Since there is a .begin( ###, … ) function for the two AVR pins I just took/stored that as a PIN# for the calls to :: analogWriteFrequency and analogWrite.


There's that Multi-stereo option you wanted @Defragster. You can choose whichever pin you want, and can mix the audio on any pin. Pretty much, the possibilities are endless. Also, I figured out how to crank 30 simultaneous notes at the same time :D

If you want to see the true power of polyphony, you have to use this sketch
and have to modify the maxVoice settings in src/synth.cpp.
Instructions on how to do that are in the read.me

I must say, I'm really impressed by the Teensy :)
 
Which pins connected to Teensy Audio Shield?

Just a question...

Which pins are connected to the Teensy's PT8211 audio kit? And which pins are connected to the Teensy Audio Shield?

I'm asking, because I want to keep my project clean from stray jumper wires :)

And since my Library allows us to change the PWM pin, it seems like it would be possible.
 
I've updated the library now, and I like the acronym "MWD" ;)

Here it is: MWD v3.5.0

I've made the readMe easier, so it should be straightforward on what to do(with the addition of the Table of Contents)


There's that Multi-stereo option you wanted @Defragster. You can choose whichever pin you want, and can mix the audio on any pin. Pretty much, the possibilities are endless. Also, I figured out how to crank 30 simultaneous notes at the same time :D

If you want to see the true power of polyphony, you have to use this sketch
and have to modify the maxVoice settings in src/synth.cpp.
Instructions on how to do that are in the read.me

I must say, I'm really impressed by the Teensy :)

Indeed - Teensy never ceases to amaze!

On T_LC with Prop_LC had a sketch using my touchRead based buttons working with 5 buttons [pins 15-19] - using the new V3.5.0 of MWD I have a voice on all 5 buttons!

When I went to the linked polyphony sketch I get NOISE and trying the SensorToButton btn.read( touchRead ) failed to get button press and importing my working replacement was no better? In fact executing the .read() on either caused a loss of USB "### hz" prints - but the noise persisted. I don't have a POT wired to I removed volume control. But starting at a LOW volume the HUMMMM Noise is the same loudness?

<edit>: Nice add of the extra voices per channel!
Note - the Teensy 3.x and LC can PWM 20 Khz at 11 bits - if I'm reading the table right.
 
1) the reason why the sound is noisy is because the more note-polyphony, the more bits you are trying to squash together. To fix this, you just have to play at a lower volume(using a potentiometer is probably best for finding this volume). Though, you could use the Serial monitor and decrease the volume.

2) SensorToButton works for me. Maybe the extra note-polyphony is interfering the Touch sense feature? A regular button works well :)

3) Thanks, the extra voices per channel was hard to implement because adding mixed samples to the right output pin can take time on the timer routine. In fact, I thought of using a nested for loop; this only made things worse because the teensy started playing at a higher octave.

So I decided to use two arrays at the beginning of initialization, and I determined which buzzers are using the same output. So when the buzzers play at runtime, the teensy can play at a much faster rate because the mixed sample's outputs have been predetermined.

It took a while for me to figure it out, but I'm glad it works without bugs.... For now 😅.
 
Status
Not open for further replies.
Back
Top