| | la_mettrie
Registered: Feb 2012
Posts: 21 |
Finding a good vibrato
On GoatTracker I've always had difficulties to find a suitable vibrato while I don't recall any problems like this when using PC trackers (IT, S3M).
Or have my ears just became more sensitive for a good vibrato???
I have let's say, values like 02 40 (speed 02 & depth 40), then I try something like 01 or 03 for speed (others feel inappropriate) and different values (from 10 to F0) for depth. But nothing seems to satisfy.
It seems those few GoatTracker SNG files which have been leaked use roughly similar range of vibrato values. This may suggest that using some totally different values won't help.
Are there further techniques to find more different kind of vibratos? Basically, what I feel is that there are no enough alternatives for different _speeds_. |
|
... 18 posts hidden. Click here to view all posts....
|
| | Adam
Registered: Jul 2009
Posts: 321 |
Quoting franz_koopaOkay, then I guess everybody else has problems too (but I'm not sure if you ppl have balls to admit it...)
I guess some people do. I don't have any problems using vibrato no matter what tracker it is. I guess trying to find the right type of vibrato that fits with the overall speed and composition of the tune is the trickiest part but after years of making music with trackers you learn what sounds best, what doesn't and when to use it. |
| | Radiant
Registered: Sep 2004
Posts: 639 |
Tweak it until it sounds right. You've got space for hundreds of different vibratos in the speed table. |
| | Frantic
Registered: Mar 2003
Posts: 1627 |
Hey.. speaking of such things.. is there any C64 music player at all which implements portamento = sliding from note X to note Y in fixed speed, independently of which notes X and Y that are involved? I am pretty sure there is none, but I thought I should ask anyway. A bit off topic perhaps.. but still related to note independent freq calcs.
Note that it is possible to make use of a standard freq table with freqs for all the standard notes to get the offset for sub note steps of at least 16 step resolution (i.e. 16 subnotes, or fine tune steps, between each standard note) by picking the right values from the freq table. Makes it a lot easier to do freq stuff in fixed speed/"size" independently of which notes that are used. In fact, with just an additional subtraction, one can also get the above mentioned 16 steps not only between adjacents notes, but between any two notes, which could be used for portamento.
Another tip, which I haven't seen anyone else exploit: If you can live with note freq values that are rounded down (floored) rather than rounded the standard way, you can actually have partially overlapping tables for the hibyte and the lowbyte of the freq values. This one is a bit non-standard considering at what note is starts, but it illustrates the concept:
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
Note how the lines which are commented away are identical with the first lines in the lowbyte table. Hence no need to duplicate these. |
| | Hermit
Registered: May 2008
Posts: 208 |
@Frantic:
SID-Wizard makes the slide/vibrato-amplitude values in SID note-dependent, so you get nearly the same audible slide-speed for notes in high/low octaves.
I use the frequency table as exponential table for multiplication, of course with lot of optimizations, so it's not kinda exact multiplication, but does the job.
Although, the slide-speed is only set on note-start, and isn't dependent on current pitch during the slide, but it's usually not a big issue for portamentos, they're local enough not to cause big audible difference...
I used the similarity of lo/high frequency tables in SID-Hacker 2.5 to detect the played notes from frequencies, otherwise it would have been impossible to look up on C64...
I used this fact in SID-Wizard as well, but don't remember from the top of my head if only for the Oscilloscope display or the player too...
To the topic: In my old attempt to create C64 player, HMTSYNTH, which is on the 3SID tracker disk (but unfinished, no load/save menu..) I used sine-table to create the vibrato and used normal multiplication, but i think there was no big difference to the easier-to-implement triangle vibrato.
On the other hand, the strict vibrato-speeds on C64 are limiting factors, such as the strict tempos for PAL timing... |
| | SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
im not sure what youre asking frantic..
in SDI you can make any kinda slide you want, but you always have to set a speed. |
| | Hein
Registered: Apr 2004
Posts: 933 |
Frantic, that's what I'm using aswell, for calculations on the note-dependant glissandos and the PW modulation. It only wastes some extra memory on zero bytes.
pw_lookup_hi
.byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
.byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
.byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00
freq_table_hi
.byte $01,$01,$01,$01,$01,$01,$01,$01,$01,$01,$01,$01
.byte $02,$02,$02,$02,$02,$02,$02,$03,$03,$03,$03,$03
.byte $04,$04,$04,$04,$05,$05,$05,$06,$06,$06,$07,$07
.byte $08,$08,$09,$09,$0a,$0a,$0b,$0c,$0d,$0d,$0e,$0f
.byte $10,$11,$12,$13,$14,$15,$17,$18,$1a,$1b,$1d,$1f
pw_lookup_lo
.byte $20,$22,$24,$27,$29,$2b,$2e,$31,$34,$37,$3a,$3e
.byte $41,$45,$49,$4e,$52,$57,$5c,$62,$68,$6e,$75,$7c
.byte $83,$8b,$93,$9c,$a5,$af,$b9,$c4,$d0,$dd,$ea,$f8
freq_table_lo
.byte $07,$17,$27,$39,$4b,$5f,$74,$8a,$a1,$ba,$d4,$f0
.byte $0e,$2d,$4e,$71,$96,$be,$e8,$14,$43,$74,$a9,$e1
.byte $1c,$5a,$9c,$e2,$2d,$7c,$cf,$28,$85,$e8,$52,$c1
.byte $37,$b4,$39,$c5,$5a,$f7,$9e,$4f,$0a,$d1,$a3,$82
.byte $6e,$68,$71,$8a,$b3,$ee,$3c,$9e,$15,$a2,$46,$04
.byte $dc,$d0,$e2,$14,$67,$dd,$79,$3c,$29,$44,$8d,$08
.byte $b8,$a1,$c5,$28,$cd,$ba,$f1,$78,$53,$87,$1a,$10
.byte $71,$42,$89,$4f,$9b,$74,$e2,$f0,$a6,$0e,$33,$20
I think I considered fixed steps for glides no matter how high the delta between de notes, but in the end I decided not to implement it. I think it's a choice between the two (fixed steps selection or manually set glide speed), else the player code will get too large (and possibly rastertime too) |
| | SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
spend 30 secs to make the vibrato you want..
spend 5 mins to find out how to make it, makes all the difference.
try all: slow, fast, middle
play around with it, for no use, just to control it.
thats the way you learn what to do. |
| | HCL
Registered: Feb 2003
Posts: 716 |
..but how do those fancy Amiga and PC-trackers implement a proper vibrato then? Perhaps something like:
F(t) = F0 + ramp(t) * sin(speed * t); ??
..where ramp(t) is a simple envelope-function like step-function, ramp with/without amplitude limit, and possibly also decreasing ramp..
or perhaps it should rather be..
F(t) = (F0 * (1 + ramp(t))) * sin(speed * t);
Any suggestions? |
| | Magnar
Registered: Aug 2009
Posts: 60 |
HCL, it is a bit more easier to modify the playback of a sample when you have direct possibility to influence the xxx kHz it plays.
A simple sine function on the frequency to be played is all that is necessary for a vibrator function with sine curves.
However, compare that with real life vibration, is not the same. If I put my finger on a guitar and vibrate the note, it is not necessary same as a sine curve... It is actually more as a triangle. Or sometime, it is more like sine+triangle+some noise to it :) as the speed is not constantly the same of my finger movement.
Anyway, triangle vibrator seems just fine to me on C64.
|
| | Mixer
Registered: Apr 2008
Posts: 422 |
A guitar vibrato is done by stretching string sideways, its frequency is always above the base fret frequency. Some playroutines implement vibrato this way and forget the middle note frequency altogether.
The extended frqtable for "sub" frequencies that Frantic hinted of can take a bit more cycles on each call, but arpeggio, vibrato and slides become same operation - adding something to the base note extended frqtable index. In practice, the added index bits need some handling and that eat cycles.
An octave up is always 2x frq or one bit shift left, it is obvious that 8 ocaves jump makes 8 bits shift to a register value. I am pretty sure this type of extended table is in use somewhere as it is very old idea.
But: why not do an LFO? a block long sin table. Add two sines of different phases together. Then alter phase difference for amplitude changes and run the index faster or slower for speed. Every democoder can write such stuff blindfolded.
That LFO can be reused for filter and pwm so they do not need register specific up/down routines, just a loop calculating through all the needed "LFO"s and then pick values for registers or offset for the extended frq table index. I am sure some routines use this too already. (I've got some such old test routines somewhere as well)
Such stuff takes more cycles and memory for variables and sin table, and require bring new variables to initialize for each instrument - but it sounds very much like analogue synths do.
|
| Previous - 1 | 2 | 3 - Next | |
