[2.1.12] Problem with Chased Events on Transport Stop

Hi team,

when implementing VL 2 transport control through an external device (a Line 6 Helix device), I am encountering a problem with the messages generated by VL 2 when the transport goes from Play to Stop, the Chase Event On Start preference is disabled and the Chase Pedal Event preference is enabled.

In detail, the problem seems to be linked to the fact that, when VL 2 receives a Control Change associated with the Start/Stop action defined in Actions and Shortcuts and the transport switches from Play to Stop, the disabled Chase Event On Start preference implies sending events, chased in a control MIDI Track, to the external device and these, in the presence of a CC69 (Snapshot change for the external device) as one of the messages received, negatively affects the operation of the device which ends up in an inconsistent state.

I also noticed VL 2 sending a CC123 (AllNoteOff) in combination with CC69 in the scenario described, but I can’t say whether this additional control message is the cause or part of the cause of the problem encountered.

That said, the question that comes to mind is whether it makes sense to have the chase events for a MIDI Track and the relative sending of messages in the specific case of transport that goes from Play to Stop: if these messages (which seem superfluous to me) were not generated, the problem would be solved at the root.

Waiting for your feedback, thanks in advance.

The preference is only ever changed by the user, otherwise it would be a bug.
But you probably mean something else:

…and that is what it’s supposed to do.
“Chase Events on Start” means “do not chase on stop/locate, chase when started”.
But that is probably not what you mean:

That’s the reset controllers procedure.
These messages are always sent on transport locate (also after stop), regardless of any of the chase operations.

Reset controllers procedure:
The sustain pedal (cc#64) is reset if pressed, as is sustenuto (cc#66), and allNotesOff (cc#123) is always sent, furthermore pitchbend and modulation are reset. This cannot be changed.

cc#69 however is never sent unless with panic, or it is programmed in a track, either at stop/locate when Chase Events on Start is off, or when transport is started when it’s on.

It is a bad idea to use sustain pedal messages for controlling anything but keyboard actions. As long as the sustain (or sustenuto) pedal is pressed, notes keep playing, and Layers and MIDI Tracks have to trace their actions in order to determine when notes have come to a halt. A Layer continues to play even if its Part has been deactivated until all notes are released, and those pedals are released as well, then plus sustain time for reverb tails etc as set in preferences.

Does that answer your questions?

not sure it is tied to the described ‘strange behaviour’, but here is something also very strange - not sure it is a bug, it is more ‘user does not understand background’:

  • I run a project with tracks, I stop the relay by ‘stop command’ on screen.
  • I load another project.
  • Some instruments (Arutria, Halion 7) are ‘out of tune’ (1 or 2 semitones).
  • poopies.
  • I close VSTLive, restart it.
  • I load the same project.
  • All is fine now.
    Where is the trick?
    It is random. (may it be tied to loading time of the instrument?)
    OK - somehow a controller message must be in a ‘buffer’ - but how to go around it?

Only some?
Could be pitchbend? Try engaging pitchbend, does that correct the “mis-tuning”? Is it exactly 1 or 2 semitones? Maybe a Layer transpose, or preferences Layer/Global Layer Transpose?

ja, looks like pitchbend. but I don’t have pitchbend wheel on the assigned controller (Hammond SK2)
as I said: some instruments, not all. Always different ones.
and not tied to one keyboard or one brand, one time it is Arturia (CS80 or Moog Modular or MiniMoog, always different synths) another time it is Halion 7.
Hard for me to reproduce, but it only happens, when I load another project without closing VSTLive. And I can not remember it happened when I
the prior project did not use tracks
I typically stop the tracks at the end a session via ‘space’ keystroke via USB/Arduino
if(buttonStatus1 == LOW)
{
Keyboard.write(32); // Cubase Start/Stop (Blank)
delay(1000);
}
any idea ? It is not urgent to me, when I close VL without saving the project - at the next VL restart/load (after 20 sec) all is fine. But maybe I can narrow it down with your input.
So far …
And thanks for all the fast work you are doing with issue fixing!

other (silly) idea:
I am sending also ‘PageDown’, ‘Pageup’ for Part switching and ‘L’ keystroke for Loop exit.
All intrument windows are closed.

Hi @musicullum,

I realize that maybe this time finding a solution is a little more difficult than usual… :thinking:

I’ll try to clarify some things, also using your answers… :slight_smile:

The preferences I indicated are those I set during testing and necessary to obtain the desired behavior during live performances

This was already absolutely clear to me :wink:

I think then that this consideration should be made to Line 6 who decided that changing a Snapshot inside a Preset can only be obtained with a CC69 and that this control is not reconfigurable by the user as reported in the following excerpt from the manual:

image

This I think is the crux of the matter: I absolutely do not question that there are particular CCs for which reset messages must necessarily be sent when the transport switches from Play to Stop and that among these there is also CC69 (after all this behavior appears completely analogous to that of Cubase, observing its MIDI Monitor), but then how can I avoid that my Line 6 Helix, at the same time as sending a CC related to the Stop of the transport, receives a CC69 from the MIDI Track used to control it and thus ends up in an inconsistent state?

I specify that the inconsistent state to which I refer appears to have pressed the footswitch that sends the CC linked via Actions and Shortcuts to Start/Stop without ever having released it. :frowning:

As much as I tried, I do not see a solution: I hope you can provide me with a useful suggestion, but obviously I thank you in any case for the support. :blush:

Yes, sorry to have to say that it is a bad decision by the colleagues. There are “General Purpose” controllers for that, and choosing note-related controllers (69 is “Hold2”) is not a good idea. For MIDI processors like a VST Live Layer, this changes the state of sounding notes, which is important to avoid hanging notes, decide when all notes are released etc.

Nevertheless, we see your problem and are considering to allow to surpress the reset controllers function.
Oh, just found that it exsists already, Edit/Preferences/MIDI/Reset Controllers.

I had also included the Reset Controllers preference in the tests I performed to understand the terms of the problem encountered by my Line 6 Helix.

What appears to me from the Midi Monitor is that, for example, for a Control Change such as CC1 Modulation, activating the Reset Controllers preference actually causes the generation of a CC1 control reset event on the transport Stop (a CC1 event with Data 2 set to 0), while this does not happen at all when the preference is deactivated.

However, all this does not seem to happen at all for the CC69 control, a control for which, on the Stop and regardless of the Reset Controllers preference setting, I note the generation of a CC123 (AllNoteOff) and the last CC69 chased in the control Midi Track.

And I believe it is precisely this last CC69 that causes the issue in my external device and this is the reason why in my first post I asked if actually chasing the last events present in a Midi Track and sending them to the output port, when the transport goes from Play to Stop, is something absolutely necessary and indispensable.

I hope I have been able to explain my analysis clearly enough. :blush:

But how should this be prevented? Chase is always enabled, either on stop/locate, or when you start. Do you want to disable chase altogether?
Furthermore, if you have cc69 programmed, it will send that message anyway, only later.
Still not quite sure what you want to acheive, despite of all explanations. Going back to square one, you said

But that’s the purpose of chase, which is always active. But: If chase pedal events is off and chase events on start is on, there will be no cc sent on stop (locate), only when starting transport.

It would be good if you could offer what you suppose is a solution to your problem. Chase is mandatory for MIDI, we might add a preference to disable chase altogether, but that is special indeed.

I’ll start by saying that, obviously, I have no idea of ​​the implementation that is under the chasing functionality and consequently of the impact that this hypothesis would have on the current solution.

That said, the idea would be, on the user side, to be able to have as a preference the fact that VL 2 generates or not in output chase events when the transport goes from the Play to the Stop state.

In practice a sort of Chase Event Also On Stop preference that would avoid the chasing of the event only and exclusively on the transport scenario that goes from Play to Stop in case the preference is disabled (or, in reverse logic, a Avoid Chase Event On Stop preference).

I remain hopeful about the possibility of realizing this solution or another solution that in any case solves the problem: as always, thanks for the continued support. :blush:

But that’s exactly what “Chase Events on Start” does. When enabled, no events are chased on stop/locate.
Still confused…

I probably understand where the misunderstanding came from, basically from my lack of clarity on a focal point.

My goal would be to continue using Chase Events on Start disabled, in order to have the chase of events particularly useful with Helix during the rehearsals, but at the same time not have the chase in the transport transition from Play to Stop, in order to control the VL 2 Play/Stop transport via Helix and avoid the issue that currently occurs in this scenario.

I hope this time I have been more capable in the explanation. :blush:

a) Chase Events on Start enabled:

  • Play to Stop/Locate transition: No events are chased (sent).

b) Chase Events on Start disabled:

  • Play to Stop/Locate transition: Events are chased.

So…?

You keep talking about transition from Play to Stop. Actually this is about transition to Locate (which is always executed after Stop).

Say there is an event at bar 5, and the next one is at bar 13. Now you locate to bar 9. The regular case is “Chase Events on Start disabled”, now, because there is an active event between bar 5 and bar 13, the last state (at bar 5) is sent. Then you locate to bar 17, without starting play, then the state at bar 13 is sent, all this in order to let all connected devices know the state at the Locate position, regardless of whether play had been engaged or not.

If Chase Events on Start is enabled, nothing is ever sent on locate (and stop). But events which are “held back” during locate are then sent when you start (engage “Play”), so that all devices are set to the last state before the position.

Now I still don’t know what you want. You keep saying that you don’t want to chase events on the transition from Play to Stop, but that’s exactly what happens when “Chase Events on Start” is enabled.

That’s a contradiction.

When? When exactly do you want chase to happen? Not when stopping, it seems, but then - when?

Obviously I am sorry to make you spend all this time to interpret something that is not at all clear and contradictory to you. :disappointed:

I try another way, that of describing two scenarios, that is, what is currently happening and what could happen to avoid the issue with the Helix device (always according to my tests and hypotheses, obviously).

Let’s first assume we have a Song that contains a CC69 event (change of snapshot, the value of Data 2 is irrelevant) at measure 1.1.1 and a second CC69 event at measure 2.1.1, events placed in a MIDI Track that transmits to the Helix device.

Let’s also assume that, through the Helix Command Center, I have configured the CC102 to press a footswitch, then using Actions and Shortcuts to perform the Start/Stop action of VL 2.

I further specify that we are in the case of preferences:

  • Chase Event On Startdisabled
  • Chase Pedal Eventenabled

I begin by describing what currently happens, according to my observations, during a performance of the Song:

  1. The transport is in the Stop state on measure 1.1.1
  2. On the Helix device I press the footswitch associated with the CC102 transmission to VL 2 and, thanks to the configuration of Actions and Shortcuts, the VL 2 transport regularly switches to the Play state
  3. The event placed in the MIDI Track at measure 1.1.1 is ignored and no MIDI message is sent (which I don’t understand, but it is not important for the purposes of the issue posed)
  4. Having reached measure 2.1.1, VL 2 finds a CC69 event in the MIDI Track, an event that is transmitted to Helix which changes the snapshot regularly
  5. Having reached, for example, measure 3.1.1, I decide to press the footswitch on Helix, the transport of VL 2 goes to the Stop state
  6. At this point, as you explained to me, the passage of the transport from Play to Stop is not taken into account; on the contrary, the relocation is considered (or perhaps just the “click” on Stop) and the enabling of the chase finds the CC69 placed in 2.1.1 of the MIDI Track, this event is sent to Helix which, for reasons that are not at all clear to me, finds itself in an inconsistent state (apparently it seems as if the footswitch had remained “logically” pressed)

Honestly I understand more and more that the logic behind the chase is different from how I had interpreted it, so I find it difficult to apply the solution I had in mind and that I am explaining to you anyway. :roll_eyes:

Hypothetically, it would be a matter of modifying only and exclusively the logic described in step 6, which would become:

  1. At this point, the software (possibly based on a preference) takes into account the change of state of the transport from Play to Stop and, for this reason and only and only in this specific scenario, does not apply any chasing logic, so no MIDI message is sent to Helix which remains on the last snapshot selected (as it should be) and in a consistent state

Thank you once again for your patience and effort in trying to find a solution to this intricate issue. :blush:

Would an option to set “Stop” to actually mean “stop, do nothing” (i.e. pause) solve the problem?

With regard to the MIDI message not being sent - is it the same if you use the PC keyboard to start playback?

Why? You want to avoid data beeing sent on stop (I insist: locate), so you need to switch this ON.

…which is exactly what happens when you set Chase Event On Start to ON.
What are we missing here?

One thing we could do is to surpress sending a controller if it didn’t change its value from the last time sent. While this should be ignored by the receiving device, we’ll add that, maybe it helps.

Because, as previously stated, I find it useful to have Chase Event On Startdisabled during rehearsals, where it often happens that you have to “jump” to different points of the Song

I find this idea really a great idea, both to solve the issue I reported to you with the Helix device and to have a smaller flow of messages to the external device, while still preserving the essential ones! :+1:

Hi @musicullum,

I am happy to confirm that with version 2.1.13 of VL 2 and the introduction of the logic of suppression of messages associated with controls that don’t change their value, the issue that appeared with the use of the Command Center of Line 6 Helix has been solved! :tada:

Just a “nitpick”: in my tests I noticed that the suppression logic introduced was limited to the Control Change and I was wondering if it was not the case to extend this logic at least also to the Program Change… what do you think?

In the meantime, my infinite thanks for the patience and commitment shown. :blush:

Good point. We extended it to program change and pitchbend for the next version.

1 Like