2019-05-31 (F) Weekly Summary

Some code written for this project seemed like a good idea at the time, and it was but some it needed tweaking, fixing, or deleting. A list was growing, but one of the issues I had was operating my blue sound module while notes were playing. Commands to change instrument/program were arriving with every note, so it was difficult to change the volume as it would continuously jump back to the program screen. That was fixed by only changing when the switch was touched.

Not every module will be expected to play every single time the controller generates a new note. This was the purpose of the "play period" function. Every nth note plays from every tenth note to every time. At system start, each module is set to not play but a press to the "play period" button will launch into playing every single note and decreases by tenths with each subsequent touch.
(0:60) Playing notes, but not all of them

Playing periodically was a valuable addition to the project, but another idea was on my list of potential upgrades. The idea was to play notes prandomly so instead of playing every tenth note, there would be a 10% chance of playing any given note. In this way, the time between notes would fluctuate, and it turned out to make a more exciting sound.
(0:65) Fluctuating tempo

The bug-fix above with the instrument selection above was the start, and one of the harder fixes. The short list of minor bugs was tackled in a day to clear out the cobwebs and move forward with less baggage.
  • The first bug was erasing some module data when the reset command was issued.
  • The second bug was caused by the controller looking at the incoming MIDI signal for the first ten seconds after startup.
  • The tempo was programmed to range from 1/8 to 8x when responding to a MIDI tempo but this was expanded from 1/10 to 10x.
  • Pitch offset was allowed to go lower than the limit set by the controller. Before, the lower limit was absolute.
  • Timing offset on modules was only programmed on the screen. It works now.
Bug list

Lately, most of the work was on the modules, but a key piece of the project was implementing center-weighting which meant that the controller would show preference to keeping subsequent notes close in tone rather than an equal disposition to jumping a full octave or playing the same note twice. A day was spent graphing and proving that the idea would work.
Calculated distribution of different number generation schemes

Center-weighting could have been done in a few ways. The way I picked was analogous to rolling different dice. If an ideal thirteen-sided die is tossed, there is an equal chance it will show any of the twelve faces or a zero. If two seven-sided dice are used there is a fair chance of rolling 0-6 and adding them together could yield 0-12, but there is a higher likelihood that the total with being closer to six than zero or twelve. With more dice having fewer sides, the odds of getting close to six increase.

The concept was coded and graphed with the serial output to show that the numbers were in line with the expected results. The two columns below show an even distribution on the left and a heavily center-weighted distribution on the right. In the right column, numbers are equivalent to rolling twelve two-sided dice and adding one or zero after each roll. All the rolls in the right column were between three and nine while the left column had a zero and a twelve.
The output of center-weighted numbers

The rest of the summary posts have been arranged by date.

First time here?

Completed projects from year 1
Completed projects from year 2
Completed projects from year 3
Completed projects from year 4
Completed projects from year 5
Completed projects from year 6

Disclaimer for http://24hourengineer.blogspot.com and 24HourEngineer.com

This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.

All information on this blog, or linked by this blog, is 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 property or assets based on their post.

This blog, including pictures and text, is copyright to Brian McEvoy.