better sound control.
better sound control.
I'd like to see easier sound control. Maybe I am not understanding the instructions on how to use it, but something as simple as 'sound(freq in hz,duration in ms)' would be great!
Re: better sound control.
Could you help us improve the existing sound library, what is wrong with it?kaos116 wrote:I'd like to see easier sound control.
maybe documentation?
The issues I have with the present method is it's confusing. If I understand it correctly You have to figure the note you would like played based on the speed of the processor. Then the duration is some form of cycles. I assume this is also based on clock speed, but this doesn't work for me.
When I change the note/tone the duration that it plays changes, even when the duration number hasn't changed. So, if I want to play a scale for 5 notes 500,600,700,800, 900 hz I have to do the math to figure out what they are based on my processor. If I want them to all play for 250ms I have to compute the duration for each note.
So, if I where to rewrite the sound routine I would make it as simple as:
Sound_Init(portb,0) 'allowing for any port and pin as long as an output
Sound_Out(500,250) 'first variable is tone in hz. Second is duration in ms. regardless of processor speed.
even allowing for variable use
tone = 500
duration = 250
for i = 1 to 5
Sound_Out(tone,duration)
tone = tone + 100
duration = duration + 50
next i
Now this may all be a mute point if I am not understanding the way the routine is written now, but I do know that if I change the note without changing the duration to compensate for the new note, they play for different lengths.
I hope this makes sense
When I change the note/tone the duration that it plays changes, even when the duration number hasn't changed. So, if I want to play a scale for 5 notes 500,600,700,800, 900 hz I have to do the math to figure out what they are based on my processor. If I want them to all play for 250ms I have to compute the duration for each note.
So, if I where to rewrite the sound routine I would make it as simple as:
Sound_Init(portb,0) 'allowing for any port and pin as long as an output
Sound_Out(500,250) 'first variable is tone in hz. Second is duration in ms. regardless of processor speed.
even allowing for variable use
tone = 500
duration = 250
for i = 1 to 5
Sound_Out(tone,duration)
tone = tone + 100
duration = duration + 50
next i
Now this may all be a mute point if I am not understanding the way the routine is written now, but I do know that if I change the note without changing the duration to compensate for the new note, they play for different lengths.
I hope this makes sense
I I understand correctly, you want the PIC to do the math of figuring out the number of cycles needed for a given pitch and length. This is directly related to several threads regarding the delay_ms procedure, and why it won't accept variable arguments. After considerable discussion and brainstorming, that problem was solved, and the solution could probably be applied to this function, as well.
In the mean time, it might be simplest to create a spreadsheet to input the clock speed and desired pitches and lengths, and calculate the procedure arguments needed. This would give the flexibility to create some pretty elaborate tunes without any difficult hand calculation, if that is what you are trying to do.
It is also possible to use the CCP module on some chips, but you'll have to create you own code.
In the mean time, it might be simplest to create a spreadsheet to input the clock speed and desired pitches and lengths, and calculate the procedure arguments needed. This would give the flexibility to create some pretty elaborate tunes without any difficult hand calculation, if that is what you are trying to do.
It is also possible to use the CCP module on some chips, but you'll have to create you own code.
My use for the sound library was for making a morse code keyer. I wanted to make the pitch user adjustable and also the speed at which it sends the characters. When the pitch was changed the math involved in keeping the speed the same and keeping the 1-3 ratio correct for the morse code dits and dahs was impossible for me to figure out. Then if they wanted to change the speed it was another problem.
The spread sheet idea sounds like a good idea for an interum fix. Giving the user just a few pitches and speeds to pick from instead of unlimited. This way I can just have a table of variables stored somewhere to choose from...
But, being the WISH LIST forum.... I can wish, can't I?
Kaos116
The spread sheet idea sounds like a good idea for an interum fix. Giving the user just a few pitches and speeds to pick from instead of unlimited. This way I can just have a table of variables stored somewhere to choose from...
But, being the WISH LIST forum.... I can wish, can't I?
Kaos116
