X-Fader Question

[JWL]

Hey:

I've just loaded up a MIDI file of a score and am currently putting keyswitches for strings.

I'm seeing a lot of cases where the first notes in a fast phrase triggers the X-Fader to go to zero, and then it jumps back to a higher level and stays there from the second note onwards... until the next phrase where another keyswitch is entered.

I've not yet enabled continuous data in this project and have been scouring event lists and graphic editors for any data which may be causing this strange behavior-- after spending a day trying to sort it out I am totally stumped.

Just as an experiment, I temporarily set all the notes in the phrase AND the keyswitches to the same velocity, but the result is the same.

Is this common? If so, I suppose I can just ignore it until it's time to enter X-Fade and Expression control data later. I can't say it's not bothersome.

I just don't understand what could be sending the X-Fader a prompt to zero out on the first notes in each phrase following a keyswitch.

Suggestions?

Thanks.

[Sapkiller]

I just tried it - and right clk + a keypress assigns xfade and with a behavour as you described.

Sure you did'nt by accident assign the xfade to keys or some other cntl ?
To make sure you could right clk the xfade and then immidiately right clk
again - this will unassign any control.

[JWL]

@Sapkiller said:

I just tried it - and right clk + a keypress assigns xfade and with a behavour as you described.

Sure you did'nt by accident assign the xfade to keys or some other cntl ?
To make sure you could right clk the xfade and then immidiately right clk
again - this will unassign any control.

Thanks, Sapkiller.

I've not begun actually assigning controllers to numbers yet, but only assigning patches to expand the matrices to accomodate the articulations I need. This new project came in as a Standard MIDI File. There could be some stray data in the file, and I'm endeavoring to find the culprit. I've been searching for a few days and have found nothing so far. If I could only find one occurence where the culprit would reveal itself, I could easily filter out that particular bit of data without having to manually remove it from every track.

Whether on or off, the X-Fader seems to have a mind of its own.

I'm dreading the notion of having to start from scratch by entering all MIDI notes manually. This is a monsterously difficult score lasting about 14 minutes.

Ugh!

[Sapkiller]

yes, the xfade fader moves even if the xfade button is turned of - but the fader must be assigned to something, controller, key wheel whatevver - thats why I suggest you try unassigning it. Then the fader should'nt react to anything.

Does'nt that work?

[JWL]

@Sapkiller said:

yes, the xfade fader moves even if the xfade button is turned of - but the fader must be assigned to something, controller, key wheel whatevver - thats why I suggest you try unassigning it. Then the fader should'nt react to anything.

Does'nt that work?

No, it doesn't work, actually. In fact, it underscores my point of the first notes in each phrase dropping to zero whether the X-fader is assigned or not, or whether it's turned on or not. Even if I reset the X-Fader level, it fights against my setting when I try to match levels from one keyswitch to another when it's on-- but the symptom is still there

It's either a bug in my system or a bug in the original MIDI file. Obviously, other people are not having a problem with it. I just need to get to the bottom of this soon because it has brought my project to a complete halt.

Thanks for your responses!

J.

[Sapkiller]

Try assigning the xfade to a known controller - say breath control ( and then make sure that none of this data is in your midifile). Hopefully it should not
response to anything else.

Only other possible thing I can think off, is midi metadata controlling the VSL VI itself - but there's no documentation of the VSL VI responding to metadata.
Is there any RPN data in your midifile? Or sys-ex data?