How’s it possible without getting Process Value for Effect Type which is idx*2*(2^-32)?
Yes, there have been discussions about this subject in the past in this forum as far as I can see.
Here’s my take, and I think that is something partially (?) proposed by @mlib as well, if I recall correctly:
Since MIDI Remote can deal with scripting, a way for the whole process to be less “expensive” for Steinberg, would possibly be to use this as a base for further development.
For example, in MR we have binds to commands. That’s cool. However, there could be an improvement by allowing setting up PLEs and MLEs on the fly.
Pseudo code:
PLEObject.initialize
PLEObject.addTarget("Media Type","Equal","Audio")
PLEObject.addAction("Track Operation","Lanes Active","Toggle")
PLEObject.execute.transform (or select/deselect/delete)
The thing here is that even with the “slow” MIDI communication protocol (which is vastly faster when we’re talking about virtual ports) an external app could perform this type of edits without an issue.
At the same time, there’s too much room for additions, when it comes to parts/events and their properties exposed to the API. Currently MR is mostly about channel objects/properties.
As a side note, some time ago I’ve created a tiny “Commander” app. It’s mostly for executing commands/preferences by typing them in a search text box. This app was taking advantage of the MR in order to pass the proper commands. Have a look here:
It’s trivial (to me) to include an AI bot and figure out what user types and perform. But again, Steinberg needs to expand on this, and the MR seems like a good place to do so.
Totally agree.
Please be patient, I’m planning on providing a snippet on this, in a dedicated thread.
The workload is different for everyone. My “old”-ish computer is now starting to slow down during exports because of new plugins I’ve added to my template, and I’m starting to get more series that now put me in a spot where I actually have to think about when I export jobs.
It was mentioned almost in passing I think, but one feature that stood out to me was the ability to stack exports across sessions (“projects”). I haven’t used that software yet but the way it looks to me is that I could select all mixes, submixes and stems required per project and then trigger the export which would have the software literally open/export/close each project one after another. With a function like that I could trigger the exports and then either go to bed or go grocery shopping or whatever while it’s working.
Just for reference; some of my exports are on a 40-min timeline and in the past took maybe 8 minutes and are now double that. If I have 4 episodes to export then that’s an hour, plus all the open/trigger/close operations required.
$400 probably doesn’t really buy me a faster computer, but it does buy me the ability to do this while I’m doing something else.
Sure, but there are a few things to remember:
First, you can use a microphone instead of typing. For post-production at least I’m foreseeing more usage of a mic while working as a one-man-shop for some jobs, because I have started to re-record some troublesome dialog and then use a clone to change it back to the character’s or interviewee’s voice, meaning a mic is available by default. Plus many computers are equipped with a mic. So, mic is faster than typing, but slower than a key command of course.
Second, as you point out key commands will be faster in some regards, but that presupposes that you have already put together the command structure in the PLE and/or as a macro and tied it to a key.
Third, one “issue” I ran into years ago was the fact that you can run out of both convenient key locations (i.e. cumbersome combinations of keys in the “wrong” place) and actually run out of keys to trigger your commands with. This is a solution, just like using other 3rd party software like Eucon for example.
Lastly, yes, “interns typing stuff into prompt instead of memorizing the key command” is a thing we can laugh at as long as it’s simple stuff like keys for event fade or whatever, but over the course of decades you’re likely to a) run into a set of commands that’s just hard to remember because of how large it is, particularly the less used keys, and b) your memory might actually start to go as you get older, and c) typing isn’t everyone’s bag.
1 Like
haha yeah… I’m already there and beyond… Used AHK to get more more commands. I was really Steinberg was going to implement ‘Hold Key’ logic for Key Commands.
I’m planning on building an OSC tablet PLE controller soon.
As a developer, Codex, Claude Code, etc they edit the local content directly, they don’t drive the local developement environment such as VSCode with an API. Yes, they run command line tools, and MCP servers do call external API’s, but the local file editing is direct. There is a huge opportunity for a new DAW vendor to truly make a readable DAW file format that operates as the main file format, not some open import or export format, so AI can edit this file or files directly. Then this DAW updates it’s GUI from the changed file rather than use an API to have the DAW change it’s binary file format. Then the user can tweak manually and save to that file format, and round and round it goes. For audio clips, just like current DAWs have wave data files for drawing, there could be AI spectral analysis extracts alongside each wave file for the AI engine to analyze. Small command line processes for permanent audio manipulation to generate new audio files, and the same for midi. The problem is current DAWs need you trapped in their ecosystem financially, so this will be a David that slays Goliath.
2 Likes
What? It should not read files. It should interact directly with cubase.
Why, does Claude use Excel to read and edit Excel files? Though, that is not a great analogy as Claude uses python to edit excel files, and it’s unfair to your point.
I’m not talking about Cubase in the above example, I’m taking about a future daw that use a text file based description of the project, where the token stream can be trained on, so the AI can work directly on the file format. Where the daw file format generation itself is pure token prediction grounded in deep understanding of the syntax and semantics. Then the DAW sees these changes and updates it’s GUI.
The future of AI in a DAW will not be based on file manipulation. But a AI might be able to do a good project conversion between different DAWs.
Have you worked directly with Claude Code or Codex in the last 2 months? I would have said the same about Coding a year ago. This article is a good read. https://www.nytimes.com/2026/03/12/magazine/ai-coding-programming-jobs-claude-chatgpt.html
1 Like
Yes. More than I would like. I hate it, but it is hard to ignore what it can do.
Thanks for writing this. Earlier in this topic someone started to talk about DAWproject and I didn’t understand why. Your posts answered that question. Now I have an idea what they were aiming at.
You’re welcome. I actually tested Claude today with DAWProject syntax, and it is able to describe the syntax and write examples, so it was trained to some extent on this syntax. Bitwig describes this as an exchange format and not intended to be a true project description. I also don’t like the monolithic nature of DAWProject, it seems like a track per file, and note region as a file, would be a more modular design.
Are we really talking about DAWproject as an actual solution for AI integration?
This assumes that:
- Every DAW will continue running without issues, when a bunch of third party programs accesses the Project File and manipulating the project’s data in real time. (Implementing this alone sounds like a complete nightmare, and ensuring that this runs smoothly without frequently corrupting the entire project sounds completely impossible to me)
- Or we save and close the project, every time we want to use AI to make changes. (But let’s be real: this is unacceptable in terms of workflow)
- Also, this assumes DAWproject becomes the “main” Fileformat for all DAWs, (not just an export format) which means it needs all functions and parameters that every DAW has right now (for Cubase: things like expression maps, Modulators, Rack Instruments, etc.) They all need to be accurately saved by DAWproject. (Or you tell the users, that features they already use, are now taken away, because it’s not compatible with DAWproject).
And for the future development of all DAWs, this is a huge liability… Steinberg has a cool new idea for Cubase? …no better wait 10 years until there is a way to accurately save this feature in the DAWproject file format. DAWs being contrained by not being able to control the File format in which their project is saved, will absolutely kill innovation.
I don’t think AI implementation via DAWproject is a realistic path for the future. The hurdles that need to be overcome to make this work are gigantic.
No, it was just something I was experimenting with as proof of concept. The concept discussed, is whether future DAW AI should read state and make changes directly to a project file versus only read state & make changes through an API. The latter is most doable now for DAW vendors, for example Cubase could just release an MCP server for Cubase. Probably the answer is a combination of both. No, the project file or hopefully “project files”, does not have to be a universal DAW standard. And yes, good point, to your comment of saved state, it’s true if the AI agent depended solely on the project file, then any non-saved project file would need to be saved. That’s one reason I’m envisioning the project represented by a large collection of small files rather than a monolithic project file, similar to the way programmer’s code.
Ok, I can kind of see your vision. If Dawproject moved to collection of smaller files, then it could be part of the solution of better AI integration.
But even in that world, where .dawproject changes to being a collection of smaller files, Steinberg has to release an MCP server or figure out other ways to massively expand their API capabilities, if they want to stay competitive in the market.
No, DAWproject is just only a first step in the right direction.
In very simple terms, a DAW is structured something like this:
raw data <> structutal data <> internal layer <> DAW UI
Bitwig and Studio One had offered that:
raw data <> structutal data <> internal layer <> DAW Import/Export <> DAWproject data
Steinberg has continued this and now offers this as well. There could be various reasons for this, such as business considerations, for example, to make it easier to attract Bitwig and PreSonus users as new Cubase customers, or to proactively address a trend that is maybe unstoppable. It doesn’t really matter why. It’s not certain whether ProTools, Reaper, etc., will follow suit, but there’s a good chance they will. There are still gaps that need to be filled in DAWproject, so a version 2.0 might be necessary.
Until this point, DAWproject would only be used as an universal data format for storage.
But then DAWproject would be sufficiently established that, as a standardized format, it would provide an excellent basis for further developments.
One could be implement DAWproject as a standardized virtual layer over the various proprietary data models of the DAWs like this:
raw data <> structutal data <> internal layer <> DAWproject layer
Of course, this would then also require standardized operability like this:
raw data <> structutal data <> internal layer <> DAW UI <> standardized control API (= another major task to do!)
Only then would we reach the point where AI could be integrated into the world of various DAWs in such a way that it could take in realtime control of music production on a larger scale like this:
any DAW data <> DAWproject layer <> MPC-Client <> AI application as MCP-Server <> standardized control API <> any DAW UI
In this context, DAWproject is only a layer; it does not function as a file format, but as an interface specification to enable universal exchange with an AI.