MIDI reliability problem

Question

I'm wondering if it's possible that something has changed in the way Kyma handles MIDI in the past couple of updates. I am revisting an older composition for a performance in March. The timeline used to be absolutely rock solid in responding to MIDI data from my EWI to control WaitUntil sounds that allow me to progress through the timeline. It even worked fine last summer/early fall when I was planning this performance. Now, it's hopelessly and unpredictably unreliable. I've spent the last couple of days experimenting with the little Capytalk expressions (mostly in the realm of treshholds) ... but to no avail. Below is an example of the sort of expressions I've been using ... one that most recently failed even though (as you can probably see) I had adjusted the BC level to a ridiculously low level. 

(!BC gt: 0.05) + (!KeyNumber eq: 37) eq: 2

This WaitUntil occurs at a climatic entrance when I'm playing about as loud as I can with BC values hovering around between 0.8 and 1.0.

FYI: Quite a while ago I adopted this format for my WaitUntil triggers to avoid unintentionally triggering event with my fingers on the keys without actually blowing on a note. And it has mostly worked pretty well. I've even had a couple of "clean" performances in the past few days when everything went fine. But I've also had numerous abject failures bad enough that I'm thinking of canceling the performance. Any thoughts on what might be going on now that causes previously solid "cues" to be missed?

Comments

Follow-up: First thing this morning the timeline failed to catch an absolutely critical cue (the one shown in the previous post. This afternoon, with no change in the timeline, I managed two consecutive successful run-throughs.

Answer 1

Since the EWI sends note events when breath pressure is large enough, you may have better results including !KeyDown in your expression:

!KeyDown /\ (!BC gt: 0.05) /\ (!KeyNumber eq: 37)

!BC and !KeyNumber always hold the last value received by the Pacarana, so your original expression could have a true value even if you are not playing the EWI. By adding !KeyDown, you are forcing the expression to be false when you are not playing.

Comments

Ah …I hadn't considered that issue. It certainly seems like this could explain a problem I had a couple of years a go when (especially during practice session) where Kyma would blow through a WaitUntil before I actually played the trigger note. But how does it explain instances when an expression like (!BC gt: 0.05) /\ (!KeyNumber eq: 37)  fails to advance the timeline, when I attack the correct note with a !BC value far in excess of 0.05 …? That has been by far the more vexing problem lately. Sometimes stopping the air and replaying the note gets the timeline moving again.

My EWI (probably others, too) has a peculiarity in the way that it handles KeyDown and KeyUp when playing a continuous (legato) passage. It sends the next KeyDown message first … then almost immediately after that send a KeyUp message for the previous note.

Thank you for taking time to address this problem that has been vexing me for a while.

---

Follow up. I rewrote the Capytalk code for all my WaitUntil sounds. Strangely enough the one that seems to still be the most unreliable is the very one we discussed as an example. I did increased the value for !BC, though still way under the !BC value I’m actually sending. And by unreliable, I mean that the timeline stalls an doesn’t move forward. Sometimes playing the note twice will cause it to proceed.  

      !KeyDown /\ (!BC gt: 0.2) /\ (!KeyNumber eq: 37)

I'm wondering if the unreliability is related to the fact the (unlike velocity) !BC always ramps up from zero. So !KeyDown and !KeyNumber messages are probably triggered the instant that !BC turns positive … ??? If I take out  either reference to !BC or !KeyNumber doesn’t stall (so far). But if the analog breath sensor were to drift a bit, I could easily foresee a situation where leakage of a very low !BC value would trip the WaitUntil before I actually blew into the instrument to produce the desired note. (Would !GateWhen be of any help?)

---

Please check to make sure that all of your WaitUntil Sounds have !BC set with "Affected by Presets" set to "No".

Could it be that you are already playing !KeyNumber 37 with sufficient breath at the beginning of the WaitUntil? If the condition is true exactly when the WaitUntil starts, you will need the condition to become false first then true in order to break through the condition.

---

I reworked all the WaitUntil sounds by setting all  "Affected by Presets” to “No” … but did not seem to resolve the problem. Meanwhile, it created another issue because it sets the value of !BC to 0.5 — even before the timeline arrives at the first of those WaitUntil sounds — resulting in the triggering of a countdown.

Meanwhile … I will never understand why !BC should *ever* have 0.5 as a preset default value, since my global map contains the following lines:

!B is: ((`MIDIController02 displayAs: #fader) setOnlyInitialValue: 0).
!BC is: ((`MIDIController02 displayAs: #fader) setOnlyInitialValue: 0).
!BreathController is: ((`MIDIController02 displayAs: #fader) setOnlyInitialValue: 0).

BTW: This has never really worked since I added to my global map. It has been a source of great frustration.

"Could it be that you are already playing !KeyNumber 37 with sufficient breath at the beginning of the WaitUntil?”

I can state with absolute certainty, that this is not the case at this particular point in the timeline. The last note played was note 39, with a diminuendo and then I stop playing anything at all (!BC goes to zero) followed by a brief pause.

---

Just to double check: in the Status window at the bottom left of your screen, you see your global map listed as being selected.

---

This *was* a problem when I first started back on preparations for this upcoming performance (after the last update replaced it with a generic default global map). But I discovered that problem early on and corrected it.

Meanwhile… I have decided to go back to "bare bones” triggers (!KeyNumber eq: 39) for most of the timeline WaitUntil sounds. In most these instances it would be better if the timeline blows through WaitUntil (doesn’t wait) than to get hung up and stall. But in two of the most critical situations where it would be "catastrophic" for the timeline to blow through the WaitUntil until I have arrived at it with my performance, I’m using this:  (!KeyDown /\ (!BC gt: 0.1) /\ (!KeyNumber eq: 37)). And I make sure that I have absolutely no air flowing through the EWI and that my fingers off the trigger note keys just before I want the timeline to start moving again. A couple of times, in situations where it’s possible that I might want to arrive at a sustained trigger note a little bit in advance of the WaitUntil, I’ll use the following:

(!KeyNumber sameForLast: 1000 tolerance: 100) gateWhen: ((!BC gt: 0.1) /\ (!KeyNumber eq: 60)) >

Anyway … today things went pretty well most of the day. I did have a question about how I could get a trigger like (!KeyDown /\ (!KeyNumber eq: 37)) to only trigger 3 times and then never again. I imagine it involves using countTriggers eq: … (something?). I’ll try again tomorrow to figure it out.

Thanks for all your helpful suggestions.
Cheers!