Environment Transformer question

Alright, another question for old school environment experts...

 

I think this might be a bug or flaw in LPX, but I would love to have someone tell me a work around...

 

Basically let's take a very simple example. I want a transformer in the environment which will insert CC1=100 event in front of every other event coming through.

 

Fine so far, so I created something like this:

 

 

Now if I play the keyboard, so that live midi goes through the environment, it looks good, the CC1 events are there right in front of the NoteOn and NoteOff, as expected, we can see that both in the environment monitor as well as monitoring the channel strip with Scripter logging:

 

 

[ControlChange channel:1 number:1 [Modulation] value:100]
[NoteOn channel:1 pitch:60 [C3] velocity:98]
[ControlChange channel:1 number:1 [Modulation] value:0]
[NoteOff channel:1 pitch:60 [C3] velocity:64]

 

However, problems happen when playing a region, which does not achieve the same results as playing live. Here is playing a region with one note on it through the same environment circuit. Note the monitor we see the NoteOn is duplicated, but what arrives at the Scripter plugin has one correct NoteOn, but a duplicated extra NoteOff! Where did that NoteOff come from and how can we get rid of it?

 

 

[ControlChange channel:1 number:1 [Modulation] value:100]
[NoteOn channel:1 pitch:60 [C3] velocity:80]
[ControlChange channel:1 number:1 [Modulation] value:0]
[NoteOff channel:1 pitch:60 [C3] velocity:64]
[NoteOff channel:1 pitch:60 [C3] velocity:64]

I was just experimenting with real time transformers and recording the output and have found that they don't work/record reliably. You should be able to make a Transform Midi preset that does what you want and can assign that to a keyboard command, which is what I did to solve my problem.

Unfortunately in my situation, using a key command to change the environment will not suffice. I need the environment to deliver consistent results...not duplicated or dropped NoteOff's either way..

What are you trying to accomplish, the end result of having a cc100 event for every note?

There's a bigger problem I'm trying to solve that I don't really want to explain entirely..but yes..I need a cc message in front of every midi event....no duplicates...

Have you tried check-marking the "Filter Duplicate Events" option in the Transform object window?

What kind of object is the testinst one? What feeds it? What is the global cabling scheme?

Perhaps there is some chasing setting involved here?

 

Perhaps explaining the end goal (or the source problem) could yield in finding an easier solution...

Oh yea I have tried a great many things including that.

 

I made the example above as simple as possible to isolate it and remove any and all other potential issues. I believe this is a bug in LPX. I have spent quite a few hours trying everything under the sun I could think of to work around it with even fairly complicated transforms, but none work..

 

It looks to me that live midi has a NoteOn and a NoteOff events as entirely separate events, but region data contains a kind of "Note" even that has start time and duration, then a NoteOff is generated automatically at some point "somewhere". When you do the COPY operation in Transformer to create the CC100 message, it looks good, it puts a CC100 in front of the NoteOn and the NoteOff, but unfortunately the CC event itself somehow still contains the flag internally to generate another NoteOff message, just like the "Note" it was copied from. Something like that. I have not found any way to filter it out without screwing up live midi.. I mean if you filter out the NoteOff, then the live midi will have hung notes, etc..

Edited May 8, 2018 by Dewdman42

What is your end goal, which you are trying (unsuccessfully) to achieve with that CC100 approach?

fix Vienna Ensemble Pro multi port templates which are currently broken due to this bug in LPX

fix Vienna Ensemble Pro multi port templates which are currently broken due to this bug in LPX

Perhaps elaborating further could be helpful...

I have a very long thread where you can read the journey and its a lot of irrelevant information for this problem at hand. Here is the other thread if you are interested...viewtopic.php?f=9&t=137085

 

VEP actually uses CC99, not CC100, but its the same principal...every midi note needs to have a CC99 message put in front if it...with the value being the "port" to use. The VEP AU plugin translates that into proper multi port handling internally.

Back to my question....can anyone work around the LPX bug in transformer?

Hi,

 

Here's a workaround:

 

 

J.

I was just about to post my own work around that i just figured out too! Thanks for contributing. One thing, the above work around you are proposing may leave some hung notes for LIVE events coming from the keyboard. That is part of the challenge... has to handle both LIVE and PLAYBACK...and has to handle both true NoteOFF as well as Note's that might come as NoteOn with velocity=0. I will post what I figured in momentarily.... Edited May 8, 2018 by Dewdman42

Alright... This is what I came up with and it seems to be working... As I said above, I guess there are 3 use cases that have to be tested. I didn't test 2nd use case below, have to figure out a way to test that.

 

1. Live NoteOn/NoteOff (sender provides a true NoteOff with some release velocity > 0)
   
2. Live NoteOn/NoteOff (sender provides a fake Noteoff with NoteOn and velocity=0)
   
3. Playback Note (NoteOff handled by LPX)

 

Here's the environment and results from Live, keyboard in this case sends a true NoteOff

 

[ControlChange channel:1 number:100 [Reg.Par. LSB] value:5]
[NoteOn channel:1 pitch:60 [C3] velocity:98]
[ControlChange channel:1 number:100 [Reg.Par. LSB] value:5]
[NoteOff channel:1 pitch:60 [C3] velocity:64]

 

 

Here's environment and results for Region playback

 

[ControlChange channel:1 number:100 [Reg.Par. LSB] value:5]
[NoteOn channel:1 pitch:60 [C3] velocity:80]
[ControlChange channel:1 number:100 [Reg.Par. LSB] value:5]
[NoteOff channel:1 pitch:60 [C3] velocity:64]

 

Explanation

The first Note splitter sends Live NoteOff events on the upper cable. Live NoteOn and region Playback Notes go to the lower cable. In either case we filter out the NoteOff's on the lower cable because LPX provides it later on its own somehow, but on the upper cable we leave it there since that SHOULD only be Live NoteOff's. It actually seems to work, even using the LPX screen keyboard, which sends a true NoteOff.

 

Notice the output during Region Playback...in the Env monitor it does not show any NoteOff happening...we filtered it out...but on the scripter logging, there it is. Something outside the environment is adding the NoteOff. In the case of live midi the noteOff should go on the upper cable and not get filtered out.

 

Also notice the transformers called "Assign100val". That is apparently needed because without it the first transform that tries to insert the CC100 events, inserts a CC with value = 0 for the NoteOff...That's the second bug involved here.

 

I also notice another thing, in the region playback example, the monitor shows duplicate noteOn events...but out in scripter log we only see one, which is what we want, but I'm not sure why the monitor shows two note ons there.

 

The two environment bugs are:

 

1. If you use transformer to copy a CC in front of a note, then you get two CC's, one for NoteOn and one for NoteOff, but the second one in front of NoteOff doesn't accept the fix operation, it always sets value to 0. So that fix is easy..use another transformer to force those CC's to the value desired.
   
2. When doing that COPY operation, we end up with an extra NoteOff and LPX adds yet another NoteOff outside of the environment.

 

Anyway, I think this is working... Thanks for your suggestions and hopefully that's the end of it.

You're welcome,

 

About undesired results with live events...I didn't test any of that, in fact it didn't even cross my mind . All I considered for this workaround was the notes-coming-from-regions scenario. Sorry 'bout that

 

J.

no apologies needed, thanks for getting involved..!

Cool,

 

Glad to see you managed to figure out a more suitable workaround. Please do make sure you report those buggers.

 

J.

already did, but I don't expect Apple to do anything related to the transformer. That is REALLY old code in there... but you never know...

Oh but they do still touch that code, so we can be hopeful they’ll fix it. I’ve been pleasantly surprised before by seeing not-so-obvious bugs I’ve reported suddenly getting fixed...

 

J.

In theory, would this work as a script to use on all external midi that has trouble receiving note off messages?

 

This has been an issue with Logic for years it seems. Using an AMT-8 and Expert Sleepers midi with Logic and stuck notes have plagued me for far too long and I have never found a reliable solution other than double clicking the control bar midi indicator to send an all notes off message. Would you recommend this as a solution?

Not sure about your problem but no I don’t think this is right solution for you unless you are using a transformer object as mentioned above. That being said you might be able to use The above mentioned bug or something similar to add duplicate noteoff’s but I reckon you need to figure out where and why you’re getting dropped note off’s

Here's a quick Scripter script you can use to duplicate all your NoteOff's. This might help, or might cause note cutoff's or might not help at all depending on if this is some kind of hardware problem. But anyway ,this will duplicate all Noteoff's very close together in time.

 

function HandleMIDI(event) {
   if(event instanceof NoteOff 
           || (event instanceof NoteOn && event.velocity < 1)) {
       event.send();
   }
   event.send();
}

 

If you want a few milliseconds of time between the duplicates to give a little breathing room, try this:

 

function HandleMIDI(event) {
   if(event instanceof NoteOff 
           || (event instanceof NoteOn && event.velocity < 1)) {
       event.sendAfterMilliseconds(10);
   }
   event.send();
}

But I can't iterate enough, I don't think most people are suffering from dropped note Off's like you are. So there must be something about your setup that is causing it and it would be better if you could isolate exactly where and when the noteOff's are getting dropped. use midi monitors and watch closely. Try sending your midi over IAC also and use a monitor there, before sending to the external device...so that when you get a hung note you can go look at the monitor. If you're using tricky stuff in the environment or Scripter, then its all suspect so you have to monitor them in and out and try to find out where and when NoteOff's are getting dropped. That is better solution then throwing duplicate NoteOff's at the problem. In fact if noteOff's are getting dropped before hitting Scripter, then the script above won't help you at all. that just duplicates it case your hardware is somehow not keeping up, gives the hardware an extra chance...