I'm not quite getting this one:

Do not sound....HOLD time achived...KEY OFF not achived.

Does this mean that you reach the hold time - but do not yet lift the finger? So you're just saying that when you're not letting-off-the-key - don't play the-key-letting-off sound? If so, I guess I get it.

I'm not sure if there's a parameter for this or not although you could do it with element grouping and envelopes -- it would possibly degrade your "key on" experience to do it this way. You could use motion sequence - but this isn't perfect since motions sequences do not follow every oscillator. Still, you could do it and adjust the element level of your key-off sample down until after some time has passed then open the gate (crank the level up). Reset by every keypress. If your key-off sample isn't long then the squelching that occurs when you strike the next key may not interfere with the key-off of the previous note. You could add some delay to the front-end but risk trampling on key-off when note groupings are dense (played in quick succession one after another). Maybe key-off wouldn't matter as much in this situation so the end result would be OK.

Given you want some "hold time" - if that's long enough you really mean don't play key off for quick succession anyhow. It's just a matter of "how quick" you can achieve and still make this work well. There's a way to do it with motion sequence although there may be a more slick way that follows each note instead of this more peanut-butter-spread approach.

Yes, playing a viola, castanets, choir and tambourine roll.

Tambourine will not sound until final chord is played.

That final chord is repeated twice along the song, while still not wanting the tambourine, and lasting half the length than the one at the end, when finally the tambourine roll is required.
Chord very long, exceeding PEG HOLD longest available time, thereby asking not to sound if key off not accomplished.
So I need both, a HOLD over and a KEY OFF condition to be accomplished before triggering the final roll.

So first and second time chord is played, tambourine roll not triggered after key off since hold time was not accomplished.
At the end, tambourine roll should wait for key off signal to sound although hold time was achieved "long ago".

In fact, the whole requirement for many songs of mine will have four steps....what is been said plus the final delay after key off, as follows:

If any answer is No, don't sound.

Is key pressed.? Yes/No.
If yes, do not sound yet. Check next condition..

Has hold time elapsed ? Yes/No.
If yes, do not sound yet. Check next condition..

Has Key off been accomplished ? Yes/No

Do we have three YES? Yes/No.
If Yes, check KEY OFF delay and wait for it to elapse and then play.

There's not a great way to setup automatic "states" like this. At least not multi-level.

Certainly you are aware of arpeggios and how they are triggered. That's one "on/off" state that can be toggled or latched - but it only goes one deep.

Motion sequence is similar - you can use note range or velocity to trigger an "on/off" state.

Since there is no "IF" logic in the "variables" (destination/offsets) - or even "IF" logic in the sources - you cannot setup a condition in one place and then do something based on this output in another.

You can communicate between two Parts using the envelope follower. However, this is more about linking between two Parts than it is setting up "complex" state-based logic.

Most of what you can do is "combinatorial" in nature. Meaning when something changes on the input, the output instantly changes to follow suit according to some lookup table.

Unfortunately you cannot generate envelope follower groups (like mix 3&5&7) which would start to make some inroads on allowing for more complex state-based design. It would still be clunky to use - but at least would allow for "and". Also, I've wanted to be able to scale velocity by an offset which would also be a way to create state-based logic. I could get even more long-winded detailing what you can't do (and how some different architecture would, hypothetically) - but that doesn't help.

Your task here is to take the things the keyboard can do and make it work for what your goal is. What you want or would prefer may not be possible - but that should not stop you. There is likely - very likely - a creative way you can devise which will support your ultimate goal, use the tools available, and perhaps approach the problem from a different angle entirely than you first envisioned.

If your goal is to have something automatic happen without having to reach up for a volume slider or scene button - that's possible. You can automate things that will (likely) produce the end result you want. However, you will likely need to spend some time mapping out a different way entirely to reach that goal. Feel free to cast wishes into the wind using the platforms available for recording/discussing these. However, you also need to - in parallel - devise alternative solutions using what exists today.

Thanks, Jason.

I miss the following:

Accessing or reaching the envelope vía different ways.

NORMAL...
Envelope will sound even when key is played very quickly or momentarily if first condition met.

1. Is velocity envelope accomplished ?
No. Do not access the envelope.
2. Yes...
Is there any DELAY requested ?
No...Go and reach the envelope.
Yes. Wait for delay to be finished and reach the envelope.

HOLD...
Envelope will sound after first condition met only after other conditions have been met and could be made to sound immediately or after some time, depending on the following...

1. Is velocity envelope accomplished ?
No. Do not access the envelope.
2. Yes...Is HOLD time over ?
No. Do not access the envelope.
3. Yes...
Are you requesting KEY ON or KEY OFF ?
4.1. KEY ON...Is there any DELAY requested ?
No...Go and reach the envelope.
Yes. Wait for delay to be finished and reach the envelope.
4.2 KEY OFF...Is there any DELAY requested ?
No...Wait for KEY OFF and reach the envelope.
Yes. Wait for KEY OFF then wait for delay to finish and reach the envelope.

Those simple steps open a tremendous amount of possibilities to make things very easy indeed, avoiding the need to shorten TEMPO to extend delays among voices, will decrease the need for using aditipnal slots, zones, elements, partials, parts, whatever you happen to call them based on the platform you are composing on and also will reduce the keyboard extension needed for the orchestration.

Sounds like you may have ideas for how you would rather the system work - but you're going to have to deal with how the system does work in the near future and possibly for eternity.

I can help flesh out what is possible - just trying to figure out what you're willing to do here. If you must have it different than what is offered - then I would suggest utilizing ideascale. I know it may be difficult to know exactly how far your vision is from what's offered - but it seems like you're still going down the path of suggesting not-yet-implemented (and possibly never implemented) functionality.

That doesn't mean the end result isn't possible - just that you're going to need to recalibrate your expectations about how to get there from here.