Hi skijumptoes
This is a relief to me. I guess you are a native english man. If so, please avoid such phrases and metaphers. This is a multi-language community and i am not familiar with such phrases. Since there was no answer from you yesterday, it was the icing on the cake and really tilted me hard.
So again, in your own interest, avoid things like these.
That was a lesson i learned yesterday. I did a mistake to mention MCU and revised my statement. If you just replace MCU with “the vendor/company that was first to have a display and this display is supported by Cubase”, my previous posts would make more sense.
I dont care which company it is. My main point with that, was to explain that there are many things, where Steinberg dont need to reinvent the wheel, as it was done before since decades. It would be dumb to not use this resources and build the API completely new.
That is why i wrote “based” and not “tied” to MCU. Sadly every other person yesterday, jumped on to the MCU waggon and not to the thing i tried to explain.
Thats why i wrote that the API is capable of doing the same things like MCU, but not all. Some stuff is missing, but not to much.
You all said yesterday, that the MCU (omg again) uses standard midi communication. For this communication, the “hooks” to Cubase where made long time ago. Why you would create new “hooks”??? I would use these “hooks” from the past and put them one by one into the new API. Because API is not different from standard midi-communication. The API index is nothing more than these “hooks”. That is why i see so many, many similar things to MCU (or other vendors).
It is just sad, that the API index is documented like $hit in first place. Which only leads to heated discussions, where people hairsplitting, if API has similarities to MCU (or other vendor).
Since its poor documentation, people start to brew their own soup with their own scripts, resulting in code that reads different EVERY time and for EVERY script.
It is very easy to imagine, how that would look, if the documentation would have been readable and nicely explained, instead of putting something out that looks like the current state of API.
ALL scripts would be looking somehow similar (you dont reinvent the wheel, if you are smart).
Sadly, this opportunity is over and leaves “normal” people way behind, as they cant do something alone with the API, except to poke with it a little bit and spend precious time with trivial things.
Sadly, this pretty much dumb approach, splits the community, into people that are frustrated (like me) and to hyper-active fanboys that jump in and tells us (frustrated) people, how wonderful the API is working on their cheap-$hit controllers with absolute encoders (probably not having even a display). This is the point where i speak to myself “hey fanboy, you could do this decades ago with Generic Remote for your cheap-$hit controller. You simply dont need a new API, to do that. So piss off.”
Sadly, the hype around API is more worth, then crying people that cant get a simple LED to work, even after months. Dude, a LED… months… puking. How can i tolerate that hype? How is it possible, that a hyped API does not offer fundamental things like these?? No, you need to write it for yourself. SAD.
As long as you can create a jog control with JavaScript API code, it means you can not tell it is not possible, it just need work to do so. SAD.