u-he SATIN as Reason Rack Extension?

Official support for: u-he.com

u-he SATIN as Reason Rack Extension?

yes
36
54%
no
31
46%
 
Total votes: 67

jsp1979
KVRAF
3088 posts since 7 Aug, 2008

Post Fri Oct 17, 2014 6:12 am

Here's one reason why a an involved re-write of Satin to optimize the RE probably doesn't seem worth it to the u-he team.
Urs wrote: Note that we have 10 employees on the payroll now, and our 9 REs together contribute less than 2% to revenues.
EDIT: Cue the posts where it's claimed that an optimized Satin RE would sell millions.

ObsoleteAcc99
Banned
22486 posts since 5 Sep, 2001

Re: u-he SATIN as Reason Rack Extension?

Post Fri Oct 17, 2014 6:26 am

jsp1979 wrote:Here's one reason why a an involved re-write of Satin to optimize the RE probably doesn't seem worth it to the u-he team.
Urs wrote: Note that we have 10 employees on the payroll now, and our 9 REs together contribute less than 2% to revenues.
EDIT: Cue the posts where it's claimed that an optimized Satin RE would sell millions.

see i understand that , i just wanted to know if it is *possible* in any technical capacity.

I also understand the Uhbiks are VERY well optimised vst.. my own instance counts are staggering for the vst/au.

It won't make him millions, no.

BUT perhaps a satin that could be used on every track in reason like the vst can, would open a huge doorway for future U-HE RE's? I don't know. We don't know how many users of Reason there really are. Only props knows.

What i was trying to say was.. that if the non optimised current uhbik RE were sold at the same BUNDLE price as the VST.. OR.. if U-HE offered a crossgrade discount to those of the VST like RP does, they might have been what one at least calls "great sellers" rather than the disappointment they have been to Urs and a turn off to him to develop more.

Urs tid once tell me that he thought they were optimised best they can be, but i have never asked the question before of if it was technically possible to code them (which would take a shitload of time) as so called "native RE" from scratch to be on par with say propellerhead devices or some other very efficient RE.

I did mean what i said.. the only activity on uhbik since release is price doubling, and there are outstanding bugs. It's disappointing. I have no issue with the sound of them, in fact out of 11 there are only 2 i actually don't like as effects, that's pretty darn good odds. But currently i don't have a machine of realistically being able to use them in realtime on a realistic size real world project.

Shareit does not take 30% for the vst, but surely props shop infrastructure, flawless copy protection and lifetime compatibility guarantee of whatever version Urs submits, is worthy of the extra percentage over Shareit?

I guess I will find out when my first collab RE comes out.

I am absolutely at this stage not a coder, and do not INTEND to speak through my ass, but am trying to understand the actual "time and money no limit" possibilities.

Edit, just wanted to add, it's especially painful for me as uhbik F is the only good sounding flanger available for use in reason whatsoever.. i just did not expect it to eat my i7 like it does.

User avatar
Urs
u-he
23364 posts since 8 Aug, 2002 from Berlin

Re: u-he SATIN as Reason Rack Extension?

Post Fri Oct 17, 2014 6:54 am

TheoM wrote:That's not even remotely what i asked and was quoted out of context. it's fine if you don't want to answer as i felt you might not want to.

we ALL know, even the code illiterate amongst us, that there is no SSE optimisations in RE. That's been the complaint of many a dev for years already.
I don't understand why my answer wasn't correct.

In VST we have SSE right at our hands, in RE we don't.

The whole concept of Uhbiks is based on the idea that things can be optimised for SSE or Altivec. Every single line of DSP code is vector based when we compile for VST/AU/AAX. Every single line of DSP code is non-vector based when compiling for RE. Every single operation translates to 1 operation when compiling for VST/AU/AAX and 4 operations when compiling for RE. That is the only difference, nothing from our side can be done about that.

We can not somehow magically calculate only 1 operation in RE as well and hope for things to sound the same. They won't. It would break the sound.

The only thing that can be done is this:

- PH (or someone else) can improve auto-vectorization on the compiler
- PH can add a general SIMD extension format that then e.g. translates to SSE for the Intel architecture

If there is any other way, I'm all ears.

- Urs

ObsoleteAcc99
Banned
22486 posts since 5 Sep, 2001

Re: u-he SATIN as Reason Rack Extension?

Post Fri Oct 17, 2014 6:59 am

Urs wrote:
TheoM wrote:That's not even remotely what i asked and was quoted out of context. it's fine if you don't want to answer as i felt you might not want to.

we ALL know, even the code illiterate amongst us, that there is no SSE optimisations in RE. That's been the complaint of many a dev for years already.
I don't understand why my answer wasn't correct.

In VST we have SSE right at our hands, in RE we don't.

The whole concept of Uhbiks is based on the idea that things can be optimised for SSE or Altivec. Every single line of DSP code is vector based when we compile for VST/AU/AAX. Every single line of DSP code is non-vector based when compiling for RE. Every single operation translates to 1 operation when compiling for VST/AU/AAX and 4 operations when compiling for RE. That is the only difference, nothing from our side can be done about that.

We can not somehow magically calculate only 1 operation in RE as well and hope for things to sound the same. They won't. It would break the sound.

The only thing that can be done is this:

- PH (or someone else) can improve auto-vectorization on the compiler
- PH can add a general SIMD extension format that then e.g. translates to SSE for the Intel architecture

If there is any other way, I'm all ears.

- Urs
ok, so i am wrong, it would break the sound. This is what i wanted to know. So they can't be coded ground up rather than ported to be more efficient, money being no object.

well then there really IS no point in satin, you already realised that yourself from your previous post..

that will absolutely be borderline unusable on any machine not built the last three years. And very limited on those that are.

I still do not understand how softube loses only 35% real world percent of actual cpu usage vs the vst, and some are close to even 1:1 (mcdsp are 1:1 and are the most efficient EQ re on the entire platform.. 250 mcdsp EQ to 15 uhbik are the ratios).

So i don't get it, when i understand coding someday, (am about to start), i might! cheers

ObsoleteAcc99
Banned
22486 posts since 5 Sep, 2001

Re: u-he SATIN as Reason Rack Extension?

Post Fri Oct 17, 2014 7:01 am

Ps i have told you many times Urs, that it is not 4 to 1.

Even using single core stacking on live input buffer (so no logic "cheat" playback buffers are in effect) the differences are *minimum* 10 to 1. Sorry but it's true.

I have made the videos and have no need to lie about that, nor would I. I approach my performance testing with full integrity.

User avatar
Urs
u-he
23364 posts since 8 Aug, 2002 from Berlin

Re: u-he SATIN as Reason Rack Extension?

Post Fri Oct 17, 2014 7:07 am

Well, I wouldn't know how any "from the ground up" rewrite would change anything in terms of performance. But I'm quite sure that if we had to write everything from the ground up for RE, there would not have been a single RE from us.

User avatar
Urs
u-he
23364 posts since 8 Aug, 2002 from Berlin

Re: u-he SATIN as Reason Rack Extension?

Post Fri Oct 17, 2014 7:11 am

TheoM wrote:Ps i have told you many times Urs, that it is not 4 to 1.
So what do you suggest we do about it?

User avatar
whyterabbyt
Beware the Quoth
26775 posts since 4 Sep, 2001 from R'lyeh Oceanic Amusement Park and Funfair

Re: u-he SATIN as Reason Rack Extension?

Post Fri Oct 17, 2014 7:14 am

TheoM wrote:Ps i have told you many times Urs, that it is not 4 to 1.

Even using single core stacking on live input buffer (so no logic "cheat" playback buffers are in effect) the differences are *minimum* 10 to 1. Sorry but it's true.

I have made the videos and have no need to lie about that, nor would I. I approach my performance testing with full integrity.
I believe he's saying '4 instructions to 1' not '4 times the processor cycles to 1'

Different processor instructions take different numbers of processor cycles to complete. Its entirely plausible the instructions being compiled to for RE could be slower than SIMD instructions as well as having the lack of 4-way parallelism.
"The bearer of this signature is a genuine and authorised pope."

User avatar
Urs
u-he
23364 posts since 8 Aug, 2002 from Berlin

Re: u-he SATIN as Reason Rack Extension?

Post Fri Oct 17, 2014 7:25 am

Actually, I don't think I want to deal with RE any further. I've asked them to take our out of the store. We'll see hat they say and how they suggest to handle this.

It's nothing but distress.

Return to “u-he”