Thanks very much!
I hope the developer is doing OK. Don’t understand why the web pages would all be up, but the d/l link down.
Como
I think NI should have an Cubase-option for drag’n’drop. Easiest way.
Steinberg could have “3rd party drag’n’drop” support but I think it will be harder to implement for them than it is for NI.
A statement from Steinberg on this matter would be soooo welcome.
Hello,
Please have a look for the posts of Arne Scheffler.
If you inspect drag-n-drop buffer while draggin from MediaBay in Cubase you will see that it contains plain text XML instead of file pointer. That’s the problem.
The real problem is that we provide many more information than just a file pointer. If you drag a range from an audio file you will see that we add the sample start position and the length of the range. This is just not possible when we would only provide a file pointer. And it’s not only the range we add to the drag, there are tempo, key and maybe other information we add to the drag.
But as earlier posted, nearly all plugin developers should know me and they know how to contact me. So if they are willing to add support for dragging from Cubase to their plugins and need help they should just contact me.
Cheers,
Chris
As I said earlier 
That’s the way standards a established… Instead of providing compatibility to established standards…
Btw, has Steinberg already contacted Celemony for their ARA interface?
Or will Steinberg keep ignoring super user friendly ways of working?
Thanks for your reply Chris but the immediate answer to Arne’s comment that you linked and the rest of the thread make it clear that Steinberg is very stubborn on this. Why not have an option like Aldanor suggested? Evereryone would be happy.
Why this kind of corporate pride of excluding every other standard? I can’t use sinevibes plug-ins because they are AU only. But you invented VST, so no AU support. I don’t get it. Does it hurt so much?
This drag and drop thing is something I (and many others) hate about Cubase. Don’t you want to achieve the opposite?
I don’t see what the big deal is here. The workaround I posted earlier only involves one extra click than if you were drag n dropping directly to Battery. I’m sorry but one extra click isn’t exactly a work flow killer…
Please bear in mind that this XML Translator is for Windows only.
And yes, one click more can kill your workflow. This workaround is not a bit like Ableton Live, as you wrote earlier on.
Try to imagine for a second what would happen if Steinberg included AU support alongside VST in its programs: nobody would code VST plug-ins for OS X anymore as the AU versions would do the job as well and it would be less work for the plug-in programmers to code for only one standard. But as Steinberg bases part of its innovations and functionalities on the VST protocol certain things would then not be possible with AU, such as note expression for example. VST3 also has other advantages compared to AU, for example dynamical I/O configuration. As a consequence Steinberg wouldn’t be able to offer some features for the AU interface and the Mac versions of its programs and thus the cross platform development of Cubase between Windows and Mac would be greatly complicated. I think that’s also one of the reasons why they dropped DirectX plug-in support on Windows.
I think that for the sake of a healthy and fast future development of Cubase, Nuendo and the VST platform itself it makes sense not to include the AU standard, it’s much easier to develop and support one plug-in architecture.
The majority of plug-in developers also code for Windows. I doubt they would drop VST, because it’s crossplatform in contradiction to AU. It would only cause additional workload on their part. But you are probably right with the effort of integrating another plug-in architecture.
However, the topic is d’n’d (from which I deviated first 
) and it’s a sad one.
yeah, back to the topic.
As I said, both are correct. Steinberg says, they offer VST-XML-Information upon drag initiation, which works properly with apps that accept VST-XML-Information upon drop. NI and every other developer is correct, when saying that they support dragn’drop of wav filepointers which works properly.
Steinberg says, everyone could ask for information on how to implement the VST-XML-“drop end”.
Now, there was a single person who wrote the VST-XML-Translator, who did this surely without the help on Steinbergs side, so there is no need for anyone to contact Steinberg on how to implement it, it’s so easy that everyone, including NI, could implement it, if THEY found it valuable.
Fact is: NO ONE finds it valuable enough to implement it. There is NO SINGLE plugin, that accepts VST-XML-Information on drop, despite Steinbergs own plugs. And, IMHO, they are right. Steinberg software is THE ONLY “drag initiator”, who doesn’t offer wav file pointers, but VST-XML-Information instead.
Steinberg says, everyone could implement VST-XML-Information drop support. Everyone else says, Steinberg could implement plain wav file pointer drag support.
And we, the customers are “left in the dark”.
I understand Cubendos underlying nondestructive file/region/event handling and I understand that Steinberg offers way more Information as just a pointer to a wav file, which, on intiating the drag operation within cubase doesn’t even exist in the first place.
And I understand when no single plugin developer bothers implementing VST-XML-drop support, when the “only” software that offers this information is Steinberg Software, and, what’s more, when they can’t do anything more with the Information VST-XML offers.
It would come down to extract the region of a big wav file to a single small file, truncate all other information like bpm, key, etc… the same that VST-XML-Translator does.
This routine has to be coded hundreds, thousands of times by each and every plugin developer who wants to support Steinbergs VST-XML-dragn’drop format. Every developer will find another way of where to store the extracted small wav file etc… which will probably clutter files into different folders…
Where it would be so simple FOR STEINBERG, to code this really small routine of extracting a region out of a wav file as new wav file, store this wav file into the audio folder of the project and provide the pointer to that new wav file on drag initiation when the user holds ALT on starting a drag for example.
Such a thing would be coded in half a day at max.
It would be coded ONCE, namely by this one developer of that software, which is responsible for what it offers for possible drag formats.
THIS WOULD BE CUSTOMER FRIENDLY! It doesn’t hurt, it doesn’t cost huge amounts of development time and ressources. It would be one step closer to MS Windows Design Rules, which always is held high when it comes to arrangement windows maximizing issues etc…:
Cubase works with standard audio files all the way, each and every operation is done with .wav files, but still, it doesn’t offer wav drag, as any other audio program out there, which works with wav files, too, does.
I find it arrogant NOT to even think about a solution of offering system wide standard wav file dragn drop. Cubendo is the only one program who doesn’t support this standard. The Hell, it even does on the “drop end”, you could drop a wav file over cubendo and it accepts it. But it doesn’t support the dragging of wav files, because they are simply unwilling to extract a region from a wav file, create a new one and offer a file pointer upon drag start with held ALT…
These are situation where I’d like to shake someone and shout on him: I am your customer, you would help me and make my life so much easier if you spend half a day implementing standard wav file drag. I would LOVE you. But as unwilling as you are, I HATE you, even though your Software is soo great and gets better every new product cycle and you’ve got so much great ideas, you’ve got the GREAT picture, but lack so hard on really simple, inexpensive details.
Bummer.
Yes. I hope there are some QA people at Steinberg who will read and understand.
You made some really great points here. If its as easy as you say it is (and I’m not doubting it is) this could be something Steinberg could potentially “fix” in a maintenance update. I’m very curious to see what Arne Scheffler (or any other Steinberg programmer) would say in response to the specific details you mentioned in your drag n drop solution.
great posting! Thank you.
- 1 !!!
If Steinberg’s refusal is about forcing people to use HALion – honestly, I’d rather switch from Cubase to Live for good, than from Kontakt to HALion.
A bit OT, but-I’ve never loved Battery anyway. I think the concept was great, but the GUI sucks, changing sounds is a pain, the ‘cell’ bit always seemed unnecessarily complicated, changing the volumes on pads could be more intuitive…the whole interface just leaves me cold. I even like Groove Agent better, though elements of that drive me nuts too.
Does anybody use EZ Drummer? I definitely need an easy drummer! (one I don’t have to keep in beer)
I love Stylus. If it was more comprehensive in its samples ( round robins, etc) I’d probably never use anything else…
Drag n drop to Battery would be nice, but honestly I don’t really use Mediabay anyway, I’m much better using Battery’s own explorer. I find opening Mediabay’s window, then resizing it, then drag n dropping to be cumbersome.
I’m pretty sure its not about forcing people to use HALion.
why would you need to resize Mediabay’s window? it always opens up in the same place at the same size for me every time.