Octave up and down

Algorithm development and general DSP issues

Moderator: frank

Sweetalk
Posts: 141
Joined: Thu Oct 15, 2009 5:13 am

Post by Sweetalk »

There is a way to reduce the predelay time? it's a little bit to long
frank
Posts: 1244
Joined: Wed Oct 19, 2005 12:26 pm
Contact:

Post by frank »

Sweetalk wrote:There is a way to reduce the predelay time? it's a little bit to long
You would need to use a shorter delay line in the program. See the section on pitch shifting in AN0001 http://www.spinsemi.com/Products/appnot ... N-0001.pdf on available lengths and how to set them in code.
Frank Thomson
Experimental Noize
djmalan
Posts: 36
Joined: Fri Mar 06, 2009 8:22 am

Post by djmalan »

Please not to use shorter delay for high pitch range ,it makes noticable crossfading distortion.Once I used 512 for 1 oct. than I had to ask to frank if there was an error about the calculation formula but there was not an error ,only the cross fading noise was disturbing the signal too much that there happened like a detuned (out of the note) sound. :D I tried this experiment with the Electro saz instrument(uses pickups ,smilar like electricguitar) and than with electric guitar ,the result was the same .But I can not notice this detuned sound with my own voice . :lol:
donstavely
Posts: 53
Joined: Thu Jan 07, 2010 2:29 pm
Location: Windsor, Colorado

Post by donstavely »

Thanks, Frank, for the octave up and down code. It is very cool to have a POG-like effect for the FV-1.

I have been thinking about ways to address the artifacts that necessarily come with pitch transposition. I want to get yours and others comments on whether you think they are worth pursuing.

The things that I would like to address are:
1) The delay of the note, due to the delay memory
2) Sometimes the note-on transient is reduced or missing, due to the cross-fading between memories
3) The tremolo effect on certain pitches due to phase cancellation between the two signals during cross-fading.

The first thing I want to do is "retrigger" the delay memory by detecting note-on transients. I am hoping that this will fix the issue of disappearing note attacks, and to some extent the note delay.

As has been discussed, shortening the delay memory can help the delay, but the cross-fade rate quickly gets to sounding ugly. I was wondering if I could figure out a way to make the delay short right after the note-on trigger, then either lengthen it, or cross-fade to a longer delay, to get back to "musical-sounding" values. The question is, how?

Lastly, I thinking that chorusing the signal before pitch-transposing might mix up the phases enough to reduce the cancellation and resulting tremolo effect. I know it will make things sound different, the question is whether it will sound better or worse.

I want to try some or all of these when I get the time. I will report results and post code if there is interest. Before then, I would welcome comments from Frank or others that have been exploring this stuff.
Don Stavely
frank
Posts: 1244
Joined: Wed Oct 19, 2005 12:26 pm
Contact:

Post by frank »

A little chorus is a common trick to hide phase cancellations in reverbs so give it a try here.

Using two different length delays for the pitch shift and cross fading between them is an interesting idea, maybe use a low pass filter to detect the envelope of the signal and if it rises sharply then quickly shift to the short delay output and as it settles fade back to the long delay output. So the first derivative of the envelope would give us the change in attack and that would be used as the xfade coefficient I think.
Frank Thomson
Experimental Noize
donstavely
Posts: 53
Joined: Thu Jan 07, 2010 2:29 pm
Location: Windsor, Colorado

Post by donstavely »

Hey Frank.

In the pitch transpose section of your (excellent) app note AN0001 you describe how the second ramp is derived from the first (adding 0.5 mod 1.0, essentially), and that the crossfade trapezoid is derived from the same ramp. You also say that the frequency and amplitude values of the ramp generator can be written "on the fly".

My questions are:

- If I change the amplitude, say from 2048 to 4096, I assume that the ramp value will continue to count without discontinuity. What about the second derived ramp? Will it add 1/2 of the new amplitude and wrap around immediately?

- In the same circumstance, what will happen to the crossfade ramp? Since I am not sure how it is generated, I don't know how it will behave with an on-the-fly change in amplitude.

I am asking because I want to try to do a better job of capturing the note attack and reduce the delay for the octave-up pitch transpose. I want to retrigger the ramp with a note detector, use a short ramp for a few ramp cycles to get the attack, then switch to a longer ramp to get back to more "musical" crossfade rate. So I am trying to figure out how to "shift gears" with minimum discontinuity.

Does this make sense?
Don Stavely
frank
Posts: 1244
Joined: Wed Oct 19, 2005 12:26 pm
Contact:

Post by frank »

Well, the pointers and ramp should all calculate correctly relative to the length but I would expect to hear a discontinuity when the length changes. But give it a try and see what it sounds like.
Frank Thomson
Experimental Noize
donstavely
Posts: 53
Joined: Thu Jan 07, 2010 2:29 pm
Location: Windsor, Colorado

Post by donstavely »

You are right - there is a discontinuity no matter where in the ramp I switch the ramp length. I assume there is no way to write an arbitrary value to the ramp LFO counter register, right?

I would love to come up with some clever solution, but the pitch-shift algorithm just seems a little too "hard-wired" on the FV-1.
Don Stavely
frank
Posts: 1244
Joined: Wed Oct 19, 2005 12:26 pm
Contact:

Post by frank »

Yeah, if you use the LFOs it is a very hardwired algo. But you could try generating the ramps and using rmpa to read from memory. One problem is that the MAC/ALU hard limits, it won't allow a value to roll over which would make it easy to generate ramps. So may have to do a little number manipulation (i.e. ramp from -0.5 to +0.5) and manually detect >+0.5 so something like:

ramp = ramp + increment;
if (ramp > +0.5) {
ramp = -0.5 + (ramp - 0.5);
}

use the upper bits as address, lower as interpolation coeff.

Crossfade coeff is a bit trickier to calculate but should be possible...
Frank Thomson
Experimental Noize
livingston
Posts: 131
Joined: Sun Nov 15, 2009 3:37 pm
Location: New Orleans, LA US

Post by livingston »

Did you ever get anywhere with this, Don? I wonder if any good info could be learned from IVL's patent for the Whammy pedal. It's obviously possible to get less latency with pitch shifting, and the original Whammy came out 20 years ago. Surely the FV-1 can at least match that hardware?
donstavely
Posts: 53
Joined: Thu Jan 07, 2010 2:29 pm
Location: Windsor, Colorado

Post by donstavely »

Yes, I actually have something I am almost happy with. It is pretty convoluted, though.

The idea is to use a few short ramps after a note trigger to capture the transient with as little delay as possible, and then revert to the standard long ramp transpose algorithm after that. Since it is not possible to change the delay length on the fly without discontinuity, I had to create a second and third delay, play with pointers to write partway into them (to shorten the delays), and then do my own ramp generators to crossfade between them.

Very painful and hard to understand, but it works. It burns pretty much all of the code space to do octave up and down. But the delay is less than 15ms. The standard algorithm is about 4X longer, and can sometimes miss the note transient altogether.

(Note to Spin: I would like to talk to you about how to make the crossfading more general on your next chip, if there will be one.)

I still want to tune up the note trigger. It is quite reliable over a wide range of input levels and playing styles. Still, any false retrigger in the middle of a chord sounds bad, and must be avoided. This is what I want to tune up.

I am not familiar with the IVL patent. I have done standard analog monophonic octave up and down, and even used the same circuit times six with a hex guitar pickup to make a hex guitar synth that is fully polyphonic. But this pitch transpose method is the way to go, at least digitally.
Don Stavely
Fulcrum
Posts: 7
Joined: Tue Oct 04, 2011 10:48 am

Post by Fulcrum »

Hey Don!

Can you share the code that you're working on? maybe someone could add his thoughts to it. I'm currently starting my own experiments with FV-1 and this code could be really helpful for everyone including myself.

PLEEEEEEASE? :D
donstavely
Posts: 53
Joined: Thu Jan 07, 2010 2:29 pm
Location: Windsor, Colorado

Post by donstavely »

Sorry, Fulcrum. I can't share the code itself for several reasons:
a) Much of the code will be used in a commercial product (though not octave up/down), so I want to keep it proprietary.
b) It is very hard to understand, even with comments and help, and even for someone fluent in DSP and on the FV-1.
c) It has been a long time since I worked on this code, and I don't remember the details of how it works.

I don't mean to be a Grinch. I am happy to give general information, but you will have to wrap your head around the algorithms and grind through the code.

Here is one quick and easy trick that reduces the pitch shift latency by 25%: If you look closely at the behavior of the crossfade generation associated with the ramp LFO's, you will see that their value is zero for the first and last 1/8th of the total delay length. So instead of writing your input signal to the head-end of the delay, you just write it 1/8 of the way in. Say for a 4096 word delay, instead of "wra DELAY" you just use "wra DELAY+512". Since the crossfade starts at word 512, you just saved 512 samples worth of unnecessary delay.

Don
Don Stavely
Fulcrum
Posts: 7
Joined: Tue Oct 04, 2011 10:48 am

Post by Fulcrum »

ok, I see, no prob man.

The hint with crossfading earlier is worth developing further, thanks for it!
Sweetalk
Posts: 141
Joined: Thu Oct 15, 2009 5:13 am

Post by Sweetalk »

Nothing better to make a octave up/octave down pedal than a Channel handbah :lol:
Post Reply