I think most of us here who are pro AI integration are not proponents of ‘fake music’.
I’m interested in it as a management tool, and I think it has real promise in this area.
But I do understand people’s anxiety and confusion.
And who’s paying for Claude’s subscription?
It certainly won’t be me. 
I think most of us here who are pro AI integration are not proponents of ‘fake music’.
I’m interested in it as a management tool, and I think it has real promise in this area.But I do understand people’s anxiety and confusion.
Well, I’m in the same boat. I’m wary of AI for certain things, but for integrating functions, I think it’s the future.
Thanks to Gemini, I was able to create a WPF floating window to control hundreds of macro functions from PLEs and Cubase functions from my 24" touchscreen, and I don’t know how to code.
With a lot of patience, good instructions, a bit of trial and error, and some backtracking, it worked, and I didn’t think it was possible.
So I bypassed that by not using the API and the script, but the C# XAML language of Visual Studio with Gemini.
I wanted to show something which I think is based on scripting and makes a point I think I made earlier, namely that 3rd parties can provide solutions to things that users want that are missing.
The video begins by stating that there is a problem with Pro Tools in that only one session (i.e. .cpr/.npr for us) can be open at any given time. For us this is not a problem, we can have multiple ones open at the same time. However, watch the video to see the added functionality this provides, beyond what we have:
So what’s interesting to me is that here is this thing that PT is missing, and rather than having Avid develop that a 3rd party developer went ahead and just got it done. And not only that, but whereas we were able to have multiple projects open at the same time Avid - via the 3rd party developer - didn’t just catch up, they went further by allowing searching of files, auditioning, transfers and more.
This is exactly why opening up the software would be good. Instead of making posts with “feature-request” tags where we never know if they’re read or if anything is in the making we could hypothetically just get it done ourselves. I could imagine anything from better AAF input/output to a speech-to-text system that’s more useful to dialog editors, and more.
Interesting. Watching the video, I’m not sure if an embedded in proTools API was used, or it’s a reverse engineering case, cause I see the external app opening the project files. Reverse engineering could work too with Cubase project files, I just don’t know if other guys went into it.
That being said, an API for controlling everything in the project would be most welcome obviously.
In 2022 (if I remember correctly), Avid has released an SDK to access core functions of ProTools. The mindset is to help 3rd parties develop tools to enhance ProTools features set. They did the same for Media Composer. Steinberg should definitely do the same. The downside is that some of the tools being developed are not free. In other hand, some of those tools would not have been made, so the cost is an acceptable tradeoff.
Exactly. I can absolutely see a 3rd party develop for music-specific functions and another for post, for example, and then you pay if it is worth it. And in fact, I can see how some tools may be beneficial mainly in a large-scale high-volume situation, and if you or your facility gets a job that lasts 6 months for which you need this functionality even a monthly subscription, as “controversial” as that is, would make sense.
The fact that Steinberg could spend less on R&D on certain areas as well as on support of those and still users would get that functionality… Can’t compete because funds are short? Let 3rd parties do some of the heavy lifting. I could be an idiot, but it seems like a no-brainer to me.
Note that Steinberg released a similar SDK ages ago, but a) it’s no longer available and b) even if it were, it was not for conventional users but rather for 3rd party manufacturers.
I don’t see it as a downside. If I can offer to you something important for your workflow that may have been requested from Steinberg but for one reason or another is not getting implemented, I think it’s worth it.
This.
It is 
I agree. And I think that in some cases you can even put a number on things. Granted, it presumes an “all else equal” scenario a lot of the time but it can make sense. For example, what if we could set up a large amount of offline exports of mixes across multiple projects and have that execute as a batch, automatically. If you work a 10-hr day and your exports take another 2 hrs, then you either sit around while that’s happening (because you have to switch projects) or you set it up to execute overnight “after hours”. I think you can put a number on those 2 hrs. If you’re an individual and change for example $50/hr then you just saved $100. And so on.
True.
I know this is just an example, but specifically this one doesn’t even need an SDK. An automated daemon is usually enough for such tasks. Out of curiosity I will give this one a try here
The only potential issue I can imagine (besides the actual development) is that if a 3rd party company added functionality, that they sell for money, can Steinberg still integrate the same functionality for free later on?
It would seem so, to me at least. I think the question would be if they’d be responsive to inquiries by 3rd parties before they start development, and if they end up developing something a 3rd party releases first, would they simply shift gears and focus on something else instead?
I mean, to me it would seem like 3rd parties doing things like this is a resource for the brand and it would be bad if they undercut them after the fact. Therefore, good communication should make it possible to alleviate this.
Please let us know how it works out, and also how it works technically.
First, let’s not that it’s not really free, most of the time it will come with a paid update
This alone means that if I have a set of utilities which for example now works with CB15, and in the long run Steinberg implements the very same set in CB18, but at the same time a CB user doesn’t need other extras provided by CB18, it won’t be of a harm to the developer, as long as the user is happy with CB15 and the extensions provided by me.
Next, all devs of such utilities (not just in the DAW business) out there are totally aware of the fact that their job may become obsolete in the near or less near future. When you create projects of this type, you have to focus on their stability but also on providing more and more on the run. This will most of the time give you an edge.
Finally there is the case of how the very same thing is implemented. I will provide a not very accurate example here, but it reflects my point of view: With CB13, Steinberg implemented the TapTempo function. Cool. A year before that, while in CB12, I had implemented tapTempo for my MIDI Remote Surfaces. I have them shared for free in the forum, but let’s pretend for a moment that they were paid. My algorithm, contrary to the one Steinberg used, counts infinite number of taps. This makes the BPM setting a bit more accurate. So, a user with my implementation wouldn’t complain, at least not much. A NEW user though, could still compare the two algorithms, and if in need for bigger accuracy, would go and buy mine. And/or complain in this forum using an FR, totally logical, still, if in real need, he would pay
I don’t see it as a downside either, but there’s always someone to argue that those features should have been provided by the DAW’s developper and that it should be free or part of a paid update.
Adobe created an API for their menus so that now you can control Adobe apps from, for example, Claude.
Steinberg needs to do this ASAP. If they don’t do it, people will move to the DAW that allows this. If one DAW let’s you tell it what to do with high-level voice commands and another DAW makes you pull down menus and remember key-commands, it is obvious which DAW will win in the marketplace.
Steinberg, please wake up quickly.
We do not want to see you go bankrupt. We like Cubase. AI integration is the way to save it.
Yeah, well, you know, that’s just, like, your opinion, man.
Related to the topic, Ableton has just announced Extension SDK.
It would be useful to have an sdk/api to be able to program your own ui/ux on top of Cubase to use over time. Ableton extensions are for one-shot operations, but Max for Live enables the programmability. This doesn’t really have anything to do with ML-models in particular. It would just be really great to be ablento build your own workflows and experiences irrespective of how you program them.
Aw muffin, you won’t be able to use your computer skill to corrupt cubase into a frankenstein music monster? What would steinberg do? It would be a tragedy.
You realize six thousand years of human history; the people made beautiful music with a basic instrument and their voices. Singing a new song, making a joyful noise. When did anyone ever need a bot to strum on the guitar for them? And why would they want it to?
Adding auto-generation to a daw is abusive to the very core function of it. And abusive to the spirit of music. AI users have demonstrated that they don’t understand or care to understand music, so stick to what you understand: computer programming.
…
All this machinery making modern music
Can still be open-hearted
Not so coldly charted
It’s really just a question of your honesty
Yeah, your honesty
One likes to believe in the freedom of music
But glittering prizes and endless compromises
Shatter the illusion of integrity