sure now we're even.

@magates said:

I had to learn to use it. I have all the bugs worked out. I can get it to work perfectly - check out my mock ups to hear the results. All done via finale. Very worth the time.

I had listened to some of your mock ups before, and it is in fact very nice work with good use of midi expression.
Apart from the inconvenience of the interface, my main real complaint about the midi tool is its inconsistency (some of which I described in my previous post) - the results do not always play back as programmed. Drives me crazy. [*-)]
Have you experienced any of these issues?
From the rest of this thread, I've gathered that you are on a Mac... I wonder if that has anything to do with our seemingly differing experiences regarding midi tool and patch changes (I'm on PC)..

@magates said:

Hmm... I hope your right, but based on what has been shown so far (admitedly little), I am not so sure... How exactly would you switch between a half tone or whole tone trill, or a sustain (and bear in mind, there are several different sustains, and possibly some new ones in play now!), or a pizzicato, etc... From what I can see, there is no patch number that I could assign from Finale (or others from Sibelius and the other options out there) to call up a specific articulation... maybe the feature is in there some where, and that is the sort of thing I would like to find out. [[:)]]

In Finale you can use a hidden measure expression with the playback set to the data dump function. In this way you can send kewswitch data as a midi message.

Michael Matthews

Well that is just a bloody clever idea. [[:)]]
I'm going to have to try that out, just for the heck of it!

The midi does look diffrent on a mac. It is easier tot see where you are.

There are a bunch of quirks with it that would take a while to explain.

But some of the basic ones are you don't always see the midi data telling what volume you were on previous to where you are now. So if you can start the volume change in an empty bar so you don't get a hick up - if you can't do that you will have to scroll back and see what the volume was were you left off.

also if you copy and paste midi data into a bar that already has midi data it will try to combine the two sets of data resulting in garabage - first delelet the old midi data by hittin backspace or cntrl-x clear.

you can only drag midi data - you can't actualy hit copy and then paste - very weird and I hate this because if you want to copy something from the beggining you have to go to a percent view of like 10% so you can drag it with the midi data.

if you try to draw in midi data with tool instead of doing it bar by bar you have to be extremly careful and look exactly where you are placing the cursor or you will get hickups in the volume always zoom out to more than just one measure to see what the midi data really looks like - the one measure view is very deceiving.

Any other questions let me know.

It works like a charm. I have a library of hidden measure expressions for all of the VSL keyswitches. I get the occasional glitch when I have to change both the keyswitch and the articulation at the same time (that is, when there are no preceding rests to pre-send these changes).

I suppose it remains to be seen how Finale will work with Vienna Instruments.

VSL Team: any info on this?

Michael

do you mind posting that library to my email magates@gmail.com

I'd appreicate it.

as far as the VI goes I can't imagine it working much diffrently than say exs - the only diffrence being you would have to use less programing (hopefully). you could actually be sure of what you were trigiring articulation wise with the lenght of note being determined exactly with diffrent % increase or decrease articulations. What other issues would there be?

Hard to say. Perhaps it's just my general skepticism coming to the fore.

Michael

@Another User said:

There are a bunch of quirks with it that would take a while to explain.

But some of the basic ones are you don't always see the midi data telling what volume you were on previous to where you are now. So if you can start the volume change in an empty bar so you don't get a hick up - if you can't do that you will have to scroll back and see what the volume was were you left off.

also if you copy and paste midi data into a bar that already has midi data it will try to combine the two sets of data resulting in garabage - first delelet the old midi data by hittin backspace or cntrl-x clear.

you can only drag midi data - you can't actualy hit copy and then paste - very weird and I hate this because if you want to copy something from the beggining you have to go to a percent view of like 10% so you can drag it with the midi data.

if you try to draw in midi data with tool instead of doing it bar by bar you have to be extremly careful and look exactly where you are placing the cursor or you will get hickups in the volume always zoom out to more than just one measure to see what the midi data really looks like - the one measure view is very deceiving.

Any other questions let me know.

Thanks for taking the time to post these observations - I have in fact experienced nearly all those issues myself. It seems if one is to get any serious work done with the tool you have to be careful and attentive about what your doing... the trouble is, without a clear view of what you've done and are doing it all has to be done from memory, which gets complicated if one is editing many parameters (velocity, volume, modulation, etc....).
I do hope this important feature gets the update it so badly needs!

The things you pointed out have been a help. [:)] I'll keep them in mind the next time I take a trip 'down memory lane'.. [[;)]]

@magates said:

...you don't always see the midi data telling what volume you were on previous to where you are now. So if you can start the volume change in an empty bar so you don't get a hick up - if you can't do that you will have to scroll back and see what the volume was were you left off.

That gives me the perfect chance to post this about velocities, just in case anyone was wondering. It is at least true for Finale 2004.

If you want to use the midi editor to change the velocity to an absolute value, you actually have to do it relative to the default playback velocity and the last velocity you set via a text expression. Namely--

1 - So your default playback velocity is 64.

2 - Let's say you have a text expression that sets the velocity to 24 and you play a note. The note comes out with a velocity of 24.

3 - You look at the midi editor and you see your note at 64, not 24.

4 - Over the course of several more notes, you want the velocity to change from 24 to 30.

5 - You actually have to scale it from 64 to { 64+ (30 - 24) }, or 70.

6 - value_to_use_in_midi_editor = desired_velocity + (default_playback_velocity - last_velocity_set_by_text_expression)

So with a default playback velocity of 64, I can't scale down from a 100 to a 20, although I could scale from 100 to a useless 164.

What were they thinking?

K

to get the midi working really well I suggest disableing human playback. I also suggest using percentages as much as possible that way it always relative. And with vsl I don't find any need to scale velocities only CCs. With almost all vsl patches scaling velociteis only works if your scaling within a given velocity layer or if their is no volume leap in the covered keyswitches. otherwise you are going to get jumps when it passes a velocity layer. there are clever ways of programing around that though.