Are your posts AI generated? Just curious. I guess it would be appropriate for this topic.
4 Likes
There are some logistical problems - potentially - with opening things up too much.
- Creating bugs/problems/crashes that aren’t a cause of the native/un-modified program, of which many users who download/implement these out-of-house development features then report them as if they are core native software problems. This could become exponential when Steinberg releases new versions of which might break some of these extensions of which were previously working, further confusing everyone
- While Steinberg could promo this new open-source coding as a feature in itself, the features that are developed through it Steinberg can’t really advertise as their own.
- If Steinberg has objectives/intent to push Cubendo into becoming an industry standard, there is a benefit to the software being universal among users, rather than completely altered versions from one studio to the next.
- Everything goes through legal these days. There’s a lot there to consider with coders contributing code, AI, whether Cubase is to be considered open-source, etc, etc.
- It’s also going to take development resources to develop and maintain. Unless Steinberg add resources to tackle this, then it is going to take resources away from other stuff on the roadmap… What is being gained for what is being loss?
I think a good middle ground, is inviting knowledgeable people such as yourself @Glorious into the Beta program, and sussing out these ideas and their implementation and testing them, and also perhaps Steinberg putting a callout to coders and developing their GitHub community a bit more.
But perhaps also, there are elements of the program that could be opened up more, I’m not against it entirely. Hopefully this thread and conversation itself, gets some things moving - whether in house or not.
4 Likes
That’s nearly 1:1 what I wrote above, Glorious.
I wrote this: 
Of course, to enable interaction between external AI and the DAW, further steps (API functions, etc.) would still be needed. We’re not there yet, but to get there, we first need a standardized data format …
I also made it clear that DAWproject, as a data format, isn’t the solution for you just yet.
1 Like
Run your post through AI again but this time tell it reduce word count by 50%>>>AI is overly verbose.
1 Like
It kind of makes one wonder whose ideas are being debated…
I don’t really find the idea of AI improving the mix all that spectacular. I could easily imagine something like that being available in Cubase 16 at the latest, and then real sound experts would be involved.
They don’t have to market it as their own, they only need to market that it exists.
I think you or I are misunderstanding this.
My impression was that by creating an open scripting API people would add functionality by creating code outside of Cubendo. Therefore it’s not change by it. There would be no case where you would have “altered versions from one studio to the next”, it would all just be “Cubase” vX and then studios might choose to run different scripts outside of Cubase which then hook into Cubase and trigger functionality.
I think it will be a net gain, not loss.
Take the time it would take to develop this once and then maintain it and subtract the time it would take for Steinberg to develop all the scripted features added by 3rd parties.
1 Like
A company like Steinberg probably isn’t going to market/promo exterior scripts, but you never know. My point is, if they are creating the scripts/features people want - they can market/promo that.
I’m understanding.
It depends on “how open”. It’s still I would say overall more beneficial for things to be developed and integrated in-house when it comes to developing a universal piece of software, at least as much as possible - so that what is advertised by Steinberg, is what all users are getting, benefiting from, and exchanging, without having to download external scripts.
I’ve definitely seen some Reaper scripts/capability I wish were in Cubase, such as
nvk_VARIATIONS - Instant Variations in Reaper
and
nvk_CREATE - Instant Sound Creation in Reaper
But to me, these a features Steinberg should just implement.
Maybe. I’m not sure. Reaper was built with open scripting very early on. I’m not sure how much work it would be for Steinberg to open things up enough so that someone could create the two scripts I posted above, vs just creating it themselves if they did.
I’m not against it, but skeptical of the gain vs loss. Plus I’m tired of seeing fake composers.
1 Like
As a guy who’s never got into post production, I’m very interested in learning what are some functionalities needed and not supported by the MIDI Remote. Could you please share for example an FR link, so I can have a closer look? From what you say I gather that your request is not (just) about remote controllers, but goes deeper maybe?
At one point in the past I was almost ready to create a post about this very interesting object. But then I thought that Steinberg could probably provide a more accurate guide, so I hesitated. Nevertheless, I’m open to discuss this matter in a dedicated thread. In the mean time, note that I’ve shared snippets here and there, if you set the “makeDirectAccess” as a keyword for searching this forum, you’ll find most of them 
Could you please share some details on what you’re after?
Steinberg has the SKI remote for communicating using Bonjour. At one point I’ve “sniffed” in order to see what it can do, but I didn’t find much that the MIDI Remote cannot already do. One thing that it can’t and SKI can, is sharing the parts’ positions/lengths of the tracks.
You can maybe check this video out: https://youtu.be/nt7kQv2zMJo?si=_pZ-_4r5cVbWbWnm&t=427
I think in large part there are things that Nuendo offers via the Project Logic Editor for example, but where it fails is that a good way to string things together in a coherent way is lacking or it becomes impossible because some functionality is not exposed to the editor. To what extent MIDI remote would help with that I have no idea.
My request is really related to opening up scripting support in general, not directly related to controllers. There was a thread about it not too long ago:
1 Like
I feel like what many users keep coming back to is that the basics of the DAW needs to be covered and functioning well. SB is responsible for those basics. For the longest time we’ve expanded both quality and functionality by using 3rd party plugins for example. It ranged from better quality reverb plugins to roundtripping to iZotope RX for spectral editing. So the core DAW is what they provide and it needs to be solid.
Because of this, the strategy is probably quite reasonably to aim for the center of the market where most users are and cover their needs.
Now, I think that we’re actually stumbling upon a situation where both “the masses” and edge cases would benefit from scripting being available. For edge cases it’s obvious - the return on investment for SB to develop those functions is low. Spending resources on developing something that 100 Nuendo users would use isn’t going to drive sales. Therefore, if just 1 of the 100 was able to script it and share it there’d be 100 happy users. For “the masses” the argument is different: among all users there will simply be too many requests to process and spend time on, and even within that center/median of the market there will be too many requests to satisfy. But if “the masses” for Cubase for example is 10,000 users then maybe 100 can do reasonable requests that 50 can code (with the help of AI or whatever) and that can be a multiple more satisfied requests than what SB can accomplish with fewer coders and with resources that also has to cover bug fixes and the basics.
I still think it’d be a net gain.
And on top of that we have the potential for 3rd party businesses to do it for money.
Just to add something;
I was just playing around with a way to color selected tracks as well as moving them into a new folder. I can do both, but I can’t also get the folder colored the same without stringing PLEs together. Now, in order to make it easier I thought I could simply use “Project / Select Track: Add Prev”, but it turns out that it’s wildly inconsistent. Sometimes with the tracks selected it will correctly select the folder above it, other times it will not.
This seems like a perfect example of something SB will probably never fix (because they aren’t fixing more important bugs) but where maybe a custom script might do the trick instead.
In other words, perhaps there are “workarounds” that can be coded to the point that the technical aspect becomes transparent to the user, and things just work as intended.
Can’t you just use ‘Up’ to select the folder?
I wanted to have it selected along with the selected tracks.
It doesn’t really matter, I was just trying to make the point that we run into situations with PLE where a different, better solution could be had if a 3rd party could script it.
What is the need to have them all selected? Just repeat the colour command.
-Add tracks to folder
-Colour
-Up
-Colour
@MattiasNYC oh yeah, there’s also ‘Add Up’
-Add tracks to folder
-Add Up
-Colour
Ok, I’ll say it again; we sometimes run into situations where the is no solution, Steinberg probably won’t make it happen, 3rd parties might. This example isn’t the point.
I didn’t exhaust the options to make this work, but I have run into other ones that are annoying, like for example naming multiple tracks from a list located somewhere by replacing default template output bus names with network-mandated nomenclature that resides in a separate document. So far I haven’t found a way to make that work in a simple fashion. I’d rather not set up a million PLE’s to string together just to make this work and then have to edit each and every one if there’s a change to the text document.
Feel free to let me know how to do that if you know how to.
Just do this: Go look at how Pro Tools have 3rd party implementation of this. https://youtu.be/nt7kQv2zMJo?si=_pZ-_4r5cVbWbWnm&t=427
Holy poughkeepsie $400 a year? Thankfully we just have Cubase export.
Some of the AI stuff was interesting, although I felt like I’m quicker with some stuff rather than typing in a prompt tbh. Cool, but not direly needed, a key command/PLE is still quicker in some regards. Lord, I can see future interns typing stuff into prompt instead of memorizing the key command 
Another conundrum is, Steinberg is selling multiple programs where other companies are not… ie, if people can start scripting WaveLab and Dorico features into Cubase, it could hurt those sales.
I think there’s sort of multiple elements to this conversation:
- External scripting
- Features we want that we should get Steinberg to just implement
- Improving MIDI Remote
- Improving P/LE
There’s a lot to suss out there. We can dream about external scripting which they may or may not do - but perhaps, we should also discuss how these other elements could be improved as well. There’s a lot of ways PLE could still be improved… not only in the action/target scripting but implementation like having it be able to be in the Right Zone.
1 Like
I started a new PLE group suggestion thread over here, to separate but maybe also include what is here in this thread… feel free to contribute:
New Project Logical Editor / Logical Editor Improvements - Cubase - Steinberg Forums