midi ports out

Hello Werner.

I can see from what you've written that my straight channel to channel between mscore and LS wasn't going to work anyway.

Suggestions that you might consider when planning your rewrite:

I would think, in instrument properties, that a simple port definition would have an advantage.
Instead of the current 8 port limit, be able to create as many ports as required. (and name them ala Jack naming protocol)
for a full score of say 32 staves, we could have 32 ports, named.
In instrument properties we have an added option for "Select port", and a list of the ports we've created, appears.
Each port carries 16 channels by default, which would be useful for multi articulation.

Additionally, in the instrument properties box, we have an instrument specific "Dictionary."
In this, the user defines by name, an articulation (1st VL Legato Down NR), as an example), and then defines a port/channel and/or bank/patch for that particular instrument/articulation.

As the user adds an articulation/port/channel and/or patch, a new empty articulation slot appears, ready for the next one to be added. And the user, if desired, could assign articulations by patch number for self built banks. I have several banks in LS for example, just for 1st Violins. If i can define by channel bank and patch, then i could conceivably use the same channel in 1st violins for all my Legato articulation options, use channel 2 for all my 1st violin Staccato articulation options, and so on.
Most modern sample libs are not only multi articulation, but contain release and non release sample sets, so with a definable by articulation channel patch framework, we could put a lot of playback options into 16 channels, and 1 port, per instrument/staff.
In this way, i could build extensive instrument dictionaries for each instrument/staff, variable in size, and unique, and importantly, consistent to a port.

so how do we define an articulation once we're writing?

I suggest here a 'note properties' expansion of the current option.
The user puts in a note, then open the note properties box, and chooses the self built articulation name from the list he's already populated in the instrument dictionary.
Playback for that note is then defined, and consistent.
I would think this particularly useful for repetitive phrases, like 16 semiquavers in a row, giving each one an up or down bow articulation channel/bank/patch designation, as previously defined in the instrument dictionary.
It would go a long way toward minimising any machine gun effect we hear in our artifical playback environment, and remove the need for any round robin type editor requirements.

And further to this, if the note properties box contained a couple of extra CCcontroller slots, with a numerical parameter box, then the user could also define at least velocity and volume for the note, or for a shift select, series of notes.
This might then remove extra coding involved in trying to get dynamics to playback correctly, as the user would do that for him, or herself. (Hairpins would be easy here too, as the user would shift select the range, open a 'lines' box, and change the values of the first and last note, and hit the button called 'ramp'.)
The note properties box could also have a note length percentage option, where the user can tweak the note length according to his or her requirement. The score remains 'pure', but the playback can be a lot more human, with the user injecting their own 'feel'.

If the user is happy to assign one articulation per channel, then a basic set of channel keystrokes would be useful.
1-16, and when the note is 'active' (selected), the user hits the keybinding for say channel 5 (staccato down), and that definition is automatically assigned to the note. Makes for speedy workflow, particularly when quick drafting, and he might not even need to open the note properties box all the time. Just use channel changes for basic articulation selection.

For those of us with big libraries there would be a setting up process, building instrument articulation dictionaries.
For the soundfont users, they're still in front, as patch designations still apply, but they have the important added bonus of being able to 'direct' a staff by user defined port, enabling them to use more than one sound device for playback.

The important part in this suggestion, is the user defines articulations per instrument dictionary, and you don't have to think about providing pages of articulation options. The user decides, and for those with big libs, well, we're used to setting up large templates anyway. It's our choice, and responsibilty.

All we need is the framework

This method gives us one more thing. The 'finished' score not only reads correctly for printing puposes, but it playsback well too, and much of the donkey work is already done. Exporting the score as a midi file, into a dedicated midi editor app for further polishing, is as a near complete file, and saves the users much repetition in tasks.

Thanks for the heads up about LS playback, and the required patch changes.
I'll leave the experimenting for now, and see what you come up with, in the rewrite.

Alex.