What's wrong in the world of notation softwares?

Dorico
81

I agree with a lot of what Brian Roland and FlowerPower have written in this thread on a variety of topics. Very well-reasoned arguments.

I’m also a huge fan of Dorico and the tenacity with which Mr. Spreadbury and team have tackled the revolution of the notation world. I believe Dorico is going to be the uncontested leader in notation once a few more milestones are crossed.

Overall, I would definitely like to see maximum integration between Cubase and Dorico, notwithstanding different object models and technical challenges. A quick note: Maybe it’s just me, but I get weary of reading the terse comments from moderators who sound angry that people are excited about the possibilities with Steinberg products. Sometimes a single moderator comment makes us all feel unwelcome.

To those who say, “I would never want a DAW with my notation software, or vice versa,” I would encourage you to think about the idea that other people have variegated workflows that aren’t necessarily the same as yours. Increasing interoperability and flexibility will serve to increase the likelihood that a given Steinberg product will appeal to a wider range of people.

The problem I see frequently in conversations like this is that you get two camps:

  1. Limiters: A somewhat stubborn and set-in-ways group that wants to create a narrow definition for what a tool should be. An extreme view in this camp here would be: “Dorico should only be notation software and that’s it, end of story.”
  2. Exciters: A somewhat visionary and flexible group that wants to encourage broadening the scope of a tool to meet wider needs. There’s a possible danger of wanting to mix in misguided “excitement,” but this group likes innovation toward extensibility and customization. An extreme view in this camp here would be: “Dorico and Cubase should be integrated completely.”

The Limiters generally want to keep things the way they are, and going forward on a narrowly defined track. (Some even try to be Brick Wall Limiters and define for everyone else what is “professional” or “the right way.”) The Exciters generally want to look at different ways things can be integrated to support additional ways of working.

This is true for just about any type of tool out there. We DAW/notation people think we’re unique. But, just for the sake of illustration here, go with me for a moment into another sphere of expertise: video stabilization.

In the video world, there are two core types of image stabilization software: 2D stabilization tools examine frames of footage to recognize consistent pixels between frames and keep them locked to the same position in the frame, at the cost of cropping and scaling the video. 3D stabilization tools “solve” a scene by intake of footage and photos from multiple angles, creating a model of the space which allows the video footage to be located in that space and thereby stabilized. (Yes, there are other technologies such as gyro-driven stabilization plots, etc., but I’m trying to just make a point here.) Those who use the 3D software see themselves as being more professional, because the work involved in “solving” a scene requires a certain level of technical sophistication. They see 2D stabilization as inferior and incomplete, a hack of sorts. Those who use 2D stabilization include plenty of major film and television studios; the 2D tech is relatively fast and lightweight and lets people just get the work done. And even a teenager “working in the basement/garage” can figure out how to use it.

As the increasing availability of video software has opened up the door to a variety of people wanting to stabilize their footage, of course the various software manufacturers’ forums include conversations about, “Wouldn’t it be great if we could combine the 3D and 2D approaches? What if they both existed in one program and we could just optimize our workflow based on whichever approach is better for the given project?” But the 3D purists are disgusted that their professional software would be tainted by 2D hacks. And the oldest-school among them makes comments like, “Well, you shouldn’t even need stabilization anyway. If you bought a Steadicam for $30,000 like me back in 1983, you’d have professional, stable footage anyway and you wouldn’t need to rely on crutches like this newfangled software here.”

Well, one company finally combined the utility of 3D (3-axis) stabilization with the ease of a 2D-style stabilization interface: proDAD Mercalli. Does it do true 3D solving? No. Would it satisfy a 3D purist? Not at all. But does it give superior results to people who need a certain workflow? Yes, it does. It would be even cooler if it exposed the 3D capabilities in the interface so 3D purists could use it in their workflows.

Or, maybe more near to our collective interests: Take a look at the world of music players and taggers. I was in a conversation recently regarding an audio file tagging utility. Many of the tool’s users prefer it to remain exactly as-is. But it doesn’t currently support user-defined lists of tags that can be easily applied. In 2017, numerous audio players support tag lists out of the box, so for many users this functionality seems like a common-sense baseline requirement. But Limiters want the app to remain as-is and declare, “Just type in the values you want. You don’t need to keep lists.” The Exciter users say, “Well, I’m managing 5 different custom tag types for xyz commercial reason, and I need to keep my lists well-formed and normalized. So I need lists.” My thought is that it wouldn’t hurt the Limiters at all if custom tag lists were implemented; it would just be an option. But the Limiters in that discussion have strict ideas. “That’s not the correct way to manage your data,” they proclaim. “You should never need this level of granularity.” They want to dictate, to everyone else in the world, what the correct use of a piece of music tagging software should be.

Every industry and topic has its elitists, its upstart kid rebels working in from the edges, its self-appointed dictators of all ages and all the moderates in-between. The elitists often have years of experience, critically acclaimed accomplishments, a highly-refined set of skills and ample knowledge. And the kids and hobbyists often have a cruder approach (which we can all drolly glance askance at, since “we were kids in a basement once, chortle chortle”). Sometimes the elitist holds a concert for a crowd of thousands, while the kid hangs out in his basement. But sometimes the kid ends up producing an international hit, while the elitist hangs out orchestrating a 58-part concerto that no one will ever hear except when he plays the MIDI rendering for his sister at Thanksgiving.

We all need tools. We all have our approaches and ways of working. It’s great when tools support a variety of ways to work.

One thing I’ve learned to appreciate in my life is the wide variety of applications and approaches a single tool can elicit. Even more, when tools can interoperate extensively, the usefulness can expand exponentionally.

Zapier, for example.

So think through this with me:

Let’s say Steinberg finds a way to integrate Cubase and Dorico in deep and novel ways. These integrations don’t have to be forced on anyone; there could be special editions of the software that provide the full “Cubrico/Doribase” experience. Or the features could be modular/optional and turned on/off at will. There are already many features like this in Cubase now that plenty of customers never use. These features could be implemented so that, if they are disabled, they wouldn’t impact performance at all. So an additive integration between Cubase and Dorico - building value between the two apps - doesn’t have to hurt anyone’s workflow. But not having this integration does hurt people’s workflow, to Brian’s and FlowerPower’s points.

If integration exists, it serves more people and the userbase expands. If integration does not exist, it keeps the Limiter group happy but pushes many other people (including me) out of the Dorico userbase.

Why do I favor integration? Very simple. When I open, work on and close files authored in Steinberg products, I want to be able to natively (or at least easily) use them in as many Steinberg products as possible. (As a Cubase and WaveLab user since 1997, I can attest to the strange differences between those applications, the flagship audio tools made by the same company. No, it’s not just that one’s a mastering tool and the other a traditional DAW.) If I work on something in Cubase for awhile, then want to switch to Dorico, I currently have to get out of the creative zone and start thinking about the technical (computer, not music) aspects of ensuring my work converts to the other environment. If I start in Dorico and move to Cubase, same thing. For the Limiters out there who work in a specific environment (doing school band scores or university string section arrangements or the like), you may already be very happy with Dorico as-is. But for others who use blended production models (especially in the commercial sector), we would welcome the day when Dorico and Cubase work seamlessly together and switching between the creative paradigms of each is just a matter of opening and closing interface elements. And I’m not someone sitting around in a garage or basement, for those inclined to perjoratives.

I always want to push myself to maximal expertise, proficiency and knowledge in audio production. But I never want to look down on someone else’s approach to work just because it doesn’t coincide with my own. I myself would like to avoid dogmatically defining narrow targets for “professional use” and what a notation app “should” be at the expense of others’ needs. I like workflows of all kinds: high-brow orchestral works built from the score up; MIDI captures from a proficient guitarist (who doesn’t know how to notate music) to score; improvised-as-we-go experimental pieces which later become scores involving multiple players on MIDI controllers; blended soundstage/VSTi recordings for film derived from a combination of Cubase and Dorico functionality, and more.

The elitist might say that some of these approaches are unprofessional. I don’t care; I just want to make music.

I think the best way forward is inclusiveness and integration.

82

It’s not all on the Dorico team…the CuBase team can get new code and protocols as well.

Personally, I’ll be OK with the ability to export and import easily between the apps if we can retain a decent percentage of the information. Naturally when importing a Dorcio score into CuBase, we mostly want the play-back data…every little engraving and spacing rule for the score isn’t that important. In contrast, when we start a project in Cubase then bring it into Dorico for polished engraving, the important thing is getting a solid point to put the fine details on the score. If percussion staves come in, and they are easy to get mapped out and making the same sounds over in Dorico, then that’s a big part of challenge (For me, it’s where I always spend the most time with bringing XML into any Scoring App).

Really, every time I look at the Play Tab, and see all the potential for that editor…I see that with some time, there will be less and less need to pull things over into a tracking DAW. Give it tempo tracks like CuBase, and add CClanes, or note expression (double click the note in play mode and draw your stuff in…like we do in CuBase)…well…there’s just not much need to pull it over to the tracking DAW anymore unless you need to mix in audio or get into the advanced post-production stuff in Nuendo world.

83

I think you answered your own question when you began with ‘… notation software…’ then continued with why you’re not happy with all the things the software can’t do the way you want that isn’t to do with notation!

The great answer here was if you want software to ‘do XYZ’ then get software XYZ.

As notation software Dorico is the best. When your needs move into DAW territory perhaps ship your notation out and open with your DAW of choice?

84

Limiter. (© ultradust)

85

To me the issue doesn’t need to be complicated.

Basically if Dorico could be told to leave a “blank space” wherever you want customize something. For instance…

At bar 49, you want something different. You should be able to put a picture of a duck, and the sound file of a quack. Dorico doesn’t have a duck quack feature – but blank space gives ability to use whatever visual and audio processed file you wish/

Basically Dorico plays everything from 1-48, 49 is yours, 50- end is Dorcio. The ultimate customization is a blank spaces, Dorico isn’t involved, because for whatever reason you need something there that Dorico just can’t do/

(yes, it should print a picture of the duck you picked for it in the engrave portion if that’s what someone wants. )

Yes, I am serious. : ) It might sound riduckulous though.


OTOH, I hope Dorico is capable of doing lots of necessary musical requirements in the end without needing much extra.

86

Dorico can do both those things already. You can import graphics images into your score. And if you have a VST instrument that can load any sound file (e.g. Plogue’s Aria player, or the free cut-down version Sforzando) you can trigger any audio you like from a note in the score.

It might not be “elegant integration,” but it works!

87

I just want to use Dorico’s editor in Cubase as a score editor. That’s it.

Benji

88

There’s only problem with that: Daniel has said several times already that it’s not what his team was set up to create.

89

I can wait.

90

It can also output MIDI, which you can feed into a DAW or into, say, Max, which makes the possibilities really endless (or open-ended at the very least).

I feel that if these scenarios were genuine needs of the users, the proponents would be able to come up with concrete requests instead of diffuse dream scenarios for a far-out future. Working with mixed music, I have a genuine need for these “blank spaces”, as rexwine called them. I imagine media composers (I know I am, though I can manage like this) are still waiting for ReWire or perhaps some video integration. But that’s wholly different from the types of solutions being thrown around.

91

Until such time as Dorico gets his own app bridging features: You can get some degree of reliable/useful ReWire support from Dorico with the ReWire VST plugin. One can sync to Video with Dorico as the Master using VidPlay VST.

Dorico ‘kind of’ imports and exports MIDI and XML. Of course these abilities improve with each release, but it’s a long way from being professional integration with CuBase. Expression maps from CuBase are quazi portable…and we look forward to seeing that aspect of Dorico grow…and hopefully it can be a nearly automatic process for CuBase users to have ‘all’ their expression maps recognized in Dorico out of the box. In the short term?

You can import the MIDI performance data, or an XML score into Dorico from other apps, but you can’t import an entire ‘playback’ setup yet. One still has to go into the play tab and rebuild all the instruments one by one, and set up each Plugin one by one. The same is true for XML imports.

Oh, and Dorico doesn’t yet keep your CC data when ‘importing’ MIDI created in another app, so you’ve still got to go in and do a native expression map setup if you want interpretive playback from Dorico itself.

Percussion stave imports are a pain when working with XML in things like Sibelius, Finale, and MuseScore, and there really needs to be a way to quickly/easily move percussion staves and their mapping between Dorico and CuBase. Again, it makes sense that various spacing and engraving data can get lost when porting things across apps…but all of the kit and instrument mapping, score symbols/text, and post-interpretive performance data etc. should remain in tact. Upon importation, one should be able to hit play, and it ‘sound the same’ in both apps, with notes being on the right lines and spaces (and having the right general head-shape).

In the short term, having Dorico support CuBase “midiLoops” would do most of the job nicely. If a stave, group of staves, or an entire score could be exported as a Cubase “midiLoop”, then they’d show up in Steinberg’s Media Bay, all ready to be previewed or pulled into CuBase with everything ready to ‘hit play’ and hear the ‘same thing one heard in Dorico’. If Dorico could import midiLoops, and keep all of the Continuous Controller, Note Expression, and/or Sysex data intact, then again, they’d come in with the VSTi and channel VST plugins all set up and ready to play.

Ideally, when working in world Steinberg, one could directly import a *.dorico file into CuBase (ready to play back, not necessarily with all the advanced Dorcio scoring data intact), and one could import compatible tracks from a CuBase project into Dorico and they’ll be sonically identical (plugins all loaded and ready to go). It could rely on some sort of app that ‘converts’ the project before loading it.

If it is true that there’s no way to host Dorico interfaces in CuBase (and no concrete plans for developing protocols and standards to make it possible), then it makes sense to have as close to 1 to 1 import/export routines as possible on the side. We do understand that CuBase’s built in score editor isn’t going to be able to do everything Dorico can, and vice verse. The point is just having a really good foundation at the point of import to work with…where everything ‘sounds the same’ in both apps (if running on the same system) until we go about tweaking it further.

92

Accurate.

There’s a problem with that, though: The average person shopping for DAW / notation solutions who comes across Steinberg’s suite will, rather naturally, expect a high degree of integration and will be disappointed by the lack thereof.

And don’t get me wrong - I’m a huge fan of Dorico and Spreadbury & team. They’re doing magnificent work.

Most of the people I know who use notation software (often professional arrangers, composers and musicians operating in orchestra and commercial jazz ensemble environments, in my case) don’t have the time or inclination to pursue information about software developers’ internal operating plans. They see “Steinberg” on a series of boxes and naturally expect, “Well, these should work really well together, since they’re from the same company.” They, quite rightly, expect similar integration as, say, Adobe’s creative suite of tools. I remember my own surprise long ago when I first discovered that the “reasons” given for lack of shared elements between Cubase and WaveLab were: “Well, WaveLab is the work of one guy who’s built it from the ground up. So don’t go expecting him to refactor just because the Cubase team made a change.” Sure, that’s a legitimate explanation of the business reality. But in many cases, customers like myself see the discrepancies as a basic lack of collaborative planning and execution inside a company. Steinberg should probably be working harder to build a true production suite (DAW, mastering workstation, film scoring DAW, and now, notation engine) that work together seamlessly - with congruity between interfaces, terminology, workflow, etc. - rather than what could be described as a hodgepodge of independent, mostly non-integrated tools.

In other words, people see the “Steinberg” logo on the box and think, “The same company built all these products. They’re probably going to work together seamlessly, or at least approximating that.” They don’t instinctively think, “This is a rubber-stamp logo that really represents a DAW company, a sole proprietor’s pet mastering workstation project, and now, an independent notation team going in their own direction.”

Most people in the market for these tools (based on known forum metrics, probably 95% or more) do not join forums like this to figure out why the interoperability isn’t there. They’re not reading Daniel Spreadbury’s “Making Notes” because they don’t have time and they don’t care. Those of us who actually take the time to read and post are a very small minority. The rest (and indeed, many people who sign up here for the first time just to make this point) are just somewhat bewildered by how a single, unified Steinberg company could really not be planning full integration between Cubase and Dorico.

Are there valid business reasons as to why not? Absolutely.

Does it make sense to many people in the market looking for their next notation software? No.

It sounds weird that “Dorico is going in its own direction, and there are no plans for it to become the Cubase score editor. Cubase will continue with its own legacy score editor.”

If Dorico is indeed going to be the best-in-class notation software, and if it’s made by Steinberg, then yes, people generally want Dorico under the hood in Cubase. They want the simplicity that integration would provide. It just makes sense.

Whether various internal Steinberg teams or people were tasked with achieving such integration is irrelevant to this marketing issue. It’s what people quite naturally would expect. That’s why Steinberg will continue to encounter bewilderment and disappointment from prospects and customers who realize that full integration isn’t in the works.

93

Integration between Adobe products? They got rid of the button to switch between apps ages ago. They now have dedicated software (AEM) to be able to manage a limited number of integrated features between some their softwares. If anything, Adobe is the case study on the advantages of having a suite of dedicated tools instead of one big offering: Photoshop only has the basic tools needed to handle vector graphics — if you want to do it properly, start in Illustrator. Illustrator can draw text, sure, but it would be mad to work on a layout on anything but InDesign. You might wireframe in InDesign, but get XD or Muse or DreamWeaver — three different softwares! — to design a site. Lightroom is a whole different thing compared to Photoshop. AfterEffects is not integrated in Premiere.

I’m sorry, but the “people don’t research a certerpiece professional software” argument just doesn’t cut it. Right by the Steinberg logo in the box, it says Advanced Music Notation System. And despite the brouhaha here, no one will search around for a DAW/Notation package because they don’t really exist — that’s precisely why everyone wants to push the team in that direction. Let the team start to flesh out their vision for the Play mode as they envisioned, after consulting top industry pros across the spectrum. See what complaints you might still have then.

94

Hi LSalgueiro -

Respectfully, I disagree with your assessment of Adobe’s integration. The products are purposefully designed to interoperate and the continued aim is increasing integration.

The “switch” button is increasingly irrelevant because the workflows for managing shared assets and tools between applications are now more streamlined.

Photoshop only has the basic tools needed to handle vector graphics — if you want to do it properly, start in Illustrator.

I agree that if you are focused on vector graphics, then of course your Adobe tool of choice would be Illustrator. But Illustrator files can be opened and placed directly in Photoshop files, and vice-versa. They can even retain their vector and/or raster characteristics (no need to convert) throughout the design process using smart objects. This makes my point precisely: You don’t have to export a generic version of a graphic and re-import it into the other Adobe app, losing the original quality. You can transition seamlessly between the two apps.

The analogy here would be: If you want to primarily work on notation, then you’re right, you should start in Dorico (as a vector graphics designer would start in Illustrator). But Cubase should ideally be able to work with native Dorico files (as Photoshop can work with native Illustrator files and vice versa), without the hassle of having to export and import the Dorico files. Adobe has done excellent work in this regard.

Illustrator can draw text, sure, but it would be mad to work on a layout on anything but InDesign.

Again, I respectfully disagree. In fact, right now I’m doing some contract work with a company’s marketing department where several layouts are designed in Photoshop and get placed into InDesign. (I’m not talking about just creating assets and then slicing and importing them into InDesign; I’m talking about full .psd layouts moved to InDesign using the placement tool.)

You might wireframe in InDesign, but get XD or Muse or DreamWeaver — three different softwares! — to design a site.

Yes, you’re right. But I’m not arguing against having multiple tools in a suite. I’m arguing for tight integration between the tools. Further, the tools you mention here are really quite a different case from DAW/music notation.

Muse is a non-coder’s quick-and-easy web design tool, while Dreamweaver is focused on someone who knows how to write their own HTML, CSS, .js, etc. Dreamweaver can open and edit the code output of Muse. But because Muse is designed to be a helper for non-coders, it’s sort of implicitly understood that a Muse user (the target user) isn’t probably going to want the vice-versa interoperability, as they’re not likely to want to get under-the-hood to mess with code. And of course, with Muse’s proprietary approach to delivering functionality via widgets, once that code is edited in Dreamweaver (or any other editor), it’s now broken in Muse. That’s not really an integration issue; it’s a level-of-coding issue.

And XD isn’t really comparable to Muse or Dreamweaver. XD is not really a web editor; it’s more like a mini-Photoshop/Illustrator combo with a richly-featured prototyping toolset. Designers historically have started in Photoshop/Illustrator and then sent their work to developers to slice and code. XD replaces this function and adds proper prototyping features such as interactive components, client review, collaborative comments, etc. Yet, you can use the assets you create in XD in your other design applications - and Adobe is working on increasing integration where it makes sense.

The main difference I see here between these products you mention and the Steinberg suite is that the general domain that Muse, Dreamweaver and even XD operate in involves industry-standard formats (HTML, CSS, javascript, .jpgs, .pngs, etc.) that are readily usable across-the-board. People doing web/app design/development generally expect that they’ll be using their (and their teams’) own favorite combination of tools and workflows to deliver results, so getting at those results using a combo of Muse, Dreamweaver, XD, etc. is less about application integration and more about getting the assets you need to keep working. And with coders, they’re generally prepared to code their own fixes anyway. In the case of Dorico and Cubase, the applications use proprietary formats that are opaque to all but the developers, and the options for export often result in significant work when imported into the other application. The end-user is often not a coder, but a musician/arranger/composer who doesn’t want to code. They just want things to work. So when the Steinberg user has to stop down and solve technical problems migrating work between Dorico and Cubase, it can be a real challenge - and it’s not as though they can just recode the Dorico file to make it work in Cubase in the same way someone can open an HTML file in Dreamweaver.

Lightroom is a whole different thing compared to Photoshop.

This one made me laugh! I assume you’re joking?

Yes, of course, Lightroom is a whole different thing from Photoshop. If it wasn’t, then Adobe wouldn’t have bothered to make it.

But you can use Photoshop directly from Lightroom as its external editor. You can directly share color spaces between the two apps. You can share Camera Raw and send a raw file back-and-forth. You can directly insert raw files from Lightroom as a smart object, retaining the Lightroom project details. You can even set up Photoshop to add a flattened raster layer to each layered file so that layered files can be edited in Lightroom. Really, what more can you think of that you’d want to see integrated between the two apps??

AfterEffects is not integrated in Premiere.

Again, I respectfully disagree. I actually assert your statement here is entirely false and misleading. As someone who does commercial video editing work, I’m very glad for the extremely robust integration between these two apps. You can use entire After Effects compositions in Premiere, and you can send Premiere sequences to After Effects. These are clean, complete round-trip processes using Dynamic Link. You can edit Live text between the two apps. You can share masking and tracking functionality between the two apps for almost every effect. You can share many actual plugins between the two apps. I could go on and on… and then there’s the integration between Adobe Animate and After Effects which can speed up motion graphics workflows tremendously.

After Effects and Premiere can directly utilize each others’ native assets with no hassle. You can open one in the other’s environment. If Cubase and Dorico worked together like After Effects and Premiere do, then my concerns would be resolved.

Your assertion on this one is false.

I’m sorry, but the “people don’t research a certerpiece professional software” argument just doesn’t cut it.

There are people like you and me who really care about this stuff and spend time looking at it. But most of the people I know shopping for notation software right now are just torn between Finale “because that’s what everyone at the orchestra uses” and Sibelius “because I’ve heard it’s even better than Finale from Jasper the viola player.” And they’ve not heard of Dorico, but they’re familiar with (and perhaps use) Cubase and so the next natural question is: “Oh, so can I open the scores I create in Dorico in Cubase and keep working there?” And the answer, for now, is not without export/import and workarounds. It’s just confusing to people. You can disagree, but the reality is that it confuses a lot of people.

And despite the brouhaha here, no one will search around for a DAW/Notation package because they don’t really exist — that’s precisely why everyone wants to push the team in that direction.

Well, I searched around and landed on Cubase precisely because it is a DAW/notation package that does exist, and has since last century. Now that Dorico is a part of the Steinberg suite, I’d like to see the suite more tightly integrated.

Let the team start to flesh out their vision for the Play mode as they envisioned, after consulting top industry pros across the spectrum. See what complaints you might still have then.

Yes, I agree with you, and I’m not trying to stop the team. This is a forum discussion. I don’t really have any complaints; I’m just laying out the case for why tighter integration is desired and expected.

95

I committed the mistake of replying to the general tone of the thread instead of addressing you specifically and for that I apologize. If you start from the top, you’ll see that most of the few users that chime into this kind of discussion generally want a type of integration that is wholly beside the point of Dorico, and some want to simply collapse the software into Cubase and that’s the end of it. You thought it was just bewildering that I stated that Lightroom and Photoshop weren’t the same. Well, of course it’s bewildering — starting from the fact that it’s a truism — but it’s what some have suggested. I’m not against integration. Rather, I’m against the kind of people who do not see the need for After Effects to exist beyond Premiere, Lightroom beyond Photoshop, or Dorico beyond Cubase. That was the point of the simile: that there’s an ecosystem as opposed to a one-size-fits-all solution.

96

Rather, I’m against the kind of people who do not see the need for After Effects to exist beyond Premiere, Lightroom beyond Photoshop, or Dorico beyond Cubase. That was the point of the simile: that there’s an ecosystem as opposed to a one-size-fits-all solution.

Absolutely. I totally agree with this.

Thank you, LSalgueiro, for your kind and thoughtful words. Means a lot!

97

So does your feedback. Your professional work seems to be hung up, in part, with the skillful manipulation of specialized software, so you can acutely understand the inherent challenges better than most.

98

… and there lies one of the key issues. Nothing equivalent exists for music, except the centuries old technology of ink on paper.

MIDI is a pretty good (though not ideal) industry standard format for playing music on computers, but it’s a terrible way to try to represent notation. That’s part of the reason why DAWS produce terrible looking scores. But the “integrate notation into a DAW” faction don’t know (or care?) about that inconvenient truth.

The only other kid on the block at present is MusicXML. IMO that hasn’t matured into a stable format yet, and hasn’t really decided what it is trying to capture. While its developers were employed by MakeMusic, it probably wasn’t too surprising that it looked at the notation through a “Finale filter” which tended to ignore semantics and focus on the layout of the ink marks on the paper. As just one example, early versions of MusicXML didn’t even have a way to say “this text is the title of the piece, that text is a block of lyrics printed after the score not under the notes”. Both were just “Here is some text, it lives at this position on this page of the score, print it in this size and this font”, etc. - which, by some strange coincidence, is how Finale represents the situation!

As a result, every app that wanted to import the semantics of MusicXML data had to figure out how every other app that exported it organized the data, and handle all their random, incompatible, and mostly undocumented work rounds of the holes in the standard. That solution just doesn’t scale - you can make it work by brute force for 5 or 10 apps, but not for 50 or 100. And many apps (including Cubase!) generate MusicXML files which are full of violations of what little is well defined.

The MusicXML standard is now being managed by an independent standards body, but (from personal experience of how international standards get defined in other fields) the wheels of change turn very slowly indeed. IMO nothing significant is likely to emerge from the end of the process for at least a decade - and even then, just creating a high quality standard achieves nothing until all the app developers take seriously the task of implementing it correctly! If they just keep muddling along as they do right now, that might never happen…

TL;DR: Don’t hold your breath!

99

I think the problem with musicXML is that it was decided what it should be, but then more sophisticated demands were placed upon it such that its legacy code has had to be contorted to try to fill its new role.

100

Brilliant post!
IMHO the whole thing about “DAW features in my notation software” must partially be based on some misunderstandings. First of all, I don’t the see the functions I miss in Dorico as “DAW features”, I just miss functions that will help my workflow; functions that are more related to ‘music’ than to ‘DAWs’ in the first place.

Saying no to DAW functions would equal for instance:
Saying no to the ability to add a movie file to the project, which would ai be very useful if you write music for picture, and b) would be a function that you probably even would notice existed if you don’t need it. Or it could equal saying no to have better and more detailed control over your tempo. The important thing with tempo lists and tempo maps aren’t that DAWs got them first, but that tempo is ex extremely part of music, and that lot of of music (not only classical music) beg for detailed tempo control simply to sound right. Saying no to DAW functions could also equal saying no to importing (or even recording) audio tracks, which would be useful in a lot of situations - and again: neither of these functions would hardly be noticeable for those who don’t need them. I could post abut a dozen other “DAW functions” as well, but I have mentioned some of those earlier + again; forget that they are called ‘DAW functions’, DAWs just happened to get them because working with music often implies a need for such functions.

Increasing interoperability and flexibility will serve to increase the likelihood that a given Steinberg product will appeal to a wider range of people.

Absolutely. And for those who create (as opposed to only engrave) music on a computer, I’m pretty sure most of you/us will miss ‘DAW functions’ as soon as we want what we have created to not only look good, but also sound good. Proper CC automation if orchestral libraries is a good example of that - simply because most string libraries, for instance, sound vert unmusical if no alteration of vibrato and dynamics exist along with the MIDI notes.