Like I said…Im not a Cubase script coder but most of my life has been coding for other progs in parametrics
To simply allow the max value in the dialog to be >127 would (should) be such a simple thing to do.
If it has the maths to reduce the res, then its just the input validation to increase the GUI field and perhaps a slight amend to the algebraic phrase to handle >127
How important is this and how hard can it be???
Problem would be solved
No. The problem(s) will start there. It seems that Cubase does not handle well parameters, if more then 127 steps (coming from midi hardware) are involved. Feedback of that, as already mentioned by others here in the thread, is also problematic. Hell, i read even a stupid question from a developer, why we would need more then these 127 steps and what the fuzz is about the 14bit resolution all of a sudden. These guys are a joke. They do not even have the “creativity” to think about, what could be possible and what could we do with a 14bit resolution. Best examples are the EQs.
What you post here, was already posted months ago in this thread. How hard it can be? Marmor, probably. I dont know. Ask these bunch of developers. Ask yourself, why you spend money on such a DAW, that cant handle stuff, that other DAWs that cost only a fraction of Cubase can do. Ask yourself, why you should do the job and are forced to learn a programming language, that otherwise would be the job of the developers.
Maybe you will find a answer.
My post is actually after reading the history; normalised parameter of 0-1 the having a divisor applied. The divisor is held in the iMaxVal
The problem really is…there are not a lot of real Germans left…Hamburg particularly is the hub of brilliant designers that have been systematically poached particularly by the U.S… culturally the positions are being filled by programmatic skill reduction…thats what happens with irreversible depopulation.
There are a couple of interesting docos on it… Whilst the previous generation were tagged as over engineering everything, the new crew don’t have the same level of discipline or commitment and clearly exemplified in the degradation of so much eg even infrastructure in Germany…well it would seem.
Then you have the takeover by Yamaha…its clearly cultural and systemic
First your answer, is really offtopic and also simply not true. Not for germany and especially not for Hamburg. Emagic was bought by Apple, now would you say Logic is garbage? Or bunti clicki? The people of Emagic still sit here in Hamburg. Did you see Logic on a ipad? Compare that, with Cubasis?
More examples? Well, one half of Bome (Midi Translator) comes from Hamburg. Or check all the great Faderfox midi controllers…guess what, from Hamburg.
I cant say anything bad about Yamaha, they at least did integrated their hardware excellently and are in perfect sync with Cubase. I could only blame them, for the very lazy Steinberg devs.
Sure
Im only claiming observance from my perspective…history.
I started in v1.0 atari (yep im old) and it was all still powering along quite nicely until next version after sx 3 (c5?)
After this i began to notice the fragmentation indicative. I look at the brilliant atari stuff like IPS etc and they were complete tools.
Even in my past life as plc automation and architecture, we had German teams here (in Sydney office) and the unity, creativity and output was miles ahead of the Australian and U.S. teams
The current state of response from Steinberg and your pretty coarse but understandable comments only further the supposition that something is culturally wrong and is very diff to the product dev mentality of 15 years ago. NI has become the same if not worse…pretty sure its all budget and siltation related.
I didnt think it was off topic…and no offense was meant; just observance as to why issues of half baked releases with what should be easy fixes (or at least understood priorities from pro users like yourself)
Thanks and peace
It’s disappointing really, how development has seemingly descended into an almost ‘stop’ state. People are putting hundreds of hours into trying to make scripts for other users, which just seems wrong to not support those alone by fixing some of the very obvious bugs which has lead to most using workarounds.
It’s when you add in the users who can’t get what they want out of the UI side of things where it gets even worse though, especially after the promises made.
I still think the MIDI Remote is one of the standout features of Cubase, but like many other good features within Cubase, they never seem able to get things over the line. Just a few tweaks and additions is all people want, just to show some forward momentum and that this is an active development still.
It feels that Steinberg are in the game of making the largest changes for maximum appeal for paid releases, and quickly lose interest (or more likely lack of budget) to get those same features polished off and working for end users. It takes quite a number of revisions to get these things ‘right’.
(IMO) MIDI Remote should always have been a public beta so all these dicussions were had in the open up front.
I can only repeat myself. This thread is in the TOP TWENTY of all midi-remote related threads. If you dont count scripts for controllers and Cubase maintenance update announces, it is even in the TOP TEN (by views/visits).
By now you deserve a reply at least 
Please, help
I created script for x touch mini that scales cc messages to arbitrary values, as described here
But i observe strange behaviour
For example then i try to control channel Pre Gain with custom vairable in onProcessValueMethod:
var value = knob[i].getProcessValue(context)+ oldValue * 127. / knobTicks[i]
knob[i].setProcessValue(context, value)
where knobTicks[i] = 48 * 2 * 10
i get change in pre gain in 0.1dB steps almost in all range of values, as expected
But, then value approach 0.5 (0dB pre gain) cubase rounds it off to 0.5
so no matter what scaling is used i get jump in observed GUI value from 0.8 dB to 0dB
What should i do to solve this problem?
