u-he

4damind · Post by **4damind** » Sat Sep 07, 2013 8:08 am

Some bugs I found with the latest Beta (1818):

random crashes if switching presets on the main screen (not in the preset browser, this is working)
freezing of Cubase 7 64Bit if moving the range knob (Phaser)

masterhiggins · Post by **masterhiggins** » Sat Sep 07, 2013 8:09 am

morelia wrote:You can buy it on the first post of this thread. Not released officially though so I think you get the beta.

Oh sorry. I missed that. Buying now. Thanks bro!

-Sam

Howard · Post by **Howard** » Sat Sep 07, 2013 8:40 am

coincidental wrote:One odd thing I noticed - the high cut knob in delay mode seems to be scaled differently to cursor movement when compared to other knobs (and certainly the low cut knob next to it). Anyone else getting this?

This one's been on our to-do list for a while (not top priority yet).

sascha · Post by **sascha** » Sat Sep 07, 2013 10:10 am

4damind wrote:Some bugs I found with the latest Beta (1818):

random crashes if switching presets on the main screen (not in the preset browser, this is working)

freezing of Cubase 7 64Bit if moving the range knob (Phaser)

The two seem to be related to an issue we found lately. The flange mode uses actually two machine models, where one is at a fixed delay, and the other is either behind or ahead (therefore the static delay of machine I). Whenever the 'range' knob gets changed (or a preset changes it), the overall latency gets reported.
Especially Cubase seems to be very clumsy in this regard, as it was easy to provoke complete deadlocks. Our current solution is far from ideal, but already a step forward and we need to keep investigating further. Our plan currently is to change the report regime dependent on what host we're running in, like for instance only report on instantiating or explicit on/off (suspend/resume). To make things worse, the different APIs have different approaches here.
Same happens when you press bypass or 'tape bypass' in studio mode, latency changes as well (in the 3-to-6 samples ballpark), so this might also affect Cubase.

Agility · Post by **Agility** » Sat Sep 07, 2013 10:16 am

One bug I've noticed so far is in one project I loaded Satin into, when using the A type compander encoding or decoding or both the audio would cut out until changing it to another compander mode and bypassing the plugin and unbypassing again, internally.

One question, Satin has a mix knob on it and is a nice feature, just wondering if back in the day in hardware, there was such a way to mix in NR?

Thanks.

4damind · Post by **4damind** » Sat Sep 07, 2013 10:55 am

sascha wrote:
4damind wrote:Some bugs I found with the latest Beta (1818):

random crashes if switching presets on the main screen (not in the preset browser, this is working)

freezing of Cubase 7 64Bit if moving the range knob (Phaser)
The two seem to be related to an issue we found lately. The flange mode uses actually two machine models, where one is at a fixed delay, and the other is either behind or ahead (therefore the static delay of machine I). Whenever the 'range' knob gets changed (or a preset changes it), the overall latency gets reported.
Especially Cubase seems to be very clumsy in this regard, as it was easy to provoke complete deadlocks. Our current solution is far from ideal, but already a step forward and we need to keep investigating further. Our plan currently is to change the report regime dependent on what host we're running in, like for instance only report on instantiating or explicit on/off (suspend/resume). To make things worse, the different APIs have different approaches here.
Same happens when you press bypass or 'tape bypass' in studio mode, latency changes as well (in the 3-to-6 samples ballpark), so this might also affect Cubase.

Aah, yes... this makes sense, so it's a Cubase specific problem and unfortunately a show stopper for Cubase users. Do you think the release will work for Cubase users or is this host specific stuff part of a further update?

Sascha, fällt mir gerade noch ein.. U-He Skalen sind ja immer bisschen sehr technisch. Im Delay "4" bedeutet 4x 16tel also eine Viertel? Was ist 1/8d also punktiert, 2,5?

Urs · Post by **Urs** » Sat Sep 07, 2013 11:01 am

Agility wrote:One bug I've noticed so far is in one project I loaded Satin into, when using the A type compander encoding or decoding or both the audio would cut out until changing it to another compander mode and bypassing the plugin and unbypassing again, internally.

oh... can you reproduce it or is it random?

One question, Satin has a mix knob on it and is a nice feature, just wondering if back in the day in hardware, there was such a way to mix in NR?

It was a bit different back in the days. The reel 2 reel tape machines hadn't necessarily had noise reduction at all. But people would have separate NR modules in 19 inch racks. As those modules typically consisted of a compressor and an expander, one could just use them as such, even without the tape. Thus they could be used as send effects or inserts in a console, with the otion to do parallel compression. The mix knob in Satin lets one use them for parallel compression too

Urs · Post by **Urs** » Sat Sep 07, 2013 11:04 am

4damind wrote:it's a Cubase specific problem and unfortunately a show stopper for Cubase users. Do you think the release will work for Cubase users or is this host specific stuff part of a further update?

I'm going to work today to see if I can come up with a workaround.

I.e. I'll check if the host is Cubase and then I'll simply refrain from reporting changes to plug-in latency while the host is in playback mode.

Are there any problems with the bypass knob or flanger range when Cubase is not in playback mode?

4damind · Post by **4damind** » Sat Sep 07, 2013 11:16 am

Urs wrote:Are there any problems with the bypass knob or flanger range when Cubase is not in playback mode?

Yes, it's the same behavior if Cubase is not playing (deadlock). I can move the knob sometimes and at some point it freezes Cubase. Maybe that too many changes will force this freeze. If Cubase is playing the deadlock is instantly.

It seems (as Sascha stated) the latency change can only be reported to the host if the plug-in is loaded/un-bypassed/activated (for Cubase).
But: latency should also reported before (offline) rendering starts?

The question is of course, is this a problem for typical usage? If Cubase will use a wrong latency compensation if the flanger settings have changed?

Urs · Post by **Urs** » Sat Sep 07, 2013 11:24 am

4damind wrote:
Urs wrote:Are there any problems with the bypass knob or flanger range when Cubase is not in playback mode?
Yes, it's the same behavior if Cubase is not playing (deadlock). I can move the knob sometimes and at some point it freezes Cubase. Maybe that too many changes will force this freeze. If Cubase is playing the deadlock is instantly.

It seems (as Sascha stated) the latency change can only be reported to the host if the plug-in is loaded/un-bypassed/activated (for Cubase).
But: latency should also reported before (offline) rendering starts?

The question is of course, is this a problem for typical usage? If Cubase will use a wrong latency compensation if the flanger settings have changed?

Thing is, we use the calls described in the VST SDK to report dynamic changes to latency.

In Tape Bypass mode, the latency is 6 samples less.

In Flanger mode the latency changes with the range parameter, i.e. from a few samples to about a few milliseconds.

So what we do here is, we switch to the best latency possible for a given situation. Funny enough that Cubase handles this the worst while all other hosts seem fine...

So now I'll implement the change so that Cubase gets a latency updates only when playback is stopped, and we'll file a bug report with Steinberg (once we figure out how).

4damind · Post by **4damind** » Sat Sep 07, 2013 11:35 am

Urs, will you provide a "RC6" if you have implemented the workaround for Cubase users?

Compyfox · Post by **Compyfox** » Sat Sep 07, 2013 11:42 am

I think you people should know this, but there seems to be a (huge) rumor revoling around the plugin manager in Cubase, that doesn't show correct latency values (especially with VST3) and can't therefore do a correct PDC.

There is no mention about this in the update history (up until 7.06 at least, which is bound to hit mid-month), but it could have influence on what Frank is reporting.

I haven't tested the Flanger Mode yet in C7.04 32bit, only the tape and the delay mode. So I can't confirm anything as of this moment. But I can take a closer look in a minute.

Stollmeister · Post by **Stollmeister** » Sat Sep 07, 2013 11:44 am

No ideas about the delay feedback I mentioned yesterday? Based on some replies it seems to be confined to Windows right? Maybe only Windows 64 bit.

Compyfox · Post by **Compyfox** » Sat Sep 07, 2013 11:48 am

If you mean crazy intense feedback noise if you turn up the knob too much, then yes I can confirm that on Win7 x64/32bit Plugins and host.

But I thought it was a feature.

Compyfox · Post by **Compyfox** » Sat Sep 07, 2013 12:14 pm

Info: Using Win7 SP1 x64 with C7.04 32bit over here.

4damind wrote:[*]random crashes if switching presets on the main screen (not in the preset browser, this is working)

Couldn't confirm this yet.

4damind wrote:[*]freezing of Cubase 7 64Bit if moving the range knob (Phaser)

Confirmed for VST3 version
Confirmed for the VST2 version. Only that it happened sooner (VST3 stuttered a bit before anything happened)

The "shut off audio stream" bug from Wavelab with the Delay MOde (if you press Sync) doesn't happen in Cubase. But I found another one:
The VST3 version doesn't show any LED movement of the tabs if you switch to the Delay mode.

sascha wrote: Especially Cubase seems to be very clumsy in this regard, as it was easy to provoke complete deadlocks. ... Same happens when you press bypass or 'tape bypass' in studio mode, latency changes as well (in the 3-to-6 samples ballpark), so this might also affect Cubase.

I can confirm that with the VST2 version. However this only happens if you click wildly on the Bypass Tape button.

I just tried it again with both the VST2 and VST3 version, really fast clicking, for a couple of seconds. Plugins continued working. So I call this a sporadic issue.

Urs wrote:So what we do here is, we switch to the best latency possible for a given situation. Funny enough that Cubase handles this the worst while all other hosts seem fine...

So now I'll implement the change so that Cubase gets a latency updates only when playback is stopped, and we'll file a bug report with Steinberg (once we figure out how).

I think we're now at a point, where Cubase catched up with all the issues, that the developers need to burn for all the mistakes Steinberg did.

It's no secret that developers course and swear about Steinberg being constantly special. They don't even stick to their own standards, even though they claim it and blame it on the developers!

Still, most bugs I've encountered are not drastic if you use the plugin regulary, and not click around like a maniac. But, it shouldn't happen otherwise either.

BTW:
VST3 version shows 0 (samples?) latency (v1.2.0.1 - SDK 3.5.1)
VST2 version shows 22 (samples?) latency (v1.0.1.0 - SDK 2.4)

Mind you, Slate VTM shows 3758 (must be samples, else that's insane in ms!).

Maybe there are issues with the VST2 SDK as well? Steinberg should really tell you how to render VST2 with the VST3 SDK - if that keeps the latency down?

But if the Plugin Information and therefore the PDC system really is borked (which I now highly assume!!!), and Steinberg kept it a secret - you can do what you want - it's not your fault!

u-he

KVR Audio

Satin goes V1.1