Search found 229 matches

Return

Re: Plugins?

We chose Lua for our plugin language because it's simple and lightweight, and you can do a lot with it. You can even create lua bindings for C/C++ libraries, so it's entirely possible that you may be able to use the plugins to link Dorico with other libraries or applications. We'll be looking at the sort of things that users want to achieve from a plugin interface and designing our API accordingly. The Lightroom API is a big influence on our design, as that has a great variety of community-provided plugins, and has stabilised over several major versions.
by PaulWalmsley
Wed May 18, 2016 9:17 am
 
Jump to forum
Jump to topic

Re: Plugins?

I'm thinking more generically than that - we want to ask the question: which classes of plugin do users want? For example:

- Batch processing and macro recording plugins (which need access to the command system - some of this is working already)
- Import/Export plugins (which need access to the low level object models and layout model, and I/O)
- Proof-reading plugins (ditto)
- Content generation plugins, eg for creating scales, worksheets (needs object and score creation ability)
- Score editing plugins, eg for invert, retrograde (needs access to higher level objects)
- Playback plugins, eg for adding/changing controller messages, note duration/velocity (needs access to playback mode and object model)
- Style plugins, eg for adjusting score for 'House style' (needs access to the score library and object model)
- Extensibility plugins, eg for plugging in third party Dlls or applications (needs lua's C/C++ bindings)
- Remote control, for writing controller apps from tablets
- ...


Each class of plugin needs a different type of API. Rather than have a 'kitchen sink' API where the Score object has 400 methods, we'll design the API to reflect the requirements of each of these cases, in a similar way to how the major modes of the application are focussed on that part of your workflow.

In the fullness of time there is the possibility for us to hook Lua scripts into other parts of the app, eg so that you could have your own custom pre-flight checks that happen before printing, playback, etc.
by PaulWalmsley
Wed May 18, 2016 10:34 am
 
Jump to forum
Jump to topic

Re: Flows

A Flow is a (potentially) independent fragment of music. So in the orchestral score case, each movement is a Flow. In the songbook case, each song is a Flow. In the case of a PVG score with a guitar fill box (eg a box that expands one of the parts, or shows a solo line) - the fill box would be a Flow, as would the main score.

Players can be common to all Flows or can be different. This allows for a movement where a second choir joins in. Because a Player has a relationship with one more Flows, when you print the parts it will include all the Flows (movements) that the player participates in.
by PaulWalmsley
Wed May 18, 2016 9:27 am
 
Jump to forum
Jump to topic

Re: Flows

That's all correct apart from a Flow able to be *part* of a movement. In terms of the size of a Flow, it can be as small as a stave fragment with a single note (that's not as useless as it seems - imagine writing tutorial content where you are showing the different types of clefs or key signatures in the Legend).

However, the flow can't really be part of a movement, because the movement is itself a flow. Basically if you have a single 'piece' of music that you want to have displayed and played back as a continuous entity then that is your Flow. We do though hope to have a time filter on a flow so that you can show a fragment of a Flow (it may be this that you're thinking of).
by PaulWalmsley
Thu May 19, 2016 4:31 pm
 
Jump to forum
Jump to topic

Re: Flows

steve_1 wrote:Can anyone please plainly elaborate on "flows" as they relate to files? Can multiple flows exist in a file? Or is each flow an individual file? I'm sorry if this was discussed in detail on another site or page.


All Flows exist in a single file.
by PaulWalmsley
Thu May 19, 2016 5:47 pm
 
Jump to forum
Jump to topic

Re: Flows

Woah, so many questions! Great to see the concepts sparking some interest :D

So this would mean that Flows are not nestable, correct?

Correct.

OK: Let's say I have a larger work, already organized in Flows on the movement level. Now I want to make a suite from this piece, linking several shorter passages together in new order. [begging the question: can I have more than one "full score" within one file?] If I understand Paul correctly, I cannot pull them out as Flows from the movement, since the movement is the Flow already. But could I define new Flows (on the same level as the movements), encompassing the relevant passages, and then arrange those Flows into something new? Basically: Can something be part of several flows, just as players can be common to several Flows?

You are correct in that the content from one Flow can't be recombined into another (aside from copy & paste). Each Flow owns the music within it (however, at the lowest level we store these as blocks, which may provide a means of having 'linked copies' at some point in the future, but they still have to be owned by a single Flow).

Is a Flow necessarily linked to concrete timings? I see how that would be almost unavoidable for anything within one Flow; if it is built from notes and rests it has to have durations (but I could imagine interesting cases where these are strictly relational, without a tempo). However, can two Flows exist within the same file and have no temporal relation towards each other? Or does each flow have a defined start and end moment defined in clock time?

Each Flow is thought to be a single 'piece' of music that is generally assumed to be displayed and played back from start to end. However, where there's more than one Flow we hope to give some control as to how you would want these to be played back - eg play back in Flow order with a 2 bar gap between each, omitting Flow 3 because that's an Ossia. It should be quite flexible.

Also, can I reuse Flows or will they always be single instances? Taking Paul's example of using very short Flows for explanatory purposes: Can I compile a exhaustive collection of snippets to explain extended techniques notation at the start of a score and then, at the start of a new movement, compile a smaller list reusing just the notations relevant to the movement?

Yes, I think so, because there is an additional concept: Music Frames (caveat: this is the development name, I don't know whether that will be the user-facing name). Flows define the content, and Music Frames define how that is to be presented on the page. Music 'flows' through a sequence of Music Frames until it runs out, then it will move on to the next Flow. You can create a new sequence of music frames if you want to reuse the content from a Flow.

Which makes me think what the more suitable way for the understanding of Flows might be: is the Flow concept predominantly a solution to problems of music modelling or to problems in laying out materials?

It's very similar to the concepts of a DTP application, though I'm not sure if they use the same names. In short:

- Flow = a section of musical content
- Music Frame = a box on a page through which music is to be 'flowed', in sequence
- Layout = a visual presentation of a combination of Flows and Players, displayed using a particular page layout. Think: 'Parts'


A picture is worth 1000 words, but I hope you enjoyed these 1000 words...
by PaulWalmsley
Thu May 19, 2016 9:43 pm
 
Jump to forum
Jump to topic

Re: Who's on the Team?

There are a few team members lurking on the list who may introduce themselves, but in summary there's about 12 of us that were part of the Sibelius team for between 2 and 14 years, and we've picked up a couple of new team members part-way through the Dorico project.

I was a developer on Sibelius for many years, between versions 2 and 7. On the Dorico team my main interests are the overall application architecture. My main focus for the coming months is the Playback system. We have some of the company's finest minds in Hamburg on the audio engine part, and I will be doing the integration and many of the other playback features. I've also got an interest in scripting - I've put in the current Lua system and binding mechanism, though we've yet to decide on the API (see the other thread on this: https://www.steinberg.net/forums/viewtopic.php?f=246&t=97329&p=538339&hilit=lua#p538470 )
by PaulWalmsley
Mon May 23, 2016 9:25 am
 
Jump to forum
Jump to topic

Re: Midi files and also Performance settings

Just to add to Daniel's response, the quantisation algorithm I've implemented (which isn't yet fully wired into the application) should do a reasonable job in most cases (hopefully better than Sibelius's, which I also had a hand in :-)

However, if you do have very complex MIDI files with nested tuplets or uncommon ratios, or complex rhythms within the tuplets, then it's unlikely that a quantisation algorithm will do a decent job. Part of the problem is the limited resolution of a MIDI file which means the tuplet positions can't be specified exactly, and the other part is the Combinatorial Explosion(TM) of possible tuplet combinations that a quantiser would have to search through in order to identify the best one.

In general I would recommend that if you have files with complex tuplet requirements that you should try to import via MusicXML instead if possible.

We intend that we'll preserve the actual note onset time, duration and velocity and preserve this within the notated note. This should also be user-editable in Play Mode.
by PaulWalmsley
Wed May 25, 2016 1:22 pm
 
Jump to forum
Jump to topic

Re: Expression maps from Cubase in Dorico?

I think Daniel is right here - as it stands I think there is extra data Dorico needs above that in a Cubase expression map file. However it should be possible to import a Cubase file which will get you 90% of the way there. I already have code to convert them.
by PaulWalmsley
Fri May 27, 2016 9:14 am
 
Jump to forum
Jump to topic

Re: Voices or layers

When playback does become a reality, I think many users will be pleased if a stave (or grand stave in particular) could contain several instrumental "layers", each with their own sound, and if each layer was polyphonic.

The low level playback code should support the option of independent voices for an instrument, which can be routed separately. As with many other things, it's quite possible that the support won't be there in the initial version to control this from the UI as it adds an extra layer of complexity, but please be assured that we are thinking about this use case.
by PaulWalmsley
Wed Jun 01, 2016 9:33 am
 
Jump to forum
Jump to topic

Re: Flows

They do have their own timelines. They can either be:
- completely independent pieces of music within the same document
- sections of music that don't play back at all (eg for a music frame that contains a legend, guitar fill, etc)
- consecutive songs/movements

I don't think it's likely that you will be able to overlap the playback of them, though in time when we get to support timecode/hitpoint annotations I expect that each Flow can have its own timecode start time (which may overlap)
by PaulWalmsley
Thu Jun 02, 2016 2:30 pm
 
Jump to forum
Jump to topic

Re: Flows

I'm not sure I understand what you mean. Each Flow will have its own 'bar 1', and you will also be able to add bar number changes where you need them (so they don't actually need to be bar 1 at all). Does that answer your question?
by PaulWalmsley
Thu Jun 02, 2016 2:44 pm
 
Jump to forum
Jump to topic

Re: 2 question about the midi editor

We are aiming to get a tempo track into Play mode. This will let you edit the tempo of each tempo event. eg 'Lento' will have a default tempo, but you can override the tempo of each instance. If you add extra tempo changes then these won't be printed in the score, but they will show as Signposts (I think Daniel has shown an example of these elsewhere).

We aim to have a general MIDI event object that can be inserted on each voice/instrument stream that can be used for inserting arbitrary program changes, notes, etc.
by PaulWalmsley
Fri Jun 03, 2016 10:24 am
 
Jump to forum
Jump to topic

Re: Assignment of VST Instruments

The reason we don't need the notation data is that notation events in Dorico have 'Playing Techniques' associated with them, eg tremolo, trill, accent staccato. The playback will find the correct switch in the expression map to play it.

Dorico will be able to find the correct switch in the expression map depending on the combination of techniques at that point. You don't need the Arco (which we call 'natural') for all combinations, so that you can just define' vibrato' and it will use that if it has a higher priority than any other techniques at that point. As an example, if you have mute and vibrato at the same time then it will pay using the one with the highest priority. If you have a 'mute + vibrato' sound available then this will be used instead. I hope that's reasonably clear.
by PaulWalmsley
Sat Jun 04, 2016 7:00 pm
 
Jump to forum
Jump to topic

Re: Assignment of VST Instruments

Ok, well I'll take this up with Daniel
by PaulWalmsley
Sat Jun 04, 2016 11:23 pm
 
Jump to forum
Jump to topic

Re: Assignment of VST Instruments

That's great - we'll look into the options for sharing community content.
by PaulWalmsley
Mon Jun 06, 2016 9:46 am
 
Jump to forum
Jump to topic

Re: Assignment of VST Instruments

Yes and no: the key part in the process is that you will need to create both Playback Template and Expression Maps. (We may be able to have some way of sharing Expression Maps within the community, which would minimise the amount you need to do, but this may not be practical for things like VSL that can be set up in a totally custom manner).

The Expression Map tells Dorico how to play arco, pizz, staccato, etc via keyswitches or controller changes. The Playback Template is effectively a blank score with all the plugins set up how you like them (including EQ/compressor/insert/Send FX settings), and your preferred sounds already loaded in each channel. You then assign each Dorico Instrument to your preferred plugin and channel, and set the expression map for it. If you wish you can also assign different techniques to a different channel, eg if you prefer a different violin tremolo.

What we don't have the ability to do is automatically load the correct patch, because this would require custom code for every different plugin. We will have this ability for Halion because it's our own.
by PaulWalmsley
Mon Jun 06, 2016 9:11 am
 
Jump to forum
Jump to topic

Re: Syncing with audio via MIDI or BPM

The MIDI standard stores tempo in microseconds per quarter note. 180bpm (for instance) cannot be exactly represented in this format - it's 60,000,000/180 = 333,333.333.... microsecs/qn. If you convert this back to bpm you get 180.000180. When you set a tempo of 180 bpm in most sequencers, actually you'll be setting it to 180.000180, but you won't see this in the UI.

In Sibelius there is a conflict because tempo events are interpreted directly from the tempo text, so it has to either store as 'q=180' or 'q=180.000180'. Many people don't like seeing that number of decimal places, so you can reduce them, but then the tempo value is wrong...

In Dorico we get around these problems by treating tempo changes as a proper event type, whose text can be independent of its internal value. So we can store the value at the full microsecs/qn resolution and display the value to the user's preferred number of decimal places.
by PaulWalmsley
Tue Jun 07, 2016 8:39 pm
 
Jump to forum
Jump to topic

Re: Assignment of VST Instruments

This will necessarily be different to Sibelius. Older versions of Sibelius (v4-v6 I think) used the Kontakt Player and was able to load sounds via a proprietary API. Version 7 was able to load sounds in Structure (the Avid sampler plugin) via a proprietary API. Dorico will load sounds in Halion via a (you guessed it...) proprietary API. We don't have access to the APIs used by other products, and at present I don't believe there's any standard means in the VST spec of loading different presets into each channel.

Historically we know that advanced plugin users have been frustrated by some of the limitations they experienced in Sibelius which did try very hard to do the 'it just works' thing at the expense of letting you do what you want. We've made a conscious decision in Dorico to make the default user experience with the bundled Halion content be 'just works', but if you want to make your own decisions then we aim to give you that power and flexibility, at the expense of requiring manual setup to have things just how you want them.
by PaulWalmsley
Mon Jun 06, 2016 4:55 pm
 
Jump to forum
Jump to topic

Re: Questions on Playback Devices

VST3 has been around for a few years now. Cubase currently loads VST2 plugins but VST2 is no longer officially supported. It's a totally different architecture that was introduced to fix some longstanding problems with VST2: http://www.steinberg.net/en/company/technologies/vst3.html

Expression Maps have some overlap with Sibelius sound sets, in that they will contain the key and controller switch information, but they will be structured quite differently (and hopefully in a simpler way than the SoundID stuff).
by PaulWalmsley
Wed Jun 08, 2016 5:06 pm
 
Jump to forum
Jump to topic

Re: Assignment of VST Instruments

@Rob Tuley: though I'd want the sounds, once set up, to be loaded automatically.

Hopefully this should be achieved by our Playback Template mechanism. Once you've done the hard work of setting up all your favourite plugins, patches and expression maps up for your regular types of ensemble, then you will be able to import it into your projects.
by PaulWalmsley
Wed Jun 08, 2016 1:42 pm
 
Jump to forum
Jump to topic

Re: Questions on Playback Devices

The VST2 and 3 specs provide different forms of being able to query a list of the *available* patches provided by the plugin, but what they don't do is allow you to query which patch is loaded into each channel, or load specific sounds into each channel. This is what you need in order to be able to do the automatic loading of sounds. The patches loaded into Kontakt aren't accessible via the VST interface.
by PaulWalmsley
Wed Jun 08, 2016 9:49 pm
 
Jump to forum
Jump to topic

Re: Dorico video presentation w/ better audio?

I saw him in the park only last week!
by PaulWalmsley
Thu Jun 09, 2016 8:12 am
 
Jump to forum
Jump to topic

Re: Sound Libraries

Yes, you can load in all your preferred sounds and then tell Dorico via an Expression Map which 'Playing Techniques' (including articulations) are supported by each patch and how to access them (eg keyswitch, MIDI CC). You can then choose how to assign each playing technique for each instrument. So if you want to use the arco and pizz from one patch and the tremolo from another then this can easily be done.
by PaulWalmsley
Fri Jun 10, 2016 9:45 am
 
Jump to forum
Jump to topic

Re: Plugins?

This should be possible, as every object in the score has a property table, and this should be accessible for plugins to add in custom data, which will then be preserved in the file. I hope that this will open up many opportunities for editorial or analysis type plugins.
by PaulWalmsley
Fri Jun 17, 2016 9:29 am
 
Jump to forum
Jump to topic

Re: Plugins?

The scripting will be in Lua and so you should be able to use any networking library that can work with lua (eg see http://w3.impa.br/~diego/software/luasocket/). I expect that you will be able to send commands to Dorico via the scripting interface. However, if you want to build a full-featured remote control mobile app then this would need a far more detailed API than just the ability to send commands. This is a very interesting request though, so I'll add 'Remote Control API' to the list of plugin feature areas we'll look at (see the top of this thread).
by PaulWalmsley
Mon Jun 20, 2016 11:59 am
 
Jump to forum
Jump to topic

Re: Plugins?

Thanks Robert, that's very interesting. If there's an OSC-Lua binding then that may be the sort of thing that will be very simple to accomplish in Dorico. Dorico has a simple URL-like mechanism for all its internal commands, so that they can be represented as a string and provide a means to pass parameters - eg "Window.SwitchMode?WindowMode=kPlayMode"

The fun starts when we think of how we can send useful status info back to the controller. I will certainly give the remote control part of the API some thought when we come to investigate this.
by PaulWalmsley
Mon Jun 20, 2016 9:03 pm
 
Jump to forum
Jump to topic

Re: Drawing CC-curves

Dorico will work somewhat like you suggest. You'll get some degree of automatic playback of dynamic from hairpins and other dynamic objects, but we plan to allow you to override these or add your own control points to modify the dynamic 'profile'. This will then be translated appropriately under the hood so that sounds that use CC1 rather than velocity will use that, and you won't need to care. If you then change to use a different sound which uses a different controller then that'll be dealt with automatically.
by PaulWalmsley
Fri Jun 24, 2016 11:21 am
 
Jump to forum
Jump to topic

Re: Multiple Instruments = One Staff?

Hi Sean,

We're aiming to support these kind of use cases (though we're not sure yet to what extent in the initial release). We know that many users want to be able to plug in their own combinations of VSTs, and they want to use 'arco' samples from this library and 'pizz' from another. So what you will be able to do is configure the rack with all the VSTs you want to use, load your preferred presets, and then tell Dorico the Expression Maps or 'Playing Technique' for each channel of each VST. We call each destination an 'Endpoint' (basically the plugin + channel + expression map).

You can then map each of your source Instruments to the Endpoints you want to use. So you could load an arco patch in one slot and a pizz in another, then in the Instruments control you just point it at these two endpoints. When we come across the pizz in the score we'll switch playback to the other endpoint. In the score you will just have one source stave, but playback can be split across many endpoints.

I'm not sure at the moment how best to support switching to another sample library just for a different section. It might be a matter of making a custom playing technique for it. The same might be true for the multiple spiccato samples.

You should be able to have per-voice playback routing, so that should give you a way achieve the ensemble/solo effect, or that could probably be also done with a playing technique change.
by PaulWalmsley
Fri Jun 24, 2016 4:52 pm
 
Jump to forum
Jump to topic

Re: Creating various versions of a piece

One of the workflows that we had in mind while we were developing the Flows and Layouts concept was that you might be producing (eg) a choral piece with orchestra, but you also wanted to have a piano reduction for rehearsals. You would then create the full score Layout and exclude the rehearsal piano from it, and create a new Layout for piano + choir. So you can maintain it all inthe same document.
by PaulWalmsley
Thu Jun 30, 2016 1:02 pm
 
Jump to forum
Jump to topic

Re: How does Dorico compare to Cubase in rendering music

We hope to have the ability to edit tempos similar to automation. I've written the tempo event code so that tempo text and metronome marks affect the tempo map, but we can have additional tempo events that aren't drawn in the score (it's possible they may draw as 'Signposts', which we use for drawing annotations on the score that don't get printed out). So this should give the ability to customise rit and accel behaviour.
by PaulWalmsley
Fri Jul 01, 2016 9:26 am
 
Jump to forum
Jump to topic

Re: Units of measurement

I can see how the ability to enter physical dimensions with a "cm" or "in" suffix would be very useful - Photoshop supports this. That probably would be quite simple to do with our model.
by PaulWalmsley
Fri Jul 22, 2016 7:05 pm
 
Jump to forum
Jump to topic

Re: Playback of sustain pedal markings

The key thing here is that the pedal markings will be stored at their rhythmic positions, and that defines exactly the point that they will play back, rather than their drawn position. We expect that you will be able to change these easily, and set the visual offset (dx) independently to get both the played effect and drawn effect that you want.
by PaulWalmsley
Fri Aug 05, 2016 1:56 pm
 
Jump to forum
Jump to topic

Re: sempre

That depends. If you can describe an absolutely unambiguous set of rules for the point at which the instruction is no longer valid then I'd say 'probably yes'. However, coming up with an unambiguous set of rules for anything that does the right thing 99% of the time - that's the hard bit...

(actually, not strictly true, the hard bit is turning that into C++...)
by PaulWalmsley
Fri Aug 05, 2016 1:51 pm
 
Jump to forum
Jump to topic

Re: Install and Uninstall questions

Dorico does depend on other Steinberg software, so the full installation does necessarily install the audio engine, licensing components, VST plugins, HALion content, etc. However, the last time I tried to uninstall, the uninstaller did a pretty good job of removing pretty much everything.
by PaulWalmsley
Tue Aug 30, 2016 9:16 pm
 
Jump to forum
Jump to topic

Re: Install and Uninstall questions

What about file compatibility? Will minor updates use a file format that's compatible with older versions, or at least be able to back-save?


We've thought very carefully about file formats and we will try to keep files portable between minor versions so that you _should_ be able to read a file created in 1.x.10 in version 1.x.1.

However, do bear in mind that as we add features in minor versions, there's no way of older versions knowing how to interpret the extra data for them, so they will ignore it (but they at least should carry on loading the file). So if you create something in a newer version using a new feature, then open it in an older version and save, then that data will be lost. As with all software (especially very new software whose features are growing by the day!), if you are relying on 'round-tripping' between different machines or different contributors then it's worth ensuring that everyone is either using the same version.
by PaulWalmsley
Wed Aug 31, 2016 9:28 am
 
Jump to forum
Jump to topic

Re: Transport toolbar

We have several playback functions already:
- play from the current position (the 'play head'),
- play from the selection,
- play from the last place you started playback from,
- play from the start of the current flow and
- play from the start of the score

Hopefully that should give you a few options...
by PaulWalmsley
Thu Sep 01, 2016 5:56 pm
 
Jump to forum
Jump to topic

Re: Install and Uninstall questions

There is only one version at the moment, so it's hard to say! I expect that there will be some kind of 'save as version X' feature in the future, but until we get as far as working on version 2.x it's hard to give a definitive answer as to how it will work.
by PaulWalmsley
Thu Sep 01, 2016 5:54 pm
 
Jump to forum
Jump to topic

Re: Transport toolbar

In the main toolbar we have just one button for playback. I think the default behaviour is that it plays from the current playhead position. This is consistent with behaviour in most DAWs. In the separate transport window there are space for more buttons and we have two playback controls on there, however I can't remember which functions we assigned to them. However you can bind keyboard shortcuts to any of these functions.

We do take our UX design very seriously and a lot of thought goes into the layout and design of the user interface, the modality of the application's operations, and how the workflow of a project passes through the various modes. Our product designers are keenly aware of modern UI design principles.
by PaulWalmsley
Sat Sep 03, 2016 11:37 pm
 
Jump to forum
Jump to topic

Re: Transport toolbar

I think you will find that very, very few software products you use in your day-to-day life have that level of HF research in them, largely because it's incredibly specialised and hugely expensive. Aside from Microsoft, Apple, Google and Adobe, very few companies have the resources for that kind of analysis (and even then, I'll bet they haven't done research with eye trackers -- that's the sort of thing you'd only find on software for jet fighters).

What we *do* have in the team is 100 years of experience of developing music notation software, even more experience of being software end users in our daily lives, and the hundreds of years of music experience of the many composers, arrangers, engravers and copyists that have passed through our door over the last few years. The design of Dorico is the distillation of all that, and many, *many* hours of discussion in the team (often quite heated, as we are all incredibly passionate about it!).
by PaulWalmsley
Tue Sep 06, 2016 8:54 pm
 
Jump to forum
Jump to topic

Re: Unusual scores

We tested our nested tuplet code specifically with some Ferneyhough!
by PaulWalmsley
Thu Sep 22, 2016 1:11 pm
 
Jump to forum
Jump to topic

Re: A question about Synthesizers

This should be a very simple operation in Dorico. This is still work-in-progress, but the steps would be something like this:

- Create a new Player and choose 'Synthesizer'
- Load your preferred VST Instrument in the rack
- Choose the sound you want
- Switch to Play Mode and in the routing dropdown for the Instrument, select the VST Instrument you added.
- ...that's it!

You should also be able to use different sounds, and there are two mechanisms for this. One is to add more Instruments to the Player and then Dorico will use an instrument change to play both sounds (which could even be with different plugins). The other is to use Playing Techniques which will be able to trigger control changes or program changes. For instance a 'Motor on' playing technique for Vibraphone can switch to the appropriate patch.
by PaulWalmsley
Mon Oct 03, 2016 9:36 am
 
Jump to forum
Jump to topic

Re: A question about Synthesizers

We don't yet have support for percussion, but we are aware of the complexities that arise with multiple players sharing multiple instruments, and also the circumstances where you may also want them notated on the same stave. Daniel may be able to chime in here with more detail, but the general answer is 'it's complicated and we're trying to find the best way to approach it'.
by PaulWalmsley
Thu Oct 06, 2016 1:25 pm
 
Jump to forum
Jump to topic

Re: Integration with Cubase

In the fullness of time we will have extensive scripting support in Dorico (Lua is currently integrated into our core libraries, but isn't currently accessible as our score model API needs a lot of work). This should open up plenty of interesting opportunities for import/export into custom formats for script developers.

It really isn't the case that it would be straightforward to write MIDI inside SVG in Dorico as the playback and layout engines arecompletely separate subsystems.
by PaulWalmsley
Thu Oct 06, 2016 4:16 pm
 
Jump to forum
Jump to topic

Re: Integration with Cubase

I can't see this working. The representations required for the visual, semantic and playback properties of music notation are several orders of magnitude more complex than can be represented by something like SVG and MIDI. Even for playback MIDI itself is woefully inadequate (note expression? routing? 'expression map'-type data?, device descriptions?, sound loading?). Similarly SVG is great at describing a vector graphic, but has no semantic meaning above that. MusicXML *does* describe a page->system->staff->voice->chord hierarchy (of sorts), but there are many problems with that.

I wish you luck with this SVG-MIDI project, but I can't see how it would solve any of the problems that we currently face. Even if you were to come up with such a standard, the complexity in implementing it would be enormous.
by PaulWalmsley
Thu Oct 06, 2016 1:38 pm
 
Jump to forum
Jump to topic

Re: A question about Synthesizers

We will certainly take this on board - I can see the value of it as a feature.
by PaulWalmsley
Thu Oct 06, 2016 8:58 pm
 
Jump to forum
Jump to topic

Re: Integration with Cubase

As you will appreciate, with very complex software bases It's Not Quite That Simple. Although you see the score scrolling in time with the music, that in no way implies that the playback code 'knows' about the drawn notation data in any way -- they are completely separate subsystems. However there are a handful of isolated interfaces that do convey some limited information between the two, such as the playback line.

For a start there's a many-to-many relationship between a drawn note and a played MIDI note...
by PaulWalmsley
Thu Oct 06, 2016 11:23 pm
 
Jump to forum
Jump to topic

Re: Integration with Cubase

Just my personal opinion here, but I can't foresee Dorico (or any other mainstream notation application) dealing with these more esoteric notations: they would be far better served by with by custom applications that deal exclusively with them. We have around 1 million lines of code that are required to deal with Conventional Western Music Notation (excluding the many common notation features we haven't yet implemented) - could you imagine the scale of the complexity required to deal with the many additional variations?

I don't expect to be a One Tool To Rule Them All notation system - that simply isn't our focus.

As it stands, there isn't a standard format for data interchange of non-standard notations. I've never seen one proposed. The problem is that something like SVG + MIDI is devoid of semantic structure which makes it very unsuited to an interchange format. However, the hope is that our scripting interface will open up possibilities for third parties to develop such formats.
by PaulWalmsley
Thu Oct 06, 2016 9:18 pm
 
Jump to forum
Jump to topic

Re: File corruption and rhythmic corruption

It's hard to say really whether you would encounter this with Dorico or not. It's not something that we've really seen to date. We do have a very different data model to Sibelius, and a big difference is that Dorico can cope much better with things like unisons. We have a more flexible model for representing tuplet positions exactly (whereas Sibelius rounds them to the nearest 1/256 of a beat), and we've done a lot of work to ensure that tuplets are a first-class citizen and can be easily edited.

There is always a problem when the application can't perfectly notate what was played in, but the user wants to ensure that it will play back the same way. The application has to put the notes *somewhere*. MIDI import is still at an early stage - there's more in the pipeline for improving the rhythmic/tuplet interpretation.
by PaulWalmsley
Tue Oct 11, 2016 8:50 pm
 
Jump to forum
Jump to topic

Re: File corruption and rhythmic corruption

I certainly haven't seen any problems like this. Because of our much improved tuplet handling it means that notes and tuplets can get moved around a lot and we always know their exact rhythmic position, so they never get 'lost'.
by PaulWalmsley
Wed Oct 12, 2016 2:47 pm
 
Jump to forum
Jump to topic

Re: Playback of 2+ voices on one staff, now and in the futur

Currently Dorico just plays back each instrument on a separate VST channel, so that a player with multiple instruments will have them routed independently.

However, the core playback code has been written so that it is also able to play voices independently, just currently there's no way to control this. It's something we hope to get in place very soon.
by PaulWalmsley
Thu Oct 13, 2016 11:23 am
 
Jump to forum
Jump to topic

Re: Playback of 2+ voices on one staff, now and in the futur

The usual relationship between player and instrument is for the cases you describe (which in the score would appear as an instrument *change*), but it can also cover cases where both instruments are being played at the same time (typically for percussion, for instance). I imaging that the combination of multiple instruments, multiple voices and expression map support will give users lots of interesting options for playback.

Take a look at the discussion on this other thread a few days ago: https://www.steinberg.net/forums/viewtopic.php?f=246&t=102793
by PaulWalmsley
Thu Oct 13, 2016 2:10 pm
 
Jump to forum
Jump to topic

Re: A question about Synthesizers

Indeed, you've hit the nail on the head - ultimately whatever choice the application makes, it may not be what the user intended. If the application offers the user the choice...? Well, can you imagine the complexity of a dialog that controls the routing of X different players holding Y different instruments which may alternate N times during the movement..?
by PaulWalmsley
Thu Oct 06, 2016 2:51 pm
 
Jump to forum
Jump to topic

Re: Large Time Signatures for Film Scores

I plan to switch my career to transcribing music found on ancient Sumerian tombstones. I hope that Dorico is fully optimized for this notation -- if it really is music notation -- and that it will play back correctly according to Sumerian performance practice. I'm sure that success or failure is riding on this.

I'm afraid this will be unlikely in the initial release. Unfortunately there is a huge schism within the Sumerian tombstone community about the best way of handling rest positioning, and it's just not practical for us to support all the options. It's likely that we'll wait for the appendix in the 2nd edition of Elaine Gould's book before we can commit.
by PaulWalmsley
Fri Oct 14, 2016 11:24 pm
 
Jump to forum
Jump to topic

Re: Surely, it must feel good!

We wouldn't have got such a great product out of the door without the amazing trust that Steinberg showed in the team. We have a really great working relationship with our colleagues in Hamburg as they care as much about their products as we do.
by PaulWalmsley
Fri Oct 14, 2016 11:29 pm
 
Jump to forum
Jump to topic

Re: Large Time Signatures for Film Scores

A huge amount of debate goes into all the decisions about the relative priorities, and none of the decisions are taken lightly. Every feature that goes in is at the cost of another that has to be pushed back. Our focus has been on getting the fundamentals right so that we can easily build on them to support new notation or playback features in the future. We are very aware of the requirements of different groups of users and that will guide our timetable for the future.
by PaulWalmsley
Sat Oct 15, 2016 10:31 am
 
Jump to forum
Jump to topic

Re: MIDI input suggestion for future updates

Dorico does echo the note you played so at least you can hear that you are in the wrong octave straight away.
by PaulWalmsley
Sat Oct 15, 2016 10:38 am
 
Jump to forum
Jump to topic

Re: Surely, it must feel good!

It's certainly the case that everyone on our team is a musician of some description: composers, performers, choir masters, home noodlers (that's me). Everyone I've met in Hamburg fits the same profile - the company does breathe music.
by PaulWalmsley
Sat Oct 15, 2016 10:36 am
 
Jump to forum
Jump to topic

Re: Large Time Signatures for Film Scores

Well that would depend if they were a Big-endian or Little-endian Sumerian.
by PaulWalmsley
Sat Oct 15, 2016 8:28 pm
 
Jump to forum
Jump to topic

Re: VE Pro 6

The expression map support is something that we hope to provide very soon. Our expression map will be an extension of Cubase's format, so that if you already have your own maps then you should be able to import them, which will get you most of the way there. However there's some extra data that we'll be able to store in there to give more control over playback. Also Dorico's data model is very different to Cubase in that it's more about Players and their Instruments, and the Playing Techniques they use, which can be mapped on to one or more devices. Eg consider if you had a violin patch that you used, but you preferred the pizz sounds from a different library. That's the kind of thing you'll be able to do.
by PaulWalmsley
Sat Oct 15, 2016 8:26 pm
 
Jump to forum
Jump to topic

Re: Two USB Dongle -same computer

I don't know the definite answer to this, but I run with 2 dongles on my computer every day without any problems. Each has a different set of licences.
by PaulWalmsley
Sat Oct 15, 2016 10:02 am
 
Jump to forum
Jump to topic

Re: VE Pro 6

We can't give any specific dates, but this is something that we consider to be a very high priority.
by PaulWalmsley
Sun Oct 16, 2016 10:53 am
 
Jump to forum
Jump to topic

Re: Problem with dynamics

There is a known bug in 1.0 where the dynamic marking at the end of a cresc results in a sudden jump. I've fixed this in our current internal build and will be in the next update.
by PaulWalmsley
Wed Oct 19, 2016 2:05 pm
 
Jump to forum
Jump to topic

Re: Music XML... what to expect

Playing techniques are at quite an early stage and we'll be working on improving these very soon.

Dynamics are a tricky one as it's hard to get a balance between importing them as a Dynamic Group (which groups dynamics that are close together in time so they are level vertically), and allowing them to adapt locally (eg so they can shift out of the way of stems, etc). In MusicXML there's no such semantic structure which can make it hard to do the Right Thing (whatever *that* is...). It is often a quirk of rhythmic positioning whether they import as a group or not, which is why it appears erratic.
by PaulWalmsley
Thu Oct 20, 2016 4:40 pm
 
Jump to forum
Jump to topic

Re: UI responsiveness is really bad

We have already made quite a few improvements to responsiveness during note input and navigation. There's plenty more scope for further improvements as we progress.
by PaulWalmsley
Thu Oct 20, 2016 7:08 pm
 
Jump to forum
Jump to topic

Re: Can't open file

If you have some files you can't open then zip them up and attach here, or if you prefer PM them to me and I'll see what I can do.
by PaulWalmsley
Thu Oct 20, 2016 9:42 pm
 
Jump to forum
Jump to topic

Re: Playback issue (Doesn't play back, or partial playback)

You can PM it to me. What you need to do:
- go to Play mode
- in the VST Instruments panel press 'e' to show the HALion windows
- the order of instruments should match those in the score, so you should be able to see where the clarinet is
- select the row containing clarinet patch in the HALion window
- press the virtual keyboard -you should see a bit of VU meter activity
- if it's sounding but really quiet then try turning up the mod wheel. if that has fixed it then we know it's a modwheel/note velocity issue
- You could also try loading in a different clarinet patch.
by PaulWalmsley
Thu Oct 20, 2016 9:48 pm
 
Jump to forum
Jump to topic

Re: Articulation samples not working or...?

Tremolos, trills, articulations, etc - these don't yet play back, but it's something we're working on right now.
by PaulWalmsley
Fri Oct 21, 2016 9:45 am
 
Jump to forum
Jump to topic

Re: Many BlueScreen crashes

Firstly let me explain a little about Bluescreen crashes:
Bluescreen crashes when something inside the OS crashes. Applications aren't permitted inside the OS -- only drivers. 90% of bluescreen crashes are caused by buggy drivers. Applications call OS routines to do things like paint on the screen or play sound. The OS routines ask the drivers to do that. If an application crashes it will exit but the OS will continue. If a driver crashes then it takes everything down with it.

Ok, so why is it only Dorico that crashes?
Well, Dorico touches lots of different areas of the OS - soundcard, MIDI, display drivers, font handling, networking... It may be that we're calling functions that none of your other applications call.

So what can I do about it?
First thing to try is the built-in support in Windows 7 - see the article here: http://www.makeuseof.com/tag/windows-7-reliability-monitor/ . If you do 'Check for solutions' then that will see if that particular crash is a known issue, and may point you to updated drivers.

If that doesn't help then you could try a separate tool such as WhoCrashed (http://www.resplendence.com/whocrashed) which will show you the driver that is misbehaving.
by PaulWalmsley
Fri Oct 21, 2016 2:00 pm
 
Jump to forum
Jump to topic

Re: Playback issue (Doesn't play back, or partial playback)

Yes, I would wait for the next update before trying any 3rd party VSTs as that should have much better support for them.
by PaulWalmsley
Fri Oct 21, 2016 5:40 pm
 
Jump to forum
Jump to topic

Re: UI responsiveness is really bad

MYou can see that the number of threads in Dorico does not increase which means that Dorico does not use parallelization a lot.

In fact, Dorico uses parallelism quite extensively. What is very difficult though is that much of music layout is an inherently serial problem. There are some aspects that can be done in parallel (eg computations on rhythms on independent staves), however there are many 'synchronisation points' which forces things to be serial again. Simple example: adding a single note in bar 1 may cause a bar to be pushed onto the next system, and that can have a cumulative effect that causes the entire score to be reformatted. You therefore have an effectively serial problem (you can't work out the layout of bars in parallel because they are affected by those that go before it. This is a very difficult computational problem.

Dorico was written from the ground up to benefit from parallelism where it can usefully be applied. Every edit you make to the score may be processed in a large number of threads if there is a benefit to doing so. We try to keep all work to other threads to keep the UI responsive.

Also, do remember that Dorico is doing a huge amount more work than any other notation package in order to apply the large number of rules, and resolve all the collisions, route the slurs, etc, and there necessarily a computational cost to this.

Performance is something that we will improve constantly. Many of the current problems are things like dealing with cache invalidations which currently are quite pessimistic to ensure that the appearance is correct, but which can be optimized quite easily once we've verified that it is safe to do so.
by PaulWalmsley
Fri Oct 21, 2016 10:50 am
 
Jump to forum
Jump to topic

Re: 'cresc.' creates a hairpin

One of the major design decisions in Dorico was that we wanted to move away from the Sibelius-style way of doing things where the user enters text for dynamics, tempo, etc and then the application tries to interpret that when you play it (remember needing all those '~' symbols in Sibelius?). It's all just text, just with different styles and implied behaviours.

Our goal instead was to capture the musical semantics of every item in the score, as best we could, so that it could obey the desired rules for formatting (eg the way that tempo items know where to align horizontally) or playback.

Dorico does try to interpret a range of common dynamic or tempo markings, where it will try really hard to extract the semantic information, but preserve the visual appearance. It won't work for all cases however, and yours is one such example. We can look at beefing up the parsing to try to preserve what you had typed more gracefully.
by PaulWalmsley
Fri Oct 21, 2016 11:54 pm
 
Jump to forum
Jump to topic

Re: reading this forum has changed my mind

Please do bear in mind that performance tuning and optimisation is something that we will do continually. There is plenty of scope for caching, invalidation tuning, etc. Initially our emphasis has to be that the score appearance is always correct (a risk of caching is that you trade speed for stale data, which would result in the score not displaying correctly -- we judge that that is a trade-off that most users would not be happy with). We've developed Dorico with quite 'pessimistic' caching (to ensure correctness) that we can now try to loosen up.

We've already made some very positive improvements to the perceived lag during note input and navigation, and we'll continue to improve that. If there are particular operations that you find to be slow then do let us know. We do know about (and are looking at) player deletion and repitching of selections. We are very aware that performance with large scores can be laggy, and we're working to fix it.
by PaulWalmsley
Fri Oct 21, 2016 11:24 pm
 
Jump to forum
Jump to topic

Re: UI responsiveness is really bad

We've fixed this particular case. It wasn't due to the speed of redrawing the score - rather it was the refreshing of the ui that was slow
by PaulWalmsley
Sat Oct 22, 2016 11:46 am
 
Jump to forum
Jump to topic

Re: Scripting example

The scripting support is incredibly rudimentary at the moment. We've got the Lua engine embedded in Dorico, but there's still a lot to do on getting the right form of the Api. There is a thread somewhere else on the forum where I talk about our plans in a bit more detail. At the moment though we do use the scripting engine to implement the Macro function in the script menu, but not all functions can be supported because many of them require extra parameters.

In short, scripting is something that we will come back to and we'll solicit feedback from the community on the kind of things they need in an API
by PaulWalmsley
Sat Oct 22, 2016 7:20 pm
 
Jump to forum
Jump to topic

Re: Disabling the audio engine

Not currently, but we will have the ability soon to have manual playback configurations which will effectively prevent the engine from loading any plugins.
by PaulWalmsley
Sat Oct 22, 2016 8:38 pm
 
Jump to forum
Jump to topic

Re: 'cresc.' creates a hairpin

Quite possibly. Nothing is set in stone just yet!
by PaulWalmsley
Sat Oct 22, 2016 10:25 am
 
Jump to forum
Jump to topic

Re: Making this forum easier to use?

Might I suggest that whilst we have just the one forum that it would be generally helpful and informative to think about the subject line before starting a new post. One such format is: 'Bug: copy/paste snarfles the udon' or 'Crash when reticulating splines in a new project', 'Feature request: Dorico needs a built-in mail client'

Less helpful subject lines are things like 'Another bug', 'oh no, not again' and 'It was the Easter bunny'.

Good subject lines help us distinguish those containing problems that still need to be diagnosed from other more discursive posts, and these will also show up much more easily in searches. Every time we answer the same question again it reduces the amount of time we have available to fix the bug that the poster was complaining about...
by PaulWalmsley
Sun Oct 23, 2016 11:12 pm
 
Jump to forum
Jump to topic

Re: UI responsiveness is really bad

These are all cases that we're aware of and working to improve.
by PaulWalmsley
Sun Oct 23, 2016 9:49 am
 
Jump to forum
Jump to topic

Re: Crashing on Save

Hi Lee,

I've taken a look at the logs, and it's the Dell Backup and Recovery component that is crashing. This is likely to be a shell extension that hooks into the Save dialogs of all applications. If there's a crash in that then it will take down the application that is running. If you are using this for backup then in the first instance I would suggest updating it - there's a newer version at http://www.dell.com/support/home/uk/en/ukbsdt1/Drivers/DriversDetails?driverId=GX7TX . If you aren't using it then I'd recommend uninstalling it.

Loaded symbol image file: DBROverlayIconBackuped.dll
Image path: C:\Program Files (x86)\Dell Backup and Recovery\Components\Shell\DBROverlayIconBackuped.dll
Image name: DBROverlayIconBackuped.dll
by PaulWalmsley
Mon Oct 24, 2016 10:08 am
 
Jump to forum
Jump to topic

Re: Tuplets

I haven't tried this myself, but I *think* you can create your own shortcut to your desired tuplet ratios. The command is:

NoteInput.StartTupletRun?Definition=4:3

It's likely you won't be able to edit this in the shortcut editor as it can't deal with every function that takes parameters, but you should be able to edit the keycommands.json file that you'll find in your AppData / Application Support folder.
by PaulWalmsley
Mon Oct 24, 2016 9:44 pm
 
Jump to forum
Jump to topic

Re: Can't open file

If you have projects that you would like to open then I have a script you can use to remove the problematic audio engine data from the file.

Just unzip the script to the desktop and in terminal type:

cd Desktop
sh ./enginedata_remover.sh name_of_my_file.dorico
by PaulWalmsley
Tue Oct 25, 2016 1:53 pm
 
Jump to forum
Jump to topic

Re: Audio Engine Process Died crash log

I've logged this internally (ref: AD-246). Our audio engine specialists are currently away, but they'll be able to take a look when they return. I'm not sure what to suggest in the meantime if the usual cleanup script isn't helping. As far as I can tell, the engine seems to be crashing during the plugin scanning procedure. Normally the engine log would tell us more, but is it still the case that you're not getting a log file?

To get to the log files you need to go the terminal and type

open $TMPDIR

which should open a Finder window, then look for a VSTAudioEngine folder. It should contain some log*.txt files.

Have you tried reinstalling, in case something has got corrupted?
by PaulWalmsley
Tue Oct 25, 2016 3:54 pm
 
Jump to forum
Jump to topic

Re: Couple more problems (as if you don't have enough)

In fact I got it working about 3 hours ago :-)
by PaulWalmsley
Tue Oct 25, 2016 11:22 pm
 
Jump to forum
Jump to topic

Re: Can I assign Halion Sonic2 as default library?

I *think* you should be able to access any of the HALion content that you already have the licence for. However those sounds won't be loaded automatically because that relies on extra metadata that links Dorico instruments to HSSE/HSO patches. In future updates you will be able to create your own Playback Templates so that Dorico will use your preferred sounds.
by PaulWalmsley
Tue Oct 25, 2016 1:47 pm
 
Jump to forum
Jump to topic

Re: no sound when using computer keyboard input

Yes, there's an option now to control this which will be in the next update.
by PaulWalmsley
Wed Oct 26, 2016 9:30 am
 
Jump to forum
Jump to topic

Re: Current flow (playback and visibility)

Some of these are bound to shortcuts:
- Space: start from playhead
- P: play from selection
- Shift-space: play from last start location
- Shift-alt-space: play from start of current flow

The current flow is just the one that you did the last editing or selection operation in.

It should probably be the case that selecting a flow in Setup mode should make it 'current' - that does make total sense and is just an omission. I anticipate that navigation between flows (eg scroll view to next flow) is something that we'll add sooner rather than later.
by PaulWalmsley
Wed Oct 26, 2016 9:12 pm
 
Jump to forum
Jump to topic

Re: Frequently asked questions: try this thread first

Dorico or the audio engine is behaving strangely. How do I reset things?

The attached cleanup scripts will:

* kill any running Dorico and audio engine processes
* removes the Dorico application data, including any preferences, key commands or custom options that you have set .
* removes Dorico's cache directories

It should get you back to the state when you ran Dorico for the first time. This can be helpful if the audio engine hangs on startup, or was tripped up by a crashing plugin.

If in any doubt, back up your system before running this script.
by PaulWalmsley
Thu Oct 27, 2016 12:38 pm
 
Jump to forum
Jump to topic

Re: Scripting?

I can't say anything at all about timescales, because at this point we just don't know when we'll be able to make all this available. However we do already have the Lua engine embedded in Dorico. We have great plans for the scripting engine because we know how many more possibilities it opens up for our users. I anticipate that it will be quite an incremental process. For instance, currently it is possible to access Dorico's command system via a script. It may actually be possible to do batch file conversions already, though I haven't tried it. This is all at a very early stage, but we want to design the APIs around the use cases that users have.

We chose Lua as its very lightweight and can be used in different threads concurrently, and can be used to call libraries in C and C++. You can use an external editor and script debugger.

Please take a look at the earlier thread on this: https://www.steinberg.net/forums/viewtopic.php?f=246&t=97329&p=545648&hilit=LUA#p545648 This is a thread we'll come back to when we look at scripting in more detail. If you add your list on that thread then it's something we can consider.
by PaulWalmsley
Fri Oct 28, 2016 10:38 pm
 
Jump to forum
Jump to topic

Re: Workflow methods to be most compatible with future updat

As far as playback goes, we should soon have the ability to have separate playback per voice anyway, so this should give you flexibility if you choose to have all parts on the same stave.
by PaulWalmsley
Sun Oct 30, 2016 9:59 pm
 
Jump to forum
Jump to topic

Re: Anyone running Dorico successfully on a Surface Pro 3?

You may get better results if you increase the buffer size of your audio device (or in the ASIO Generic Low Latency Device control panel). There's also a few options in HALion that you can try tweaking
by PaulWalmsley
Sun Oct 30, 2016 10:02 pm
 
Jump to forum
Jump to topic

Re: No Playback - RealTek High Definition Audio

Actually, we've had more problems on the mac than on Windows. The Realtek is just about the only device giving consistent problems.
by PaulWalmsley
Sun Oct 30, 2016 9:54 pm
 
Jump to forum
Jump to topic

Re: No Playback - RealTek High Definition Audio

I don't know why you keep talking about FPS - it's a meaningless measure in a desktop application. Desktop applications have a totally different update mechanism to games, and the speed of a graphics card will have almost no effect on the perceived redraw rate. The framework we use does support Retina but there are certain areas where there are extra things we need to do to go cope with multiple DPIs, some of which we just haven't had time to do yet.
by PaulWalmsley
Mon Oct 31, 2016 9:19 am
 
Jump to forum
Jump to topic

Re: How to assign instrument, articulation in playback?

The short answer is 'not just yet'. Work is currently ongoing to add support for Expression Maps (Dorico xmaps are based on Cubase's though they will be more oriented towards Dorico's playback model). The road to really get the full benefit of something like VE-Pro is going to be a long one, but that's the direction we want to move in.
by PaulWalmsley
Tue Nov 01, 2016 9:51 pm
 
Jump to forum
Jump to topic

Re: Play Mode: Instrument Allocations

Not currently, though this is something that we could consider. Play Mode is at a very early stage at the moment.
by PaulWalmsley
Wed Nov 02, 2016 1:03 pm
 
Jump to forum
Jump to topic

Re: Multiple dynamics at the same time

You can mute one of them so that it won't affect playback.
by PaulWalmsley
Thu Nov 03, 2016 2:23 pm
 
Jump to forum
Jump to topic

Re: A little Wish List

The double bass problem is fixed for the next update
by PaulWalmsley
Sat Nov 05, 2016 1:35 pm
 
Jump to forum
Jump to topic

Re: Slightly OT question for any HALion experts out there

The reason for this excessive vibrato is that there is currently no way of telling Dorico whether the patch you loaded uses note velocity or mod wheel for dynamics. The default HSO clarinet uses mod wheel for dynamics, but if you switch it to the GM clarinet then that uses velocity. Dorico doesn't know that and plays it using mod wheel, hence the vibrato. This is something that we're looking at currently and we hope that in the next update you will have greater control over this by being able to tell Dorico whether each loaded patch uses mod wheel or note velocity to control dynamics.
by PaulWalmsley
Mon Nov 07, 2016 12:47 pm
 
Jump to forum
Jump to topic

Re: OS X doesn't sleep while Dorico is running

This is implemented as an option in the next update. You would need to switch away from Dorico for it have an effect. However, this option is really intended for the case where you need to share the audio device between two applications and you don't have multi-client ASIO drivers.

Bear in mind that choosing that option has other side effects, since the audio engine is itself a separate process, so if you're not playing back then sound will stop when you switch away.
by PaulWalmsley
Thu Nov 10, 2016 10:19 am
 
Jump to forum
Jump to topic

Re: Tempo Objects Language?

This was originally something that we intended to do, but then on further investigation turned out to be Not Quite That Simple, as many of the existing terms may not translate exactly to every supported language, and then you have the further combinations of meno/molto/mosso/piu, etc which needs to be done in a grammatically correct manner in each language. It's likely to be something that we'll look at again in a future version.
by PaulWalmsley
Thu Nov 10, 2016 7:32 pm
 
Jump to forum
Jump to topic