>>Input of Track A to Cthulu and also setting the Direct Input of the instrument on Track A to Cthulu>>

I haven't seen that an instrument has an input as well as the track...

I was using Clthulu last night and I noticed it's a resource hog, mainly because it can send a lot of notes to the synth which then uses a lot of resources. I have crashes on occasion messing with the arpeggiators.

Haven't experienced any lag though, what latency are you running and what is your soundcard?

Good to put all your specs in your signature...

Specs are
64bit Win10, i7 4703HQ, 16 GB RAM, 125MB SSD
Interface: Babyface Pro

I don't think the issue is system related, and Cthulhu is not a resource hog that I can tell, barely registered 1% on the CPU list. Same issue happens with all the arp plugins I tried

My arp pattern was very simple. When I record, I get just over 1/64th offset between the recorded notes and the arp trigger notes. Not talking about soundcard latency, just information being routed internally between tracks.

I haven't seen that an instrument has an input as well as the track...

Direct Input is on the Instrument tab itself, you can pull the output from Cthulhu directly, no need for monitoring to hear it, except you can't record the output.



I tried with a new, blank project with only an instrument, arp and drum track and there appeared to be no offset either through Input or Direct Input. I also tried removing tracks one at a time from the original song, and the delay finally went away after I had removed all but 7 tracks/instruments.

Perhaps Studio One does not have very robust (or any) delay compensation/synchronization for midi routing between tracks?

Any MIDI settings that might help this issue?

I'm afraid there's nothing you can do about it other than adjusting the data by the amount of total plugin-delay or temporarily disable/deactivate the plugs introducing extra latency.

I'm not experiencing any discernable delay from cthihlu, and CPU is 1%.

Typically, I connect to Cithuhlu first as it has its own sound generator for a reference), and cithuhlu's output will go to the instrument I'm looking to sound that instruments output. No delay associated before or after anywhere. The 64th delay you're experiencing on track A is pretty substantial. Look at any settings coming from your controller, or arpegiator patching.

You shouldn't be seeing any lag between tracks A & B at all.

Have Arps in this or any other connections ever worked for you before?

Simple test: Try doing an audio recording patching the track output in the same way. In other words, patch to track A, and output that track to another audio track (or bus output). Even before recording, are you seeing a delay between the two track's meters? It's basically the same patching scenario. There should be no delay.

What is your controller? Also check if you have any behind the scenes MIDI mapping going on.

I would target the delay between tracks A and B. Something's not right. Do you have any delay effects, or sidechaining going on?

There was always something like this happening in cubase, different things happened but it was in direct midi recording. Anyway the answer was to check or uncheck USE SYSTEM TIMESTAMP.
S1 has ignore system timestamp, might give it a try.

Tacman7 wroteThere was always something like this happening in cubase, different things happened but it was in direct midi recording. Anyway the answer was to check or uncheck USE SYSTEM TIMESTAMP.
S1 has ignore system timestamp, might give it a try.

No difference either way, unfortunately.

I would target the delay between tracks A and B. Something's not right. Do you have any delay effects, or sidechaining going on?

I tried re-creating my song track by track and testing the midi latency at each step.

Everything was in sync until I added a third party plugin - Virtual Tape Machine by Slate Digital, and then suddenly I had the 1/64th and a bit offset in the recording.

My guess is that the PDC induced by the Virtual Tape Machine is not being synchronized with the MIDI routing .. or something like that. Probably this is not something can (or should?) be fixed ..

Perhaps the reason there is no offset in Ableton is that Ableton does not have proper PDC implemented?

I need to add more separation between my composition and the mixdown

seanjordan wrote: Everything was in sync until I added a third party plugin - Virtual Tape Machine by Slate Digital, and then suddenly I had the 1/64th and a bit offset in the recording.

My guess is that the PDC induced by the Virtual Tape Machine is not being synchronized with the MIDI routing .. or something like that. Probably this is not something can (or should?) be fixed ..

Huh. Those tape emularion devices have very minimal delay, but are typical in producing high tape saturation.which does invoke high CPU load. But somehow as you stated, you saw cithuhlu with high CPU. I've seen that happen in S1, where something else picks up all the CPU baggage. Until you wring everything out.

Usually the result is pops and clicks when the CPU meter gets high enough. I haven't heard of delays though.

Keep checking for further delay causes. Right now though, the culprit enters as you say from 3rd party plugins. Any other issues with other plugins other than introducung Slate tape? The audio lag is unusual. I would again check all routings, and even properties. Each thing you do or take in/out, watch CPU and track input meters.

One test I always do when I can't explain some occurence is start fresh with an entirely new song. No template, nothing. Just new. See if the delay still happens from basic levels pick new patches, and check. Then enter the patches you have now, and check.

The devil lies in the details.

Lokeyfly wroteHuh. Those tape emularion devices have very minimal delay, but are typical in producing high tape saturation.which does invoke high CPU load. But somehow as you stated, you saw cithuhlu with high CPU. I've seen that happen in S1, where something else picks up all the CPU baggage. Until you wring everything out.

CPU load was minimal.

I see, just lag only.

Any success starting a new song?

If not, isolate the controller altogether, by triggering notes using the Qwerty keyboard.

If lag still exists, you only have your track A & B, all over again.

So from what I'm hearing, it's only the Slate Tape plugin.

Follow the troubleshooting outlined. It's designed to isolate and compare up to the trouble you're having.

Perhaps throw in some screens shots along with any results. No delay should happen between tracks from direct S1 track patching assignments.

Not sure tape saturation is really necessary, so early on. That's typically more of a post treatment. It's not going to make or break the arp connection. Of the Slate Tape is entirely elsewhere, turn it off for now. Not that that's an answer, but it's a pretty subtle (yet high consumption) effect to get in the way.

I have the Waves Kramer Tape, and no such delays.

Remember, start "completely" fresh and let us know.

It's reproducible behavior with any VST that adds to the song's total plugin delay.

Repro

1. Create Empty Song
2. Add VST with MIDI out capability
3. Add Mai Tai + Instrument track and route its input from the VST with MIDI out
4. Add 10 instances of the Gate plugin with Look ahead enabled to simulate 20ms latency (optionally you can bypass them)
5. Record the MIDI output data from the VST to the Mai Tai Instrument track

Result: The MIDI received from the VST to the Mai Tai track is placed 20ms later (red track in the gif).
Expected result: The introduced latency is compensated, since MIDI data is received from a singular device within the Studio One instance and the total plugin delay is known by Studio One.

Lokeyfly wrote

seanjordan wrote: Everything was in sync until I added a third party plugin - Virtual Tape Machine by Slate Digital, and then suddenly I had the 1/64th and a bit offset in the recording.

My guess is that the PDC induced by the Virtual Tape Machine is not being koo with the MIDI routing .. or something like that. Probably this is not something can (or should?) be fixed ..

Huh. Those tape emularion devices have very minimal delay, but are typical in producing high tape saturation.which does invoke high CPU load. But somehow as you stated, you saw cithuhlu with high CPU. I've seen that happen in S1, where something else picks up all the CPU baggage. Until you wring everything out.

State's VTM has a 39ms delay if my memory serves me right. It's built into how they modeled it, factoring in the time it takes the tape to travel between the two different tape heads.

Two suggestions that may not help but are worth a shot: 1) make sure you're running the most recent updates of VTM and 2) try the VST2 version if using VST3, and vice versa.

Last thing, if nothing works, just bypass latency inducing plugins while tracking. The latency should get compensated for during playback, so it would only be temporary.

Thanks all for the replies, I expect this is an omission in S1 and for now I will work around it avoiding plugins which introduce delay during the composition stage. Lokefly you are correct, no need for tape delay so early on.

niles wroteIt's reproducible behavior with any VST that adds to the song's total plugin delay

Very nice

Niles wrote: It's reproducible behavior with any VST that adds to the song's total plugin delay.

Repro
Create Empty Song
Add VST with MIDI out capability
Add Mai Tai + Instrument track and route its input from the VST with MIDI out
Add 10 instances of the Gate plugin with Look ahead enabled to simulate 20ms latency (optionally you can bypass them)
Record the MIDI output data from the VST to the Mai Tai Instrument track

Result: The MIDI received from the VST to the Mai Tai track is placed 20ms later (red track in the gif).
Expected result: The introduced latency is compensated, since MIDI data is received from a singular device within the Studio One instance and the total plugin delay is known by Studio One

.
the OP is experiencing about a 64th delay. The 64th somewhat questionable by the tempo but we get the picture.

Of course latency is reproducible, but getting lengths greater then 20ms is unnacceptable, unless something is very wrong. The OP is working from what seems to be a small number of tracks from his information (as I see it, I could be wrong).

I don't get your example as why in God's green earth would someone run 10 instances of the gate plugin with look ahead enabled to simulate 20 ms. It's so much easier to decipher latency than from an already tainted source. The subject was about Cithuhlu, arpegiators and as we've come to realize, Slate's VTM. Effectively the culprit.

Attempting to produce some controlled latency, I don't get at all, in your example. Who's looking for reproducible behavior?

Funkybot wrote: State's VTM has a 39ms delay if my memory serves me right. It's built into how they modeled it, factoring in the time it takes the tape to travel between the two different tape heads

I see. Thanks man. I have never used Slate's MTS, and that definitely points to something (I used to repair Studer Revox reel to reel decks in the 70's).

It's interesting how Slate would incorporate tape delay (obviously varies by tape speed), because the essence isn't trying to include tape delay as that is a physical tape delay, when the goal is typically capturing just the saturation. But I've met Steven at times at the AES show, and he is a purist at heart. hopefully I can ask remember to ask someone there why they would bother with reel world analog 39ms tape delay. (Glad you clarified that). A lot does bank on that reproduction of the playback head including tape bias, and even the tape used, head alignment (azimuth), etc. UAD also get pretty esoteric with their tape saturation plugin, as you can pick the machine, tape, speed, etc. But delay sort of caught me off guard,

seanjorden wrote: Lokefly you are correct, no need for tape delay so early on.

Cool. Hope you have it sorted otherwise. Just throwing this out there. If you still want the Slate MTS running (I feel ya being a guitarist), then you may want to try sending FX, and it would still be coming out of the Master out, or monitor as needed.

I suspect the 39 ms delay is switchable? And Slate simply added it as an alternate echo option, which multi head playback tape decks could do.

Good luck.

Lokeyfly wroteI don't get your example as why in God's green earth would someone run 10 instances of the gate plugin with look ahead enabled to simulate 20 ms. It's so much easier to decipher latency than from an already tainted source. The subject was about Cithuhlu, arpegiators and as we've come to realize, Slate's VTM. Effectively the culprit.

Any VST introducing latency will interfere with the timing of any VST that will output it's MIDI data to the host. I used the Gate to reproduce it because every Studio One user (and the developer) has it.

Lokeyfly wroteAttempting to produce some controlled latency, I don't get at all, in your example. Who's looking for reproducible behavior?

The developers, so they can reproduce and eventually fix it.

When we have a flat tire (a problem), we'll call you to produce a flat tire for us to know how to fix a flat tire.

Your process of creating a 20 ms delay (which in many ways can be done far easier) in no way helps a user determine their existing "delayed" condition.

But thanks all the same.