Hey, sorry to hear about the loss of your post. I hate when that happens. It’s such a buzz kill. I’d love for you to engage me via pm, I’m interested to hear your take on what you find faulty in my reading of whats wrong in the world of notation software (and notation culture). Anyways, you said I “might fundamentally misunderstand how music software handles fonts”, no, you’re a little bit off base here. Actually I have absolutely no idea whatsoever how music software handles fonts! . I am completely ignorant! I’d love to learn more, but unfortunately, the likelihood of my understanding of how software handles fonts is not going to change dramatically unless all my work in composing and playing dries up, and all the 'to be read" books in my library disappear. I’m sorry to all the professional font folks out there, I know it is a beautiful art, and also to the programmers who have to implement such stuff. It must be tricky. You’ll notice, LSalgueiro, that I don’t claim to know anything about how fonts work, in fact I explicitly state my lack of knowledge regarding coding. What I do know alot about is writing music, and the desires and wishes of composers. And, if you reserve a discussion on notation software to people who only understand fonts, I think it would be a disservice and sad for the development of this wonderful tool, and the industry as a whole. Imagine if electric guitar manufacturers/developers only kept their discussion to people who understood the science and principles of magnetic pick ups and the wiring of electronics. The only reason I repeatedly bring up the time signature example, is that; 1. it is quite a common desire for composers, and 2. Sibelius has a this feature since I can remember. So although you are absolutely correct when you state that I know nothing about the unique way in which Dorico handles fonts, that isn’t really the point is it? The point is simply that, what seems to font-implementation-ignorant people like me is that, I can’t change the way 4/4 looks. That’s it. Pretty simple. And the fact that the feature has been around in Dorico’s primary adversary for ages is a bit strange. Somewhere along the line, someone on the Dorico team thought it was not important. Someone made the decision that changing time signature fonts was not a priority. The team is too smart to have just forgotten about it. So? But when I bring up the subject in a forum like this, I get “aleos might fundamentally misunderstand how music softwares handle fonts, and how Dorico does it differently. Since Bravura is licensed under a SIL Open Font license”. Thanks, I know too, that I don’t know about it. What I am curious abut is why a rather simple and in-demand feature such as font manipulation (for dynamics too), was not taken into account in such an excellent and well thought out program. Again, someone made the conscious decision that this wasn’t important enough to be included in the software. That is a curious aspect to me. And it is examples like that that provoke people to say, mistakenly, that “the developers or not musicians blah blah”. Of course that’s not true and those childish accusations, we just simply ignore, but the nagging thing in there is, that, although a stretch, I can see how one would arrive at such a conclusion. For instance, simply, answer the question to yourself; why was font manipulation not made a priority in an engraving centric notation app? Because it was too hard? I don’t believe that. Software engineers are experts at bringing to life the dreams of developers. Someone, somewhere along the line said “we don’t the option to change fonts quickly in a menu, like Sibelius has, people don’t use that feature”. This, unfortunately, I think was a mistake. I also never implied that version 1 is a stone tablet. I have nothing but admiration and respect for the team that developed this software. I am simply curious about the decisions that were made. And adding my 2 cents on “whats wrong with the world of software notation”. For an app the promotes itself as an engraving tool first and foremost (an ethos which I am 100% in love with), it’s slightly confusing for the non-programmer to understand why font changing would be such an issue, why there would be no other styles of noteheads, why wouldn’t there be a modern clefs, and overall notation except for the-old-in-the-tooth jazz font, (which hardly any of us Jazz players use when exchange lead sheets) and why playback of third party samples, and all the rest of that, is ‘easy’. I’ve found work arounds in Dorico, using text instead of the dynamic marking tool, for dynamics, I understand that many of my gripes could be achieved through some hoop jumping and maneuvering, it just seems to me, as of now, the aforementioned ethos, doesn’t appear to be strongly reinforced by the product.
If anyone had asked this question a couple of years ago, the only conceivable answer was that notation software was stuck in a rut.
I don’t think that’s the case now - Dorico is bursting with potential, Steinberg and Yamaha appear to be in this for the long haul and the team have made no secret of taking the program well beyond the scope of simply engraving music (beautifully). Personally, I’m in with DAW group: from day 1 I’ve made it clear that I’d far rather make music with notation software than the ubiquitous piano roll - and that means all the way down to a final, mixed product.
I confess to being a bit disappointed with Dorico when I first saw it. I thought (still think) it was launched a update or two too early. However, as the months have rolled by, it’s becoming ever more clear that the team know exactly what they’re doing and one year on Dorico is far more robust and impressive. If there’s an issue in that the team’s priorities don’t match mine - ultimately I’d far rather they maintain direction and continue to develop in a way that ensures things are being done right, rather than have them lose focus by opening up development on multiple fronts. I don’t see it meeting all my requirements for quite a while - version 3, more likely 4 - but I’m supremely confident that at some point it will. In the meantime I get increasingly more use out of it and if I currently have to work with two programs to get what I want, that’s no different to what I’ve been doing for years.
In short, these days I enjoy the ride, mindful of the fact that all good things come to those who wait. And the answer to the thread question is that notation software is no longer stuck in a rut and has a future.
Aleos, I have been reading your posts, and what I think is what you really need out there is not really new things in Dorico. What you need is that people who can design music fonts do it the way you wish they would. I understand that and I think it is a totally legit demand. Maybe some nice designers out there could fulfill your demand — this is very time consuming, as Paul has stated before.
I am quite interested too in aesthetics, and therefore I bought November 2 and MTF-Cadence, the only SMULF-compliant fonts out there. I must say you are right in thinking there is no revolution in those fonts, they look like optimized-by-centuries-of-engraving fonts, which is fine for most of us. It might be interesting to have some pictures of your master’s engravings, for some designers to try and copy or find some inspiration. Anyway, nice discussion, thank you, dear Doricians !
Yes! I agree. I would be more than happy to buy a font from someone. I almost bought November as well, it looks great, but in the end, I decided it wasn’t enough of a departure from what already is here, at least for my taste. There is a member on this forum who designs very hip (non-music) fonts, but I think he is dabbling in a music font, and also does some fantastic research that is definitely up my aesthetic alley. To get someone to personally design a font would, justifiably, cost a lot. Maybe you and I could team up and coax some friendly soul to undertake a project.
I love LSalgueiro’s treble clefs, and pretty much all of the notation he/she shared with us. The treble clef and rehearsal marks are a little too 'handwritten" for my taste, but maybe that could be a small option to change, I could beg him for, if that font were to go public.
Yes, I as well think this is an excellent discussion. Good work Dorico folk! Hopefully I can make the switch soon. I guess I should start building up my chops with it anyway, it’s just sitting here in my applications folder, feeling lonely. Should probably give it some love.
Don’t worry; this is a hobby for me too. One thing I clarified in the lost post was that I am a composer first and foremost, so I can very acutely understand where you’re coming from. My professional career as an engraver started when I found myself bewildered that everyone around me seemed to just trust their notation’s software defaults, not caring when they got something grossly wrong — or, if not wrong, just plain ugly. I just had to get everything right in my scores because I loved the sheet music that I saw published, most of it many years ago. And this was a very early impulse — not quite from the start, because my first software was Noteworthy Composer (which I recall was rather limited, but an astounding discovery for me at such early age), but when I was first introduced to Finale and Sibelius. Then I started to do this for colleagues, then even for my teacher at the time. By the time I was 18 and finished my first year of college, I already had enough experience to be trusted with what was my first major engraving commission, after being recommended by the teacher that was supposed to teach notation software fundamentals.
Now, I only even invoked your misunderstanding in passing for one reason: if you can’t correctly conceptualize the problem, you won’t be able to correctly diagnose it. In my original post I tried to explain some fundamentals; when I tried to post and the page timeout, and a refresh yielded only your post with all my text gone, I cut it down to that because it was the argument’s kernel but not, of course, what was fundamentally interesting about the conversation. But the instrument analogy is interesting. If you don’t know anything about the guitar’s electronics, all you can do is play the guitar as-is. Terrific music is made, certainly. But you can’t modify the guitar itself, change its tone beyond what the pots or the switch allows you. Not knowing doesn’t stop you playing the guitar; not knowing doesn’t stop you using Dorico. It just stops you short of doing just right what you want. This is true for absolutely every tool.
The only reason I repeatedly bring up the time signature example, is that; 1. it is quite a common desire for composers, and 2. Sibelius has a this feature since I can remember. So although you are absolutely correct when you state that I know nothing about the unique way in which Dorico handles fonts, that isn’t really the point is it? The point is simply that, what seems to font-implementation-ignorant people like me is that, I can’t change the way 4/4 looks. That’s it. Pretty simple. And the fact that the feature has been around in Dorico’s primary adversary for ages is a bit strange. Somewhere along the line, someone on the Dorico team thought it was not important. Someone made the decision that changing time signature fonts was not a priority. The team is too smart to have just forgotten about it.
Now this is just plain unfair. You might notice that the team has mostly let the discussion run freely across members (though they read pretty much everything), but this argument has baited Paul into the discussion. Sibelius has this feature since you can remember. Great! Then you must think Sibelius has been around since the big bang. Not quite, but 20+ years of Sibelius compared to one (since the launch) of Dorico is quite different. Twenty years of iterative development. And if you take into account the complexities of software development today as opposed to just a few years ago… To expect them to match those 20 years in three would be unreasonable. But you’re absolutely right — the team hasn’t forgotten about it. Bravura, the font developed to serve as the SMuFL flagship and the font you’re using right now in Dorico, has non-serif time signatures. It’s just that it’s been admittedly not a priority to implement a way to have the user switch to the stylistic alternative in this case. And why should it be? The team has finite resources, and there are much more important features to implement, some of which are impending. I’m sorry, but bogging a discussion such as “what’s wrong with notation software today” — even though the tone of the original post was downright trollish, if I recall correctly — down to “Dorico hasn’t implemented my pet peeve” is an attitude I find very strange. I find it quite narrow-minded, and actually beyond the point. If you say that you can’t change the time signature, pretty simple, then I could say — despite showing you that you can — “then don’t use Dorico if it’s not right for you”, pretty simple. It’s obviously not what I’m doing, or else I wouldn’t be two very long posts deep into this. It’s also not what the team is doing. There’s five years of unfiltered and clear communication regarding the philosophy, the capabilities and on-going development of the software. If that’s not enough, then I don’t know what I can tell you. Have another gander through the thread. You might actually be in the minority in saying you’re delighted that Dorico (currently) somewhat privileges notation over playback. Why should your pet peeve come first?
So? But when I bring up the subject in a forum like this, I get “aleos might fundamentally misunderstand how music softwares handle fonts, and how Dorico does it differently. Since Bravura is licensed under a SIL Open Font license”. Thanks, I know too, that I don’t know about it. What I am curious abut is why a rather simple and in-demand feature such as font manipulation (for dynamics too), was not taken into account in such an excellent and well thought out program.
Again, because you’re misdiagnosing the problem. I reiterate that I tried to explain, but it got lost. You can’t jump to a new tool and expect to keep your workflow intact. There will always be differences, even if slight ones. And there are many other in-demand features that aren’t in place either.
Again, someone made the > conscious > decision that this > wasn’t important enough to be included in the software> . That is a curious aspect to me. And it is examples like that that provoke people to say, mistakenly, that “the developers or not musicians blah blah”. Of course that’s not true and those childish accusations, we just simply ignore, but the nagging thing in there is, that, although a stretch, I can see how one would arrive at such a conclusion.
Reread Paul’s post. This is simply narrowminded. At best, it wasn’t more important than everything else that made it into the software by now — which is hugely different. The framework is there to be fleshed out.
For instance, simply, answer the question to yourself; why was font manipulation not made a priority in an engraving centric notation app? Because it was too hard? I don’t believe that. Software engineers are experts at bringing to life the dreams of developers. Someone, somewhere along the line said “we don’t the option to change fonts quickly in a menu, like Sibelius has, people don’t use that feature”. This, unfortunately, I think was a mistake.
This is a big misrepresentation. You’re trying to fill the gaps of what you don’t know with speculation, and it’s way off the mark.
I also never implied that version 1 is a stone tablet. I have nothing but admiration and respect for the team that developed this software. I am simply curious about the decisions that were made. And adding my 2 cents on “whats wrong with the world of software notation”. For an app the promotes itself as an engraving tool first and foremost (an ethos which I am 100% in love with), it’s slightly confusing for the non-programmer to understand why font changing would be such an issue, why there would be no other styles of noteheads, why wouldn’t there be a modern clefs, and overall notation except for the-old-in-the-tooth jazz font, (which hardly any of us Jazz players use when exchange lead sheets) and why playback of third party samples, and all the rest of that, is ‘easy’. I’ve found work arounds in Dorico, using text instead of the dynamic marking tool, for dynamics, I understand that many of my gripes could be achieved through some hoop jumping and maneuvering, it just seems to me, as of now, the aforementioned ethos, doesn’t appear to be strongly reinforced by the product.
I’m not a programmer and it never puzzled me. And it shouldn’t, because the explanation has been provided a myriad of times, both in the forums and in this very thread. Very soon, the people who are providing it might just tire and recede into silence because it might just not be worth it. I can only urge you to take what you can get from these discussions and to really dive into the way Dorico does things, instead of fighting the software. This is true about any tool, by the way, but doubly so when the tool implements some game-changing paradigms. Of course your demands are legit. But so are almost everyone else’s, and the balancing act is insane. As Marc said, most of what you’re looking for doesn’t actually entail a new feature, but just a different font, which is a very niche market. It’s not even Dorico’s problems, per se. As I said, I think I can help you. I’ll drop you that PM.
For what it’s worth, I think Dorico is superb for such a young application. I have very little to complain about since I can see the point of the software, the progress with each release, the potential that can still be built into every tab/mode/editor (and new tabs can be added in the future), and the power. flexibility, and quality of the many engine layers.
Obviously things that ‘go on the page’ are most important. The rest will follow in due and appropriate times.
When it comes to ‘integration’ with something like CuBase, I honestly do not know if it’s easier to have ‘portable’ documents, or to build pipelines in both apps so they can work with the same data pool in the same active memory pool at the same time.
If there is a path of least resistance that can be done sooner in the development road-map without harming the long range system architecture, using existing code at hand to ‘wire up’, I’m speculating we’ll start to see that stuff weave its way into Dorico. I.E. MIDIloop exporting and importing. For me at least, that’d be 90% of the way to a nearly ideal bridge to port projects between Dorico and Cubendo worlds. If Dorico ends up using a similar schema for drum mapping as CuBase, then I’m 98% of the way there with a MIDIloop exchange. For larger projects it could save a good hour of duplicating plugin setups after the transaction.
Just ideas, and while I doubt I’m thinking of anything the Dorico team doesn’t already have reams of data and research over, it’s fun to pipe in here and blow hot air from the balcony. If nothing else, it provides a little insight as to how a user is getting along with the product, and what he would find useful/valid, yet fairly doable with a reasonable amount of time/effort.
To make the obvious comment: close integration with Cubase is no use to people who don’t use Cubase as their DAW, In fact it might discourage them from using Dorico for notation!
Of course re-using the some of the design concepts and code from Cubase internally in Dorico is a different matter - and not an issue, since it doesn’t stop Dorico being a stand-alone application.
Apple tried (and eventually backed off from) creating a “walled garden” software ecosystem to run on their “walled garden” hardware - but I don’t think Steinberg should be looking to copy that business model.
Further to Rob’s point, there must be long-term users of Cubase that very occasionally use its scoring functions and certainly don’t want to learn a new (Dorico-based) scoring module.
Product interoperability usually benefits both products in the offer from cross-over purchases (e.g. Cubase owners buying Dorico, Dorico customers buying Cubase) insofar as the interoperability doesn’t exclude other offers in the market (e.g. makes it harder to use Logic, Digital Performer, Ableton, Protools, etc.)
I’m skeptical that making Dorico play nice with Cubase can be anything but beneficial for Steinberg. Making Dorico play nice with other market leaders (Logic and Protools come to mind) would be advantages to those customers using those workflows. That is not to say a Reaper user might complain why their DAW was not given extra support, but in general, the more interoperability Dorico can offer, the more opportunity it has to enter the orbits of established products in the market.
Conversely, poor interoperability between products, discourages customers with more elaborate workflows. This would most impact customers coming from established workflows (Sibelius, Cubase’s Score Editor, Finale and so on…)
On the other hand, making integration so deep that precludes or weakens the use of other products (“a walled garden” for example) can be detrimental if customers are unwilling to abandon their pre-existing workflows.
It would probably be advantages for Dorico to increase interoperability without necessarily forcing other choices (such as DAW) on the customer.
Everything developed now will be much more established later on, and likely harder to change. Now is the best time ever, even if you don’t think they will take up a suggestion.
I beg to differ. That’s like saying XML is of no use to anyone who only works with a single Notation Package. Archival and exchange is important to the lion’s share of today’s musicians.
I do agree fully that Dorico needs to be an all around complete package as a stand alone product given its price tag, but I do not agree that barring development that pushes the price through the roof, that integration capabilities with a flag-ship post production environment would ‘discourage’ people from using Dorico.
If you want to collaborate with people and get your music accessible to as many media formats and distribution schemes as possible, then portability and integration into other products and formats is of value, even if you primarily do all of the composition in a single a application.
Until such time as Dorico has matured to a point where it has all of its own DAW-Centric features (fine detail over playback of MIDI/virtual instruments, synchronization with film/video/gaming engines, basic audio tracking, etc.), people need the ability to either integrate, or exchange documents in the Steinberg Realm (and beyond).
At the other end of the spectrum there is a clear need for modular e-Publishing tools. A score is one thing, but the power to do anthology and text book type works, and to make collaboration and interactive sessions more robust is behind the curve compared to just about every other ‘information realm’ in modern society.
So far all of the Scoring Packages don’t put much if any emphasis on things like SCORM, AICC, 3D meta-verse integration (interactive eLearning stuff), etc. At this phase in the competitive scheme of things, I’d love to see some notation suite start to take a closer look at getting music notation into the 21st century when it comes to interactive/collaborative publishing protocols and standards. Just having a way print to paper, or to sell/share scores on some web-site isn’t enough compared to what every other industry out there is doing with software these days. We should be able to put together interactive learning modules and export them to SCORM/AICC compatible formats all ready to merge into an eLearning management system (Course Mill, BlackBoard, Moodle, etc.) at the click of a mouse. We should be able to sync up performances and exchange information over 3D meta-grids (Such as Second Life or Open Grid). It should be bone-head easy by now to link up compositions with things like Py-Ware (Drill and Choreography design software). We should be able to have a dozen collaborators examine the same score somewhere on the cloud, hear and edit it, and mark it up together in a joint session from anywhere in the world.
Every other industry, from physicians to astronomers have tools to educate, communicate, and collaborate…to build interactive learning environments, to establish digital models for experimentation and testing the theoretical boundaries of ideas that are simply not practical to test in the physical world. While we do have some nice stuff in the music world…we’re still decades behind.
Steinberg and Yamaha have the clout and resources to help bring Musicians into the 21st century. Integration among applications, and common industry-wide protocols are the ground level to making it all possible. Maybe in our lifetime, we’ll be able to have something for Music that’s more like Lectora, Ventura Publisher, Adobe Publisher, etc. but FOR MUSICIANS. Meanwhile, we’re all out here learning a thousand different ways to do things, and spending years to accomplish things that our peers working with other types of ‘information’ can do at a click of a mouse.
Since Cakewalk’s data structure is (presumably) audio and MIDI based and Dorico’s native data structure is (apparently) neither MIDI nor XML based but something new, any integration would, I imagine, involve a pretty complex translator module which, if it is to occur, seems likely to be pretty far down the road.
I have only a marginal knowledge of programming so undoubtedly miss some of the points in this very long thread. However, I do understand from another thread that Dorico already incorporates such a translator module to convert its notation information (which is neither MIDI nor XML) into midi (or midi-like?) information that is required by the playback engine. If the Dorico team are otherwise in favour of the kinds of “integration” talked about here, this might make it less far down the road than we would otherwise expect.
The problem with interchanging data using MIDI is that, to be really useful, you need to know what is going to read it.
If you generate MIDI data that is set up to work with the of expression maps for a specific sample library (like HSO) the data is going to be full of library-specific information like key switches, controller data, etc that is specific to that library. Most likely, none of that will work properly with a different library. The issue is with the sample library you want to use, not with the DAW itself. Within Dorico and Cubase, the information telling the program how to drive the sample library is in the Expression Map files.
Otherwise, the user will spend a lot of time in the DAW unpicking the library-specific MIDI data and replacing it with something different - which rather defeats the point of “good integration”. Or if the transfer only uses the minimalistic General Midi standard, you have to reconstruct all the “expressive” playback in the DAW starting from scratch, which is no better.
Of course some power users will be happy to buy third party software (like Plogue Bidule) and spend time programming it to do the translation for them - but not everybody either wants to do that or knows how without going up a learning curve that doesn’t have much in common with “making music”. And the people who don’t know much about this are the ones who ask questions like “why does my violin part play weird notes that are out of range of the instrument” - answer, because those were meant to be MIDI commands that do key switching etc, but your sound library didn’t recognise them and thought they were notes to be played!
This is basically the same problem as translating human languages. The notion of “translating English into a foreign language” is nebulous until you say which foreign language you mean. For example “I live in Paris since ten years” is a perfectly good and grammatical sentence in French (translated word-for-word into English) but it certainly isn’t English!