UHE Uhe Ubik A Re Rack Extension Bug Propellerheads reason 7

[Naviretlav]

implying u-he's programmers aren't as outstanding as that one guy?

just self plugging for some job brokering percentage?

not sure which one is more inappropriate...

I don't have any benefits from this, other than fixes in the product.

Sorry, we currently can not compile Rack Extensions that do not crash Reason. We do not know what's going wrong, but we hope that whatever we do to fix our AU/VST/AAXes will also help in this case.

So our first priority at the moment is to get our plug-ins back up into stability, then prepare to do some RE work. For latter we might also need to wait until our new developer is up and going. He starts in May and he replaces Clemens who did the REs and who left us in December.

I'm simply to busy to do this by myself, and the fact that Clemens left us is very unfortunate.

He clearly said that he don't have the time to take care of the REs , especially since someone left the team, so it would be wise to hire someone new just for this short task.

[Naviretlav]

I'm sorry, but:

How f**king stupid can you be? Really?

I don't see anything wrong about my suggestion, and please don't search for it on purpose.

I really love most of the UHE RE plugins, especially the P and G. I use them all the time, and they are one of my favorite REs. We all know that coding REs is not that easy as it suppose to be, and I really admire his work. From conversation above, I understood that he is just busy with other projects and live issues. If time is the only obstacle, than hiring an extra man for help could be a good solution. And I suggested him one of the best that he could find. There is nothing wrong in collaborating with other developers.

I'm sorry if I said too much and it offended anyone, that wasn't my intention.

[NadirToZenith]

i do not have any benefits from this

sorry for misunderstanding, mistranslating perhaps, your benevolent intentions...

one would think, however, that programmers, developers, are in the know of each others' capabilities, thus if, when, one's work is required, one is contacted then hired.

hope no offense is taken, wish you all the best...

[Urs]

Yeah, not my favourite timing, but still a valid request.

Thing is though, our code is *complicated*. It does not compile to RE out of the box, we use pre-build scripts to adjust 100s of sections. These scripts are out of date atm. We furthermore need to patch the RE SDK to include plug-in specific preprocessor defines and includes. There's a lot of workarounds needed and a developer has to learn a lot about how our framework operates.

There's no way I'm going to talk someone through this, as there's no way I let anyone try this with our code on his own. The only way to ever go back to RE development is if and when we can make the time to do so. The chance for this to happen rises with the less amount of time that's required. If, for instance, PH would miraculously allow for a certain standard feature that we would like to have available, then a recompile with a fix would be a piece of cake.

- Urs

[Tronam]

Can you tell us if switching from "open" to "small", wiggle "HF Range" knob, and go back to "open" solves the issue?

I was curious to see if I could reproduce this bug, but after downloading the demo and spending some time with it over the past week I haven't had any success in doing so. I'm running Reason 7.1 with Uhbik-A 1.1.0 on OSX 10.8.5 and I've tried a variety of Dry/Wet settings, random patches and even just the initialized state. This includes closing and reopening song projects, loading combinators, quitting the program before opening and other variations. In all circumstances it loads and sounds identical, precisely matching the knob settings. I'm not sure what the difference could be.

Tangentially, it has been ages since I tried out the VST version of Uhbik-A and I totally forgot about its remarkable "transparency". It's a beautiful sounding reverb, very easy to program and nicely complements the various other flavors available in Reason. It's also 3x more CPU efficient than TSAR-1 on my system. It was well worth the purchase. Thanks for bringing it to RE, Urs.