| | tlr
Registered: Sep 2003
Posts: 1790 |
Scaled vibrato strategies?
Do anyone of you have any good fast/compact vibrato strategies to share?
I'm aware of the basic difference from the neighbouring note technique but that is usually implemented in a slow way.
I'd like some pointers for more efficient stuff.
(Object code is fully acceptable) |
|
... 10 posts hidden. Click here to view all posts....
|
| | chatGPZ
Registered: Dec 2001
Posts: 11386 |
uhm isnt a square shaped vibrato basically an arpeggio? :) |
| | Dane
Registered: May 2002
Posts: 423 |
The fastest way is definitely to use finetune (add to frq)-tables that loop. The downside is you'll need different tables depending on what note you're on, but if you're not that fussed and want to save rastertime... |
| | tlr
Registered: Sep 2003
Posts: 1790 |
@mixer, groepaz: I guess it depends on the speed of the vibrato. If the vibrato is really fast I think you will notice, although it may be desired like groepaz says.
On synthesizers, at least older analog ones, vibrato is almost always implemented as linear modulation.
@stein: Good point about guitar vibrato. Guitars are very interesting control-wise as the modulation approach is very direct to say the least. It would be interesting to see what kind of frequency modulation curve a normal vibrato run gives. |
| | chatGPZ
Registered: Dec 2001
Posts: 11386 |
<nitpicking>that "e-guitar vibrato" is btw often referred to as "pitch bending", not only because it is more extreme, but also because it is not centered around the base frequency :)</nitpicking> |
| | Hein
Registered: Apr 2004
Posts: 954 |
Quote: Both are interesting.
If I understand hein correctly from my quick look he calculates the add value from the table msb.
$00-$5f = 00<msb>, $60-$bf = <msb>00.
Assuming that gets close to the desired widths it's very clever.
I'm a bit confused about what the optimal tracking for width would be. Is it proportional to the difference to the neighbouring note or is it proportional to the actual frequency?
Also, what do you do if the note changes during the vibrato? An add/sub approach with scaling can get lost in such cases?
I've also gone for a vibrato table approach btw, though mine is a bit more focused on flexibility than speed/size.
The msb is also the lsb indeed (00<msb>) and resulting indices (basenote + depth) $60-$bf give me 16bit frequency add/sub values <msb><lsb>.
The scale will change if the base-note changes, but it's true that for glide (for instance c-3 to c-5), the scale will not change until the base-note (c3) is reset to a new one, for instance with a tie-note or after a glissando command has reached it's target note (c5). The new base-note is the new 0 point from where the add/sub values are fetched from the frequency tables.
I'm not sure what you mean by optimal tracking for width. |
| | tlr
Registered: Sep 2003
Posts: 1790 |
By optimal tracking I was thinking that the difference would have a different slope compared to straight frequencies, but I realize that I've totally forgotten my derivatives. :)
(note/12)
f(note) = f0 * 2
(note/12)
f'(note) = f0 * ln 2 * 2
i.e the difference between any notes a constant distance appart is always proportional to the note halfway between those.
Doing like Hubbard and subtracting just one note away is not 100% accurate though but I guess it doesn't matter. |
| | Hein
Registered: Apr 2004
Posts: 954 |
You can recalculate the slope each frame based on your current frequency and the upcoming frequency, but than it has to be 100% accurate without rounding errors, else your vibrato will detune after a few seconds, I suppose.
In my routine a glide-up can start with an add value of 3 cents each frame, but once it's at the target-note, those 3 cents may have shrunk to a mere 1 cent. :) |
| | Frantic
Registered: Mar 2003
Posts: 1648 |
Just to give some ideas:
If you use flooring when calculating the 16 bit freq values instead of standard rounding you find that the frequency table will actually wrap around nicely, so you can use frequencies in the "lo byte table" for higher values in the hi byte table. (eh.. hard to explain.. tired today). If you look at the commented out lines at the end of the hi byte table you'll see that they are the same as the first lines in the lo byte table, so no need to duplicate them.
So.. first of all, that saves a little bit of RAM since you can use some of the table data both for hi byte values and lo byte values. Then you can also add a bunch of zeroes before the table, to be able to pick sub note values with desired granularity. (e.g. for each octave down in the table you'll have a value that is divided by two, four, eight, etc..) Of course you could also replace the table of zeroes with code that just does a "lda #0" in those cases, to save some table space at the cost of some additional code.
...and you could insert an additional intermediate table to pick a more intelligent set of finetune/vibrato offsets from the freq list. Maybe this way of organizing the tables gives some ideas.. Or not? :) Approaches to vibrato that uses tables run into the problem of extended tables, so I suppose ways of making the tables more compact can be valuable.
(Btw.. the table below was just something I found in an old code file. I don't remember exactly what settings I used for the calculation, so it might be that each octave doesn't even start with a C or such. I post it mainly to illustrate the idea.)
freq_finetunehibytes:
.byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 ; oct0
.byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 ; oct1
.byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 ; oct2
.byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 ; oct3
.byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 ; oct4
.byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 ; oct5
.byte $00,$00,$00,$00,$00,$00,
freq_hibyte: ;floored
.byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 ; oct0
.byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 ; oct1
.byte $00,$00,$00,$00,$00,$00,$00,$00,$01,$01,$01,$01 ; oct2
.byte $01,$01,$01,$01,$01,$01,$01,$01,$02,$02,$02,$02 ; oct3
.byte $02,$02,$02,$03,$03,$03,$03,$03,$04,$04,$04,$04 ; oct4
.byte $05,$05,$05,$06,$06,$06,$07,$07,$08,$08,$09,$09 ; oct5
.byte $0a,$0a,$0b,$0c,$0d,$0d,$0e,$0f,$10,$11,$12,$13 ; oct6
.byte $14,$15,$17,$18,$1a,$1b,$1d,$1f,$20,$22,$24,$27 ; oct7
; .byte $29,$2b,$2e,$31,$34,$37,$3a,$3e,$41,$45,$49,$4e ; oct8
; .byte $52,$57,$5c,$62,$68,$6e,$75,$7c,$83,$8b,$93,$9c ; oct9
; .byte $a5,$af,$b9,$c4,$d0,$dc,$ea,$f8
freq_lobyte: ;floored as well
.byte $29,$2b,$2e,$31,$34,$37,$3a,$3e,$41,$45,$49,$4e ; oct0
.byte $52,$57,$5c,$62,$68,$6e,$75,$7c,$83,$8b,$93,$9c ; oct1
.byte $a5,$af,$b9,$c4,$d0,$dc,$ea,$f8,$06,$16,$26,$38 ; oct2
.byte $4b,$5e,$73,$89,$a1,$b9,$d4,$f0,$0d,$2c,$4d,$71 ; oct3
.byte $96,$bd,$e7,$13,$42,$73,$a8,$e0,$1b,$59,$9b,$e2 ; oct4
.byte $2c,$7b,$ce,$27,$84,$e7,$51,$c0,$36,$b3,$37,$c4 ; oct5
.byte $59,$f6,$9d,$4e,$09,$cf,$a2,$81,$6d,$67,$6f,$88 ; oct6
.byte $b2,$ed,$3a,$9c,$13,$9f,$44,$02,$da,$ce,$df,$11 ; oct7
.byte $64,$da,$75,$38,$26,$3f,$89,$04,$b4,$9c,$bf,$22 ; oct8
.byte $c8,$b4,$eb,$71,$4c,$7f,$12,$08,$68,$38,$7f,$45 ; oct9
.byte $90,$68,$d6,$e3,$98,$ff,$24,$10
|
| Previous - 1 | 2 - Next | |
