A day was spent making the code a bit more tidy. Small improvements had been gathered on a list but the code was already usable so the improvements were polish more than they were important. Since everything built for testing will not be used in the first prototype there is no way to know how the final hardware will work.
The first piece added was the most important. It was a rising edge trigger. This was mentioned yesterday but for anyone who doesn't know and didn't read the Wikipedia article a rising edge trigger is simply a cue to the program to do something as soon as the switch goes from off to on then ignore it until that happens again. Python makes this easier than Arduino in my opinion and it is a strong programming tool.
For the next piece a software debouncer was added. This was discussed before and it is nice to have but probably unnecessary. On the other hand Python made this easier than Arduino and it paired well with the code for recognizing a rising edge so it was added within a minute and calibrated with a few tries. It will need to be recalibrated when the actual prototype gets built.
These bits of code made the program interface better with the rudimentary setup and inexpensive test switches. It also helped to learnd about the GPIO programming with Raspberry Pi and Python.
To signal that the device had started the introduction would play the three lowest notes in succession. It seemed like a suitable way to tell the user that the piano was up and running. With the thumbwheel switch added it was now possible to know which octave the user had selected so it was possible to play all the notes in that octave. Which was added to the code. Then, since multiple octaves would be powered on simultaneously, a delay was added which waited for any previous octaves to play their notes. Ideally, when the piano gets powered on all the notes will play as though someone was playing the keys in order.
Pygame did a wonderful job of implementing sound with this project. In all the reading it was also shown that the number of sound channels could be declared explicitly. This number had to do with the number of sounds which could be playing at the same time. It wouldn't sound very realistic if only one note per octave could play at a time. The number of channels was set to 12 by some code copied from the internet. Mashing all the piano keys made it clear that the system wouldn't keep up so the channels were increased from 12 to 25. Key mashing sounded cacophonous so it worked beautifully.
When ordering parts for this project two different sound card styles were ordered in case one wouldn't work with a Raspberry Pi. The second arrived in the mail and both worked. It was even swapped without restarting the computer without problems. It was necessary to access the sound settings and select the new card.
This blog, including pictures and text, is copyright to Brian McEvoy.
The first piece added was the most important. It was a rising edge trigger. This was mentioned yesterday but for anyone who doesn't know and didn't read the Wikipedia article a rising edge trigger is simply a cue to the program to do something as soon as the switch goes from off to on then ignore it until that happens again. Python makes this easier than Arduino in my opinion and it is a strong programming tool.
For the next piece a software debouncer was added. This was discussed before and it is nice to have but probably unnecessary. On the other hand Python made this easier than Arduino and it paired well with the code for recognizing a rising edge so it was added within a minute and calibrated with a few tries. It will need to be recalibrated when the actual prototype gets built.
These bits of code made the program interface better with the rudimentary setup and inexpensive test switches. It also helped to learnd about the GPIO programming with Raspberry Pi and Python.
To signal that the device had started the introduction would play the three lowest notes in succession. It seemed like a suitable way to tell the user that the piano was up and running. With the thumbwheel switch added it was now possible to know which octave the user had selected so it was possible to play all the notes in that octave. Which was added to the code. Then, since multiple octaves would be powered on simultaneously, a delay was added which waited for any previous octaves to play their notes. Ideally, when the piano gets powered on all the notes will play as though someone was playing the keys in order.
Pygame did a wonderful job of implementing sound with this project. In all the reading it was also shown that the number of sound channels could be declared explicitly. This number had to do with the number of sounds which could be playing at the same time. It wouldn't sound very realistic if only one note per octave could play at a time. The number of channels was set to 12 by some code copied from the internet. Mashing all the piano keys made it clear that the system wouldn't keep up so the channels were increased from 12 to 25. Key mashing sounded cacophonous so it worked beautifully.
When ordering parts for this project two different sound card styles were ordered in case one wouldn't work with a Raspberry Pi. The second arrived in the mail and both worked. It was even swapped without restarting the computer without problems. It was necessary to access the sound settings and select the new card.
Disclaimer for http://24hourengineer.blogspot.com/
This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.
All
information in this blog, or linked by this blog, are not to be taken
as advice or solicitation. Anyone attempting to replicate, in whole or
in part, is responsible for the outcome and procedure. Any loss of
functionality, money, property or similar, is the responsibility of
those involved in the replication.
All digital communication regarding the email address 24hourengineer@gmail.com becomes
the intellectual property of Brian McEvoy. Any information contained
within these messages may be distributed or retained at the discretion
of Brian McEvoy. Any email sent to this address, or any email account
owned by Brian McEvoy, cannot be used to claim property or assets.
Comments
to the blog may be utilized or erased at the discretion of the owner.
No one posting may claim claim property or assets based on their post.
2016-06-08 (W)
Comments
Post a Comment