Need for WLDS / WLDR ?

[PK]

Frank & Keith,

Congratulations and thank you for such a great chip. I have written dozens of pieces of code and look forward to some commercial offerings around the FV-1 soon. I feel like the FV-1 is the first DSP I could really dig into with complete ease.

My questions have to do with LFO setup.

(1) Is there anything special that the WLDR/S instruction does that you can't do by setting the range and rate coefficients for an LFO?

(2) Can you get different resolution or different coefficients in any way by setting LFOs via SOF, WRAX vs. WLDR/S?

(3) If using a WLDR/S, is the SKP above it really necessary? I have noticed no difference in operation, and I've run out of program space a couple times now so freeing a word means something.

(4) Finally, while I have your ear, I know the assembler won't allow it but if you hand crafted the instruction could you JAM a SIN LFO? Do the different types of oscillators share ALU logic at that level?

Sorry if any of the above is covered in the documentation.

Thanks again for some great silicon,
PK

[frank]

Hi PK,

Thanks for the kind words, we worked to make a useful chip that really served the market.

Now, to the questions:

(1) Is there anything special that the WLDR/S instruction does that you can't do by setting the range and rate coefficients for an LFO?

Nope, it is just an instruction to set both range and rate at the same time.

(2) Can you get different resolution or different coefficients in any way by setting LFOs via SOF, WRAX vs. WLDR/S?

Nope, no advantage to any of them.

(3) If using a WLDR/S, is the SKP above it really necessary? I have noticed no difference in operation, and I've run out of program space a couple times now so freeing a word means something.

If the only thing you are skipping at initialization is the WLDR/S then you can probably delete the SKP to save a tick.

(4) Finally, while I have your ear, I know the assembler won't allow it but if you hand crafted the instruction could you JAM a SIN LFO? Do the different types of oscillators share ALU logic at that level?

No, you cannot JAM a SIN LFO. The SIN and ramp do not share calculation hardware as it was more efficient (less gates, smaller chip) to have them each do their own thing rather than designing a generic block to do both.

[PK]

Thanks!

[mweavers]

Hi Frank,

I'm new to FV-1 and loving the capabilities! However, there is a piece of info I seem to be having trouble finding or wrapping my head around, and it's to do with the correlation between WLDR freq coef and RMP0_RATE freq (fractional) value.

You can set up ramp speed using WLDR with a binary coef ranging from -16384 to +32767. By my calculations, this gives you a pitch shift range of about -14 octaves (input freq / 16384) up to about +1 octave & 7 semitones (input freq x 3).

However, when setting the ramp speed via RMP0_RATE using acc, it seems to follow that -0.25 is one octave down (so equates to a binary coef of -8192 as you would expect) BUT seems to require +1.00 (which acc can't achieve) to get exactly one octave up (binary coef of +16384).

Can you please clarify the relationship between setting RMP0_RATE decimal fractional value and WLDR binary coef in both up pitching and down pitching (if there is a difference between the two).

Thanks in advance.

[frank]

I'm away from the office at the moment but if I recall correctly you divide the decimal value by 32768 to get the equiv fractional value.

Using the equations in AN-0001, for down we get -8192 as you stated so
-8192/32768 = -0.25

For up we get +16384
+16384/32768 = +0.5, not +1.0

I think you accidentally divided by 16384 instead of 32768 for the up calculation.

[mweavers]

Thanks for clarifying...it is possible that my pot was responsible for this as I use 3.0V for my pot supplies instead of 3.3V, therefore my RAMP_RATE may have been 9% lower than what I was expecting. (Although having said that, REFP is also fed 3.0V so I would have thought they would scale fully).

My next question is about the ramp LFO amplitude when comparing the value passed to WLDR and the value passed to RMP0_RANGE. I understand that with the sine LFO an amplitude coef of 32767 via WLDS corresponds to a decimal value of 0.999... for SIN0_RANGE. However for the ramp LFO which has the four choices via WLDR (512, 1024, 2048, 4096), what do these correspond to in the decimal domain? Do you simply divide by 32768 like with the sine LFO?

[frank]

REFP and REFN are used for the audio converters, not the POT inputs so REFP should be connected to the 3.3 rail through the 100 ohm as shown in the datasheet.

The ramp range is actually a 2 bit selection and not a value like the SIN generators. I think the 2 MSBs (not sign bit) are passed when writing to RMPx_RANGE to select the range so the values should be 0, 0.25, 0.5 and 0.75 to select between the 4 possible ranges. Been a long time since I looked at how those bits are mapped as I've never needed to dynamically change the range of a ramp LFO.

[mweavers]

Ahhhh....that explains the pot range problem all right! Thanks for clearing that up for me.

As far as setting the ramp rate via RMP0_RATE...I'm more interested in what CHO RDAL returns for RMP0, which I assumed would have the same amplitude as what you would pass to RMP0_RATE?

I'm also still confused about WLDS amplitude...the app note AN-0001 seems to indicate conflicting values. On page 3 it says:

Ka = N*32767 / 16385
= memsize * 1.999817 (memsize being the allocated delay size)

The example following this equation uses a memsize of 8193 and a WLDS amplitude of 16384, giving:

Ka = (memsize-1) * 2

However, the next example (page 5) covering the entire mem range of 32768 gives a Ka(decimal) coef of 0 to 0.999... which (according to page 4) maps to 32767, giving:

Ka = memsize-1

Sorry to labor on these details Frank, but can you please clarify for me?

Thanks.

[frank]

CHO RDAL when ramp is set to 4096 should range from 0 to 0.5

The info on page 3 is for using WLDS, the example on page 5 is using WRAX to directly write the rate register. The bottom of page 4/top of page 5 show how to convert from the calculated Ka and Kf (used with WLDS) to the equivalent decimal values (used with WRAX).

[mweavers]

Great, that explains CHO RDAL for ramp thanks!

However, you didn't really answer my question about the conflict in the app note...

Page 3: setting via WLDS suggests Ka = 2 * buffersize (approx)...

delay1 mem 8193 ;+/-4096
...
wlds SIN0, 5, 16384 ;2 x mem alloc

Page 5: setting via WRAX to RMP0_RATE suggests Ka(decimal) = 0 to 0.9999, which (when converted to Ka) gives 32767 which does NOT equal 2 * buffersize, instead it equals 1 * buffersize (approx)...

;mem is not partitioned so is 32768 (+/-16384)
...
ldax POT0 ;0 to 0.999
wrax SIN0_RANGE, 0 ;0 to 0.999 equivalent to 32767


So which one is it? Ka = 2*buffersize or Ka = 1*buffersize?

(or have I completely missed something here?)

[frank]

Actually I did answer the question but let me try it a different way...

The equations on page 3 apply ONLY to WLDS.

The calculated values on page 5 apply ONLY to WRAX.

Look at the bottom of page 4/top of page 5 to show how to take a calculated integer value from the equations on page 3 for WLDS and convert it to a decimal value for WRAX.

There is a difference in how the values are mapped from the instruction word to the internal data lines of the FV-1.

If you still think there is an error, please show an exact calculation using the same instruction (WLDS or WRAX not both) but resulting in 2 different values.

I assumed your comment "Page 5: setting via WRAX to RMP0_RATE" is a typo and you mean SIN0_RATE

[mweavers]

So for WLDS (Page 3)…

Ka = 2 * buffersize

And for WRAX (Page 5)…

Ka(decimal) = buffersize/32768

Only problem is, when you use the formula on page 4/5 to convert Ka for WLDS to Ka(decimal) for WRAX you end up with...

Ka / 32768 = Ka(decimal)

Which gives...

(2*buffersize)/32768 = buffersize/32768

Doesn't add up!

[frank]

So for WLDS (Page 3)…

Ka = 2 * buffersize

OK, an approximation but close enough for this

And for WRAX (Page 5)…

Ka(decimal) = buffersize/32768

Page 5 does not say that anywhere and there is no buffer used in the program on page 5.

The code on page 5 never uses a buffer size, it is an example of how to make an LFO to generate a sin output for use as a function generator or other application where creating an LFO could be of use. Basically, we don't care about a buffer size in this program, it only cares about generating a sin wave to output on the left DAC output and mapping the POT values to valid ranges for the SIN LFO. So do not try to equate the the values here to the values on the other pages around a buffer size that doesn't exist in the code.

[mweavers]

Ahhhh....I understand. That makes perfect sense now. Sorry it took half a dozen posts & replies! Thanks for your patience.

Mike.

[Digital Larry]

I'm also still confused about WLDS amplitude...the app note AN-0001 seems to indicate conflicting values. On page 3 it says:

Ka = N*32767 / 16385
= memsize * 1.999817 (memsize being the allocated delay size)

The example following this equation uses a memsize of 8193 and a WLDS amplitude of 16384, giving:

Ka = (memsize-1) * 2

I'm trying to understand this as well. The amplitude parameter has to be an integer, right? So it seems that

Ka = (memsize-1) * 2

satisfies this requirement as well as matching the values given in the example. Is there any benefit to using the (32767/16385) factor?

The values given above are specified as the MAXIMUM value which would sweep over the entire length of a given buffer, right? So in general (for chorus and reverb smoothing) the amplitude is going to be less than this theoretical maximum.

Also, if you had, for example a chorus, for which you wanted to have a variable delay length (specified by an equ statement, not connected to a POT) then it would make most sense to state the SIN LFO amplitude parameter also in terms of this delay length, whatever the fraction of it is.

Last dumb question (maybe), but the max value of amplitude of 32767 means that you could only sweep at the MOST over about one half of the delay memory space at one time. Although I admit that that is plenty for any application I can think of.

Thanks for the clarification.