Real-Time Formant Shifting: Any plugins do this? (HELP?!)

[Spyro]

@jackle&hyde

Here on FL studio, when I made a render containing omnivox, it added a time lag on the audio that's beeing processed by it (for instace, remco's voice)

I know omnivox adds some latency, I noticed it when working realtime so I just moved the remco's audio clips backwards to compensate, but even if it sounds in time when playing realtime, when rendering it adds more latency somehow.

Hope thats clear enough, if you want an example just ask.

[useruseruser]

@jackle&hyde

Here on FL studio, when I made a render containing omnivox, it added a time lag on the audio that's beeing processed by it (for instace, remco's voice)

I know omnivox adds some latency, I noticed it when working realtime so I just moved the remco's audio clips backwards to compensate, but even if it sounds in time when playing realtime, when rendering it adds more latency somehow.

Hope thats clear enough, if you want an example just ask.

Sorry, but we cannot compensate such behaviour (nobody actually can do that - in our humble opinion).
If the host application handeles "realtime" different than "rendering", so that's obviously a host problem. Right?

The plugin even don't "know" something about the things, the host application currently does with the output it produces (at least it should not know that much) ...

A plugin "lives inside a black box". Doing merely, what requested by the host. Especially it can not do any delay compensation itselves. That's the job of the host.

(Yes. We are conscissious, that many different hosts actually handle that quite different - some logically (by rendering with the same blocksize than the realtime process), some others do what they want (then saying: that plugin does wrong things!)).

[shamann]

Spyro, I'd recommend processing the voice separately, then sync'ing the processed audio clips with the remainder of the track. It adds one extra step, but unless the host fully compensates for the latency, it's you're only bet.

[cron]

Wicked sounding plug in. Thanks a lot.

Let me get the bug reports rolling.

Setting both formant and pitch 100% to the right crashes Audiomulch, giving the error (in a box labelled "Microsoft Visual C++ Runtime Library")

"Runtime Error!

Program: (Audiomulch v0.9b19 path)

Abnormal program termination"

This is consistently reproduceable on my machine (Athlon XP 2200+, 512MB RAM). Tried with more than one Audio driver (i.e. Windows Multimedia as well as ASIO).

Also, I managed to make the plug crash (but not Audiomulch) when both formant and pitch were set 100% to the left. So far I haven't been able to reproduce this.

Hope this helps. If you need me to get in contact with Ross (Audiomulch developer) to help you solve these (or indeed if it's an Audiomulch problem), let me know.

Cheers.

We cannot reproduce such behaviour with Cubase nor WaveLab.
The question is, is it a GUI (or mouse) problem or does it also occur if you use external controllers to get those extreme positions?

If the latter is the case, so there meight be the chance, that there is anything wrong with the audio opcode (ouside the limits).

Otherwise it meight be, that anywhere inside the signal way the parameters are "distorted".

We just checked inside our plug, whether there are any parameters outside the limit: No.

Yep, this happened when using the mouse.

Afraid I'm off out now, but I'll try using MIDI controllers and Mulch's deault GUI option and get back to you a little later.

How about you shamann? Do you get this problem in Mulch too?

Thanks again for this great sounding plug.

edit: I've just remembered my MIDI controller is broken.

[useruseruser]

Tip: if you try it, don't open the GUI (else it probably would do the same thing, cause the faders are automated via MIDI). They don't automate, if the GUI is closed.

edit:
If your controller is broken, then you probably could "paint" controllers into your tracks?

[cron]

Yep, if you don't open the GUI and just use Mulch's automation to do it, it works just fine . Should I get in touch with Ross about this?

[useruseruser]

I can't explain it otherwise...

For information: We develop with one of the latest stable VSTGUI libraries (from development snapshots).

And we do really nothing special. The parameters range is in both cases 0.f to 1.f. And we use chunks for the patch and bank formats.

I hope, AudioMulch don't add rounding errors to the parameters...

Never had any problems here.

[Spyro]

Spyro, I'd recommend processing the voice separately, then sync'ing the processed audio clips with the remainder of the track. It adds one extra step, but unless the host fully compensates for the latency, it's you're only bet.

Thanks for the tip.

Just wanted to point that out because I never saw this behaviour on a plugin (not on SIR or ConvoBoy or any other adding considerable latency) is like getting double latency when rendering which is weird. (I know omnivox isn't finished yet, Im just trying to help but I'll shut up now hehe)

I'll try on Tracktion now.

Does anyone has the same result using another host?

[shamann]

How about you shamann? Do you get this problem in Mulch too?

I only used it on Mulch's default GUI, as I'm on Win98, which doesn't display the widgets properly (a common problem these days as the latest VC++ compiler/libraries added a GUI incompatibilty with Win98). I haven't had any crashes.

Win98 will be out of my life for good soon, so I'll test once I'm over to WinXP.

[useruseruser]

@spyro:
Maybe there's something, we don't know?

Could it be, that you tried to render with different sampling frequency than the realtime process was?

Then actually would it cause such behaviour.

The latency issue of OmniVox is caused by the internal pitch detection opcode (you know: Pitch synchronuous Overlapp and Add - needs to detect the pitch to synchronize the overlapping finally ).

To cover the normal range of a human voice you need at least a certain amount of samples for analysis. Else you wouldn't be able to detect bassos.

That amount meight be different when used with different sampling rates ...

So we suggest to render with the same sampling rate as the realtime playback is - or vice versa. This way it should work

[Spyro]

I have tried on Tracktion and it renders fine, I got the same latency realtime and rendering.

Yes I'm always using 44.1khz

The latency issue of OmniVox is caused by the internal pitch detection opcode (you know: Pitch synchronuous Overlapp and Add - needs to detect the pitch to synchronize it finally ).

To cover the normal range of a human voice you need at least a certain amount of samples for analysis. Else you wouldn't be able to detect bassos. That amount meight be different when used with different sampling rates ...

Yes I know that omnivox needs time to process the audio signal, and that's the latency I can hear when playing realtime, is only when rendering that seems to double the latency. Let's say realtime latency is 300ms, when rendering is 600ms (or around that)

This on FL only, so yes it can be host related too.

[useruseruser]

Then I assume, FL simply "forgets" to calculate the applied track delay when rendering ? ...

Or it sends anyhow different initialization data to the plugin when rendering to disk.

Our plug cannot be it, because we don't know, what the host is doing with our oudio material. There is nothing which tells us "add more or less latency now!".

So that's really strange.

[Spyro]

Do you mean FL doesn't compensate the latency?

FL doesn't have any latency compensation system, that's why I compensate manually by moving the audio clip backwards, so it sounds in sync relatime, until there all works fine. When rendering, I expect to have all in sync too as in realtime, but I get a delay again.

[useruseruser]

Ok. Then we'll buy you a new host application!
Which one do you want to have?

[useruseruser]

I'm a bitch sometimes...