u-he SATIN as Reason Rack Extension?

[pdxindy]

Zebra does not do feedback loops between modules... any feedback is hardwired in the module itself (XMF Filter).

Hehehe, that's only for audio signals. Modulation signals can have feedback loops all over the place in Zebra, albeit not latency free ones (they update in the kilohertz range though - which is usually good enough for modulation)

Yeah, I realized I did not make my point so clearly there... I was talking about the audio signal not having feedback loops in combination with modulation modules individually being more powerful, so there is just less need for a->b->c->d type connections overall.

I think the wires become more favorable when you start having more chained connections

[kmonkey]

Any news on this. Some ETA on Satin RE?

[EvilDragon]

Bazille and Presswerk are in the spotlight right now, and after that, Zebra 3.

Seems to me that u-he is quite wary of RE and they aren't considering doing any new ones, there seem to be limitations in RE SDK that don't gel with u-he way of doing things...

[Urs]

Well, nothing has changed - we have a Satin RE that's nearly ready for beta testing, but it crashes for reasons we have not been able to figure out.

Apart from Bazille and Presswerk our current project is "finding odd bugs and fixing them once and for good". In the meantime we've updated a lot of things and we've fixed a lot of bugs and niggles. We have not yet reached a state where we're happy to wrap things up. This is why Bazille and Presswerk - both technically finished - haven't been released.

Once this is over, we'll give Satin RE another shot. If it still compiles and if it becomes workable/debuggable then we'll follow through with it. If changes to the RE SDK require another month or two of work or if there are other factors of uncertainty, then we'll push it back until we can afford the expense.

Note that we have 10 employees on the payroll now, and our 9 REs together contribute less than 2% to revenues. We have to spend our time responsibly, and we have already lost a year or more just porting things to VST2 64-bit Mac, AAX (+ PACE signing), RE, VST3 (disaster!), signed AU, signed installers, Mavericks. We're fed up with plug-in format issues. We would like to spend some quality time with creative tasks rather than compatibility issues. Unfortunately RE has always involved tedious updates to the SDK and approval rules...

Cheers,

- Urs

[kmonkey]

Thanks for detailed info. I wish you good luck with everything..

[kmonkey]

So i am going to inject some life in this thread because i got response here from developer himself. It is a bit offtopic but it is related to this thread. Lately i am seeing quite a few badmouthing on porting VST to RE and i saw people mentioning and giving Uhbiks several times as an example of bad porting and some of them claim that it's developers fault (in this case Urs).

Here is just one example but really i am seeing this pattern randomly and uhbiks mentioned on several threads on ph forum https://www.propellerheads.se/forum/sho ... 525&page=3

Post number 28

"I hate to bring them up again, but point in case, uhbik. Sure, if props coded them they would be 10x as efficient, but that is the dev's fault not props, as he did sloppy ports."

I am aware users are making pure guessing there and i am aware of RE sandboxing and using more CPU cycles but i am finding it highly unlikely that Urs or his team which is doing ports - did this port so badly. Anyone from u-he care to comment?

By this analogy is it ok to expect Satin RE (once when released) having really bad CPU usage?

I am totally confused. By reading these threads i am under impression that Propellerheads have some kind of advantage when coding RE - which is giving them option to run RE's in more efficient way when compared to the rest of the RE developers.

What a pile of confusion...

[Urs]

It's very simple.

Uhbiks are written a code that directly translates to SIMD instructions (SSE/Altivec). Rack Extensions are compiled with a compiler that has no special instructions to do SIMD - we can't write any assembly whatsoever. Therefore our code is replaced by equivalent skalar instructions. It's up to the compiler to then generate efficient code from that. This is called auto vectorization, and it is supposed to work, more or less. In case of the compiler Propellerhead uses for our code I assume it's not its forte.

So yeah, we optimise the hell out of our stuff. We write assembly-like code. When this kind of code is not available on a platform, I guess this doesn't work so well…

I had hoped that this was resolved meanwhile… there's no point in doing any more REs if this doesn't work. Satin won't run as RE unless the RE compiler does a tremendously good job.

[kmonkey]

Thanks for explanation. Makes a lot of sense and i was expecting something like that because it seems perfectly simple to me that not all companies develop their plugins in the same way. It saddens me to see all these freak individuals making bold claims and making damage to your and other companies however we could never stop waves of stupidity. That's why i asked directly and anyone can read kinda "official" response from one of the most respected VST plugin developer. It's puzzling to me how a person or users which never in their life developed a single plugin or read a book about DSP - can make such comments about bad porting but like i said we can't stop that..

I hope Phead resolve this situation because you are not first one saying something like that.

Best luck and keep up the good work. Hopefully one day we'll see your Satin as RE..

[Urs]

Well, I've gotten used to all sorts of claims. There are magazine reviews that start with "u-he, a company famously known for their CPU intensive plug-ins" and there are even competitors who have no idea what zero delay feedback means in the context we're using it who say "but unlike theirs, ours is optimized". No wonder that users say the same. It's, hmmm, ridonkulous.

I've thought about publishing a few lines of our code that can shed light on the issue. OTOH I've got to much on my plate to deal with this right now.

[whyterabbyt]

It's puzzling to me how a person or users which never in their life developed a single plugin or read a book aboud DSP - can make such comments about bad porting but like i said we can't stop that..

surely it only takes a few weeks at KVR to notice the presence of an unduly large number of people who know absolutely nothing about software design, coding for audio, business, audio software, or the audio software business, but 'think' they have a unique level of insight into all these things that all established developers mysteriously lack....

[ThomasHelzle]

surely it only takes a few weeks at KVR to notice the presence of an unduly large number of people who know absolutely nothing about software design, coding for audio, business, audio software, or the audio software business, but 'think' they have a unique level of insight into all these things that all established developers mysteriously lack....

[ObsoleteAcc99]

So the fault is propellerheads compiler, and the plugins can't be written ground up in C++ or whatever RE's excel with to be super optimised?

i will take everything back if this CAN'T be done.. i am not talking about revenue being worth it vs time, I am talking about, if a programmer was given a task of making a uhbik plugin make the sounds that it does, but be an efficient RE, it can absolutely NOT be done, under the current SDK.. using ANY approach..is that correct?

cause i would then love to know how there are so many uber efficient RE's out there that have heavily sse optimised vst versions. Logic told me they rewrote them ground up as RE's.

[Urs]

i will take everything back if this CAN'T be done..

One can not write SSE optimised code for Rack Extensions.

instead of

vector float a = b * c; // multiplies 4 x 2 numbers at once

we have to write

float a1 = b1 * c1;
float a2 = b2 * c2;
float a3 = b3 * c3;
float a4 = b4 * c4;

This creates the same result (but obviously, the second piece uses 4 times as many instructions, hence runs about 4 times slower). The compiler can, if it's clever enough, automatically create the upper example from the lower example. This is called auto-vectorization. If the compiler did that, Uhbiks would run as fast as RE as they do in VST. If they do not run as fast, then it's most likely so that the compiler does not auto-vectorize.

- Urs

[ObsoleteAcc99]

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.

[ObsoleteAcc99]

let me put it another way.. why can't your plugins be written from the ground up as RE's to use whatever method is the most efficient for RE?. I am saying, if money was no object, is there no way a dedicated programmer could rewrite the uhbik's to sound the same but take every possible advantage of RE to make them specifically optimised for that format.. Meaning whatever language RE uses, like avasopht said, i think it's C++.

i am saying that this is the only explanation i can come up with for those who use heavy sse optimisations in their VST but only have a 50% penalty in the RE, vs around 1000% with Uhbiks in their current RE form. How did the others do it when i KNOW softube have super sse optimisations on all their products especially tsar and tsar is only 50% efficiency loss real world (more like 35% on one track, reason's own not very optimised multithreading accounts for the rest of the difference, which is why i have put yours at 10x and not 20x.. as it's 13 uhbik f RE vs 250 AU on my system).