Is it available by script only not in Cubase editor midi remote ?
Hi,
Yes, exactly. The keyboard is available via scripting only.
1 Like
@Jochen_Trappe I notice that the steinberg git repo has several pull requests (as intended at the start of this thread) but none have been assessed or responded too.
Will the steinberg git repo be accepted midi remote contributions or has that idea fallen away?
Also I note there is no update to the main branch even though there are updates to Cubase midi remote (again the intent at the start of this thread was the midiremote contributors should stay up to date).
None of this is hampering efforts by the community to create and share midi remotes (including myself) but would be nice to know what steinberg is doing.
Hi @robw, good question.
The github-thing is making me quite some headaches as MIDI Remote Scripts can only be developed properly if both coders and testers are having access to that hardware device. And that seems impossible to me due to the vast number of MIDI controllers out there.
If I approve a pull-request just by judging the “beauty” of the source code but not by testing its actual function doesn’t seem right to me.
Nevertheless we need to find a workflow that proofs the correctness of a script or, if not possible, remove the github-repo.
I am very much looking forward to having some heavy discussions about it.
Ahh yes, that is a problem. Solutions:
- Buy me all the necessary hardware and I’ll test it for Steinberg
- Perhaps steinberg can note the lack of warranty and checking etc, and accept community contributions that are clearly being used in the Forums.
- Give up the the idea of having PRs but do provide the base repo with examples so community builders can fork and build (like we are).
I think 2 or 3 would work but 2 is probably better at increasing the number of quality solutions (especially since having some feedback on the code would be helpful). Steinberg could perhaps do something to qualify community contributors/maintainers - like the ranking/moderator approach used in the forum.
That’s my first attempt at some ideas.
If Steinberg wants to pursue number 1, I work for gadgets quite happily 
Sure thing, but shouldn’t we buy you a warehouse first?
1 Like
This is not the first time Steinberg faces this question. It produced mixed results.
The most succesful was VST. Steinberg could have insisted on performing a quality control on every VST plugin before release. That would have seriously slowed down, if not even halted the success of this technology. Steinberg opted to let people release whatever they want but made them register with Steinberg first (to get the SDK).
MIDI Devices were possible to create by everybody but Steinberg did not add all of the user made scripts/files to their CDs. You see, this was in the 90’s. There was no internet to spread those MIDI Device files, so the installation CD would have been the best way to get as many of them out to the broad public. However, since no quality control could be done it was deemed to be too risky, bad MIDI Devices could have negatively affected Steinberg’s reputation.
Here we are again, year 2022, almost 2023.
I would propose to put a big disclaimer on the site stating that scripts are not quality controlled by Steinberg, “use at your own risk”. Use your site to encourage other people to write the MIDI Remote scripts to get this technology as widely used and accepted as possible.
If your customers want to help, don’t stop them but rather guide them.
2 Likes
Eyeing Cubendo from the sidelines from a competing DAW, but this kind of thinking is something that would really convince me to jump ship. (That and second pass rendering for game audio! Pretty please with a cherry on top.)
The major appeal of open source repositories is that anybody can submit a pull request and potentially improve something, or bring a problem to the attention of someone who can fix it, even if that’s another member of the community.
Niche/obscure solutions are obviously something that Steinberg themselves are never going to be able to support in their entirety. Likewise, metadata on the GitHub repository of Verified Working by Steinberg would be good to have, that way they can be easily sifted through for people who have no time to waste on potential issues.
Native Instruments allows users to upload Reaktor ensembles to a centralized platform, but there’s no guarantee they work. Doesn’t seem to bother anybody. Nobody blames Apple or Google when a third-party app doesn’t work as expected.
Obsidian (a Markdown note-taking application) allows “Community Plugins” and updates to them from within the application itself. If scripts could be updated (and likewise rolled back to prior versions in case something breaks, which is easy with git) via an in-app git pull just like Obsidian does, that would be extremely cool.
Steinberg stands to pick up a lot of users from other DAWs if they don’t need to setup each piece of gear again.
Whilst users can indeed publish their own elsewhere, that lack of centralization sucks and feels very messy, which is what’s great about Google Play, App Store, and what NI does with Reaktor. IMO, if users are confident enough to use GitHub, they’re probably power users who don’t need their hand held. Just give me the data in a centralized place. If I find a script that’s broken, I’ll fix it, or work with the manufacturer or other contributors to figure out what’s wrong with it. If Steinberg can’t give users the tools they need for obvious logistical reasons of verifying that they work, it makes sense to centralize the community’s work and stating what’s tested as working.
Convincing manufacturers to support Cubendo in this way makes not just their product very appealing, but also Cubendo. Give them a Works with Steinberg badge to slap on their marketing materials.
2 Likes
@Jochen_Trappe please do not repeat earlier mistakes which force to make parallel user-built forums to get Remote Scripts.
As a software dev I understand the underlying issue, but have pretty much questionings:
- The function to build MIDI Remotse Script is there. Which was the original use-case/expectative? (e.g.: every user technically experienced or not will waste hours in building his own remote-script?
e.g.: hardware producers willl write the scripts for the people?) - The reality is that with a generously thinking only a 5% of all users will even take themselves the time to make a Remote Script for their Hardware.
- Let’s assume that Steinberg can’t and will provide all possible scripts. They could, but won’t
Which is the sense of maintaining a function which is clearly not supported (by a person, a forum or as thought out: a github)
So taking this as a base and trying to find solutions:
-
What speaks against a clear disclamer when a script is user-built (marker) and not steinberg-supported? From a icon to a watermark?
-
In the long term wouldn’t it be more attractive for a user (take me as an example) to write a script if he/she knows that others will benefit from the deed and be able tu use the MIDI Remote Script? I mean nearly every software is built-up at least of one or several public-domain software packages?
-
Do user even expect the MIDI-Remote Scripts to be 100% complete or perfect? Specially if they know their origin (See 1: marker in the Remote Script). Another user mentiones 3rd party VSTs
-
By providing a common platform, sharing of MIDI Remote Scripts is promoted, by this you indirectly promote that scripts will get (user-based) improved when they’re incomplete or contain a nasty error/issue. This enhancements could then easier get shared again (pull request), thus the quality of the script would automatically and constantly improve
-
So we have a common platform and now come the Trolls:
a) → When an issue is identified, switch back to the working version and block the Troll
b) Instead of improvements people begin to mod the interfaces
==> I don’t think there would be many misbehaving, it hasn’t been on earlier forums were controller scripts where exchanged. There is a mutual guiding and respect at this specifical level, I like to believe, otherwise mark mods as such
==> This will give you most probably less work than trying to test or verify every new script. -
Now Steinberg can think, well why not share the risk, Controller Hardware producers should offer the support!
=> well they usually don’t, so we end up in some other forums or private webpages where we share links to handy remote scripts always hoping that the original author may have a complete script or will be updating his enhanced/improved version anytime soon. It has been since the 90s, we’re now in 2022
Please do not overcomplicate things… At the moment the script editor is something like: Yeah, it would be pretty cool, but I don’t have the time (or knowledge)
and like this a very cool & helpful improvement in Cubase losses it’s worth & sense
My suggestion would be: Keep on using the github and simply accept al incoming Pull Requests… and learn on how to optimize everything from there on (probably it will be less work to deal with trolls etc. than to trz to verifz everz user submitted script), and: Use a true false marker to differentiate Steinberg supported MIDI Remote Scripts from user-built ones. Don’t desincentivate users/clients to helop, but do all you can to incentivate to build up a huge MIDI Remote Script Database (only then the idea of the Remote Scripts begins to make sense)
These would be my humble 5 cents
1 Like