Shop OBEX P1 Docs P2 Docs Learn Events
Interrupt Driven Tempo/BPM Generator (Tempo/BPM VP) — Parallax Forums

Interrupt Driven Tempo/BPM Generator (Tempo/BPM VP)

YendorYendor Posts: 288
edited 2008-08-09 01:45 in General Discussion

Since I apparently struck a (ahem) ‘chord’ with Jon! [noparse]:o[/noparse]) ·
·
We need a way to easily keep those toe’s a tappin, and keep Jon entertained at night and on weekends.
·
Enclosed is my Tempo/BMP VP to hopefully accomplish this!
·
Be forewarned, that this is a lengthy write up will be a tad familiar to the Pitch VP thread – think of it as documentation!
·
My goals with this VP:
  1. Allow a true (or ‘truer&#8217[noparse];)[/noparse] representation when entering music notation, instead of worrying about turning a note off, timers, etc. – let an algorithm do it!
  2. Accurate representation of Tempo based on BPM
  3. ‘See’ the beat using an LED, and see the 1st beat of every measure.
  4. Be able to vary tempo ‘on the fly’
  5. Support standard and odd time signatures: 6/8, 8/8, 2/2, 3/8, 7/4, etc.
  6. Be able to make Meter/Time Signature changes ‘on the fly’
  7. Develop a duration concept that will allow polyphonic notes and polyrhythmic durations (more than one rhythm occurring at an instant in time).
·I feel I’ve completed #1-6, and seems to be working great.· I’m implemented a solution for #7 for the note duration, but is still monophonic and ‘monorhythmic’.·· I’ve also implemented ‘rests’ that I was quite happy with, by adding a 128th pitch (0) to the Pitch Table and to the constants, with supplemental code. ·(Makes sense, you don’t play during a rest!). ·I ran into a few interesting issues in doing this (oscillation – see code) and feel that the may be a few too many band aids, so some coding efficiency and a tad bit of redesign may be needed, but again Proof of Concept has been realized!
·
I see there’s been some great adds to the Pitch_VP, however I’ve based this as building block for monophonic sounds and using the Monophonic Pitch VP, as this was my next goal.· These things will all tie in together in due time.
·
This VP is essentially a Timer VP with code similar to the SX/B or ASM clock/timer examples we all have reference to, with a reference table twist.·
·
Another note, after studying the UART code intensively, it's interesting how similar these subroutines concepts actually are!· For example, waiting for a bit to clear, flagged in the interrupt before moving on. This can be seen in the TX_BYTE VP UART examples as well as all subs in this program.· With this in mind the Rx Buffer and Jon William’s TX Buffer concepts should be able to be easily implemented in some form, as long as we have variable space.·
·
Thinking a bit on the buffer concepts, it’s looking like the overall project, will need 4 buffers for MIDI:
  • RxMidi Buffer (8-16 bytes)
  • TxMidi Buffer (8-16 bytes
  • Duration Buffer (8 bytes for 8 note polyphony)
  • Note On Buffer (8 bytes for 8 note polyphony)
·
If the Piezo buzzer development should continue (which has been a great troubleshooting and development tool), two more buffers may be needed:
  • Duration Buffer (8 bytes for 8 note polyphony)
  • Note On Buffer (8 bytes for 8 note polyphony)
·
However, this means that 8 output pins would be needed, and code space in our interrupt to incorporate 8 single VP’s or one new polyphonic VP - but think of the cheese factor!
·
I hope I won’t have to go to an SX48, but at least we have that option!
·
Getting back to the Tempo/BPM VP, I’ve commented the dickens out of this code to give musicians and non musicians a decent understanding of what’s going on.· Plus, it should entertain Jon, as well!
·
Like the Pitch VP, the Tempo/BPM VP needs a data table.· As typical tempos are from 20 BPM to 255 BPM (which is what was implemented), this means 236 Words or 472 Bytes of data is needed to fulfill the entire range.· Of course, you can scale back as necessary, to suit your needs.
·
Also, like the Pitch VP, Tempo/BPM accuracy will be based on the interrupt time and the clock cycles, as well as a new one: PPQN (Pulse Per Quarter Note).· I’ve enclosed a spreadsheet that will generate the SX/B·Tempo Map and Note Duration Constant Code based on the desired·SX Clock, Interrupt rate, and PPQN in the two worksheets.· I haven’t experimented with different Clocks and PPQN Resolution, so that will be Jon’s homework assignment for Monday.· Typical PPQN’s are at 96, 192, 240, 384, 480, and 960.
·
Accuracy is also calculated in the spreadsheet, but I’m not sure what’s the ‘norm’ is in the industry, nor am I sure of what design tolerances there are out there (I don’t see any specs in any of my instrument documentation either), but this is close enough for me (+/- 0.1% from 20 to 186 BPM, +/- 0.16% at faster BPM’s).· ·This can even improve if we avoid certain tempos.· Plus, we can add features to sync to other devices in the future, both as master or slave, or just simply increase the interrupt or clock frequency.· However, note that the interrupt rate will impact the number of instructions available in the interrupt.
·
At the bottom I did some stat’s based on MIDI’s tolerance for Baud Rate (+/- 1%).· It would be interesting to here everyone’s thoughts in using that as timing accuracy.· However, there will be some latency for processing messages, output of data, etc.· Overall, I'll continue to look into it.
·
Some definitions, but note that this is my interpretation of the definitions…some people may say ticks, pulses, clocks, etc. and could mean the same thing. (note that·these are bitmaps, but if you want the spreadsheet, let me know).
·
·
·
Hardware:
·
  • Two simple red LED’s (one optional) is connected with a 220 ohm resister.·
    • One for the downbeat
    • One for Beat 1
    • Another cool thing you can do is, with appropriate resister values, put a bi-colored led to be red on Beat 1, and green on any other beat OR get this, put a RGB LED in there and go nuts with colors, with an RGB LED VP!
  • A Piezo Buzzer is also used in this example connected as indicated in the SX/B help file under FREQOUT or SOUND
Software:
  • I’ll demo this using the monophonic Pitch VP previously published.·
  • Note the Code Comments for additional details.
The Code:
  • A data table is required (472 bytes).· Can always scale back the table, as necessary.·
  • Had the issue using the “Load” directive, so I put all the constants in the main file.
The Spreadsheet (TempoBPMTables_v1.xls)
  • Two worksheet included.· Analysis at the bottom of the 1st worksheet.
  • Helps to visualize tempo variances and accuracy with different levels of interrupts, clock speeds and PPQN
  • Generates:
    • Tempo Table, to put in your SX/B Code (TEMPO BPM Table, Column L)
    • Duration Constants, to put in your SX/B code (PPQN Constants, Column D)
  • Spreadsheet Inputs (Green)
········ SX Clock Frequency
········ RTCC Prescaler
········ Either the RATE or CYCLES of your interrupt, depending on your preference
o······ Right now the CYCLES (Cell D4) is copied over from Cell E3, but that’s just for calculation verification.
  • Spreadsheet Calculations (Yellow)
········ Interrupt values is calculated, and then put in either Cell G3 or G4 into Cell H4 (interrupt time).
········ Then if you want, you can put your Bit Period Counter in to calculate the baud rate (MIDI is listed)
  • The rest of the columns give the calculations to get to the counter for the tempo.
  • The ‘Rounded’ Column is the value that you use in your tempo table.
  • In the even that there are fractional pulses based on the chosen PPQN, the column will turn red, and will comment out the SX/B code automatically.· You can implement anything you want.· With 96 PPQN, only a Dotted 128th can’t be used, as it won’t be mathematically accurate for completion of a measure.
With the way I incorporated it, Delay_MS is no longer needed.· You can change tempo ‘on the fly’ for any piece of music you have defined.· Also, now there’s no waiting around unless a note is in the process of playing…· The main program loops to do other stuff until duration hit’s Zero, but you have to sacrifice more code in the interrupt.
·
I’m still noodling around some concepts on this.
  1. I basically want to write music as it happens, and don’t want to think of turning off the pitch after it's done.· Let the algorithm figure that out.· Midi will be a bit more challenging.
  2. The Decrementing duration part of the interrupt may not be the best solution.· Some other concepts is a ‘duration array’ of maybe 8 bytes for the notes.
·Some other cool ideas to add:
········ Bi or multi colored LED – Red on One, Green (or others) on other beats.
········ Tap Tempo (e.g. tap a button to measure the pulses in between taps, and come up with a suitable tempo)
········ Use a Ping Sensor to adjust tempo based on hand gesture (Ping VP)
········ Generate/Receive MTC – MIDI Time Code or Midi Timing Clocks, for sync to other sequencers or drum machines – occurs every 24 pulses
········ Improve the Duration Engine (implement buffers)
········ I’ve also put some interesting comments in the code of interesting things to try, like a ‘style’ engine (swing/shuffle), varying tempo to accelerate/decelerate clocks during playback.
·
I’d be interested in hearing other ideas, bugs catches, or seeing improvements·the code or algorithms, or just let me know what you think!
·
Now we can truly say the SX Rocks! (or at least, CAN Rock!) – even with a Piezo Speaker!··
·
At least, I hope I’ve given Jon something to do this weekend!
·
Keep those toes-a-tappin!

Enjoy!
·
Rodney

Post Edited (Yendor) : 8/9/2008 2:33:01 PM GMT
zip
zip
TempoBPM_PPQN_Tables_v1.zip
50K
SXB
SXB
TempoBPM_VP_v4.SXB
34K

Comments

  • JonnyMacJonnyMac Posts: 9,215
    edited 2008-08-08 22:20
    I wonder if there's a clean way to get the timing parameter into a byte? Could we, say, define the shortest note that will be played and give it a value of one unit -- this will correspond to N ISR cycles for that note. Other notes are multiples of this base. If the timing could be defined by a byte then a 16 byte bank could be used as an eight-note buffer (note + timing) pretty easily.
  • YendorYendor Posts: 288
    edited 2008-08-09 01:45
    Sure Jon,

    The flexibility is there, however it's all about making sacrifices, and how much flexibility you want in the program.

    For example, what tempo ranges, note values, clock accuracy do you really need?

    It sounds like the key for you is to·increase·the PPQN value from 96.

    Going to 480 PPQN you can have tempos from 60 BPM to 255 BPM in a byte value.· If you really need to go slower, you can call a quarter note, a half note, in the constants, and so on.· This also impacts clock accuracy - note that the faster frequencies, most of the clocks are the same, but I doubt if someone would really notice, especially if you only are looking at a handfull of Tempos for the songs you code.·

    If you scale back to only three tempos on your song choice, you can also choose the optimum PPQN, but I think that's what you're saying.

    You can experiment with the spreadsheet to see where it fits.

    Let me know if you have other questions cyphering this.

    Rodney


    Post Edited (Yendor) : 8/9/2008 1:21:14 PM GMT
Sign In or Register to comment.