What's new

Negative track delay and Logic Scripter - recording in vs. playing back

I should probably change the name of that checkbox so that its more obvious.

Note that the simple correction mode checkbox can be automated in an automation lane in case you want to switch back and forth dynamically. With simple correction mode, all your notes will be ending their sustain earlier then they appear on the piano roll. Lots of times it doesn't matter for shorts, etc.. But for sustained sounds..then it might matter.

The only reason to really have the notes terminate early is to avoid accidentally getting legato overlaps. what kinds of problems were you having with notes not being ended early?
 
I should probably change the name of that checkbox so that its more obvious.

Note that the simple correction mode checkbox can be automated in an automation lane in case you want to switch back and forth dynamically. With simple correction mode, all your notes will be ending their sustain earlier then they appear on the piano roll. Lots of times it doesn't matter for shorts, etc.. But for sustained sounds..then it might matter.

The only reason to really have the notes terminate early is to avoid accidentally getting legato overlaps. what kinds of problems were you having with notes not being ended early?
I'm making a mockup of John Williams' Superman march -- at the beginning with the rhythmic riff of repeated notes playing eighths and 16ths. There was some dropping of the sound that went away when I turned on the simple mode.
 
I'm making a mockup of John Williams' Superman march -- at the beginning with the rhythmic riff of repeated notes playing eighths and 16ths. There was some dropping of the sound that went away when I turned on the simple mode.
I looked at the sequence - and I'm not sure it's because the note ons were coming before the preceding note off-- technically, there was a gap in time even without simple mode. So I can't say for sure why it was a problem.

But I figure the simple mode is useful in that it isn't changing the relative timing of the different events in the region. (So what you see is what you get, only earlier.)
 
The NoteOns need to be TRIGGERED early so that they sound on the grid due to very slow attack transients that are inconsistent between articulations. Real players also start moving their hands ahead of the beat instinctively so that the actual sound will not start late.

You want the actual sound to be on the grid, not late, not early.

The end of the note should also sound on the grid, what you see is what you hear but if you really wanted to get technical you’d need to use a completely separate latency compensation for each articulation release time which may not at all match the latency of the attack and would also vary between different articulations.

Nobody has really been addressing this or thinking about it in such detail, and who wants to? Too much to think about. But I think in general it’s easier to play in parts and release early instinctively then it is to start thr attack early.

If simple mode tends to sound better or right in some way then by all means use that. I think when dealing with some libraries that have really long attack latency such as legatos and portamemtos you may find that simple mode will be starting the release too soon for the last note of a legato phrase.
 
@Dewdman42 I've finally been able to devote some time to all this, and I wonder:

Since the Environment really has no concept of MIDI FX plug-ins (at least as far as I can tell—it seems to assume they are the same plug-in as the loaded instrument plug-in, which is annoying), shouldn't there a way to toggle Scripter's behaviors from within Scripter itself via a MIDI control value that it's listening for?

Something like (excuse my rusty pseudo-JS):

JavaScript:
controlCC = 99 // for example


if (controlCC) {
    if (LSB = 0) {
        // pass all other MIDI through without processing
    };

    if (LSB = 1) {
        // do the thing
    };

    if (LSB = n) {
        // maybe some other option
    };
);
 
I'm not understanding what you're trying to do or why?

But yes, the environment does not support any midifx plugins

And yes its certainly possible in script to listen for various midi events to come in and control its behavior that way, but its a little more involved then using normal automation. Most plugins use automation, and then if you want to use midi to control the automation, you use smart controls to affect the automation. Actual midi controlled FX plugins are very rare. But anyway, its certainly possible to do it in Scripter, but its a bit more involved.
 
I'm not understanding what you're trying to do or why?

But yes, the environment does not support any midifx plugins

And yes its certainly possible in script to listen for various midi events to come in and control its behavior that way, but its a little more involved then using normal automation. Most plugins use automation, and then if you want to use midi to control the automation, you use smart controls to affect the automation. Actual midi controlled FX plugins are very rare. But anyway, its certainly possible to do it in Scripter, but its a bit more involved.
Basically I am trying to use ArtAlign (JSON) to control the lookahead behaviors of VEP. Using Smart Controls to toggle the enable/bypass of the Scripter plug-in, however, causes some associated MIDI CC automation data I am trying to send to the VEP instance (for enabling/disabling Latency Fixer instances) to get lost... but only when disabling the Scripter plug-in. (In other words, those Latency Fixers receive all 'enable' signals, but no 'bypass' signals).

In my mind, the most elegant solution would be to have an ArtAlign that is in a Scripter that is always enabled, and the scripted behaviors would instead be toggled rather than the plug-in state itself.

So, something like this:



this.png
So we'd have these rules:

1. Scripter plug-in is always on.
2. Smart Controls toggle the state of the 'Compensation Enabled' checkbox.
3. If checkbox is checked, MIDI enters the preset latency compensations per port/channel etc. as defined in JSON.
4. If checkbox is empty, MIDI passes through Scripter as if Scripter did not exist.
 
Basically I am trying to use ArtAlign (JSON) to control the lookahead behaviors of VEP.

First of all ArtAlign doesn't change the lookahead behavior of VePro. It simply adds a different amount of latency to each note depending on how you have the JSON configured.


Using Smart Controls to toggle the enable/bypass of the Scripter plug-in, however, causes some associated MIDI CC automation data I am trying to send to the VEP instance (for enabling/disabling Latency Fixer instances) to get lost...

Why are you enabling and disabling it?

but only when disabling the Scripter plug-in. (In other words, those Latency Fixers receive all 'enable' signals, but no 'bypass' signals).

Why would latency fixer be receiving the same automation to enable disable? that doesn't make sense.


In my mind, the most elegant solution would be to have an ArtAlign that is in a Scripter that is always enabled, and the scripted behaviors would instead be toggled rather than the plug-in state itself.


again, I don't really understand exactly what you're trying to do. The only reason for that checkbox is not to enable it and disable it dynamically while playing. its so that you can turn it if when you want to play in a part with your midi controller, because otherwise a lot of delay will be added. its easier to play in the part with the delay minimized.

It doesn't sound you are using the script properly. please read the wiki docs careful to understand it.

I will not have any time to work on these scripts any time soon, but if you would like to contribute some ideas please post an issue request through the gitlab website.

you are of course welcome to take the script and tweak it to your heart's content if you want to dynamically enable/disable its behavior during playback but I'm not sure why you would want to do that.
 
First of all ArtAlign doesn't change the lookahead behavior of VePro. It simply adds a different amount of latency to each note depending on how you have the JSON configured.
Right, it compensates for whatever Latency Fixer values are being fed.

Why are you enabling and disabling it?
I'm using it as part of a whole modal template setup where I have 1 of 2 states true — a low-latency tracking mode and a high-latency mixing mode. It shouldn't be active while I'm tracking, but it should be active while I'm mixing.

Why would latency fixer be receiving the same automation to enable disable? that doesn't make sense.
It's not—it's receiving a separate control (CC33), but when Scripter plug-ins toggle (as part of a Smart Control/Summing Stack setup) they block simultaneous CC messages on disable.
again, I don't really understand exactly what you're trying to do. The only reason for that checkbox is not to enable it and disable it dynamically while playing. its so that you can turn it if when you want to play in a part with your midi controller, because otherwise a lot of delay will be added. its easier to play in the part with the delay minimized.
Right, it's a modality, not something to be tweaked live.

It doesn't sound you are using the script properly. please read the wiki docs careful to understand it.
I have, but it (+ a delay compensation plug-in) does not behave properly if used in the way specified in the wiki. That combo *does* behave properly when the delay compensation plug-in is hosted within VEP instead of in Logic. It works fine when drawing in automation to achieve the two toggles (that is: Latency Fixer on/off; ArtAlign active/inactive).

However, I don't want to draw in automation to automate this (as this shouldn't be a dynamic automation, nor should it be tied to anything in the playback/rendering, but should simply be a modal state), so the only way to accomplish such a change without drawing in automation is to have a toggle button that sends a control (or multiple controls) at the same time.

But without drawn in automation, the only way to control both things simultaneously is to send it simultaneously...which is impossible when disabling Scripter blocks MIDI thru at that moment.

I will not have any time to work on these scripts any time soon, but if you would like to contribute some ideas please post an issue request through the gitlab website.

you are of course welcome to take the script and tweak it to your heart's content if you want to dynamically enable/disable its behavior during playback but I'm not sure why you would want to do that.

Thankfully, that is not what I am trying to do.
 
Thinking outside the box...

The 'Record' track (channel-port) doesn't care whether or not Scripter is engaged or bypassed, so it acts as a bridge through the whole plug-in state toggle process.

It's not pretty, but it works!
 
I have, but it (+ a delay compensation plug-in) does not behave properly if used in the way specified in the wiki. That combo *does* behave properly when the delay compensation plug-in is hosted within VEP instead of in Logic.
That's why the first line of the wiki says "its still under development". Sorry but I will not be able to spend much or any time working on these scripts any time soon, as I have moved on to DP, which has latency compensation built in.

What I can say about the latency fixer only working inside VePro, must be because VePro itself imposes more latency then the Scripter script does. Not sure, Apple has been messing around a lot lately with PDC related bugs so who knows. but yea...if you use the midi negative delay that should work better...or use it inside VePro as you already figured out. I don' have time to investigate it or update the wiki anytime in the near future. Please report bugs on the gitlab issue tracker. Thanks.

Good luck.
 
Top Bottom