Sorry, but I think this is where you are a bit wrong. HT doesn’t “halve” the transistors for each logical processor, all the execution resources of the core can only used by one cpu thread at the time, but that completely… What is duplicated are all the registers that define the state of a compute thread, so that when one of those two processes stalls (because of a cache miss or it has to fetch data from memory), the other one can be quickly executed “in between”.
But yeah, HT is of course still active for Cubase without multiprocessing, and cubase has enough threads running apart from the audio thread that it uses all logical processors once in a while. As vinark correctly wrote, you cannot disable HT from the OS side (that is why I think that the preset “disable HT” in that before mentioned process lasso thing is not precisely named)
Hi @fese , you were right it is not a HT problem! And you are also right in explaining HT to Louis, glad you did that! And I agree about the lasso naming too, although the full name is 'don’t use virtual HT cores", which is more precise then what I wrote lol.
And I was surprised that lasso worked for VEP too.
@Louis, it is a very powerful laptop, better and faster then my current desktops, it runs at 4ghz with all 6 cores/12 HT cores also under full load.
With HT disabled it runs VEP better then any of my 4 desktops, which are all 4 cores at 3.6ghz no HT. Only my main DAW runs at 4ghz (4 cores)
Exactly and I am sure they fixed that in a later version. My hope was (for you) that the spitfire issue was the same issue, how they schedule, but alas…
I have one more theory, but it is not helpful, but explains why the issue goes away when not in record or monitoring mode and why it does not happen all the time. And it is unfixable then I guess.
In live mode (record or monitor) Midi data can be entered into a buffer that is currently being processed, if the midi command comes at the beginning or mid buffer there is no issue, but right before the end of the buffer there is no time to fetch the samples in time for the buffer has to be send. You can easily test this hypothesis by watching for clicks with a very small buffer size and then a very large. It should occur with both, but less often with the larger buffer as there is less change of being at the end off a buffer.
Cheers!
@fese Thank you so much for clearing that out !
For some reason I really thought the CPU was able to process two operations simultaneously on a single core… Which is totally impossible after thinking a bit 
That makes total sense that it uses two separate registers so the next task becomes ready while the core is still busy computing the previous one, that speeds up things.
@vinark What you say about MIDI buffering is very interesting. When I increase the buffer to 1024 or 2048 it happens less often, but from 32 to 512 it happens on almost every key press, and key release too.
This still does not explain why disabling multi-core fixes it, and most importantly, why it only happens with two same instruments.
Obviously when ASIO Guard is in use when the tracks are not monitored, the issue doesn’t occur because there is enough headroom. But, maybe ASIO Guard changes the way data is processed (I mean, not only adding latency), so this may explain why it only happens in real-time mode.
Are you talking about the instrument samples/files or audio data samples ?
If fetching the samples was taking that long and was so heavy on the CPU then it should happen on many other instruments from many developers, but that doesn’t seem to be the case. When we play a VST piano, synth, drums or whatever instrument, it happens naturally that at some point we hit a note very close to the end of the buffer, yet we don’t notice any dropout.
Cheers guys, thank you both for your input!
Ok, here are new findings :
When the dropouts are occurring, tweaking the core affinity for Cubase.exe in Task Manager (for example, disabling one core, doesn’t matter which one) makes the dropouts go away completely !
However, as soon as we tweak the buffer size, the dropouts appear again, which is again fixed by tweaking the core affinity (even if we check back all cores).
Tweaking the core affinity seems to “rearrange” the instructions between the cores so they do not clash any longer, but as soon as we touch the buffer (which resets the audio engine) it becomes buggy again.
Please tell me how strange is this !
Also, if we toggle Multi Processing back and forth during the “affinity fix” (when at least one core is disabled), the issue comes back but this time it’s glitching out even more than before, sometimes it makes long glitching noises and after a while it completely drops out for a brief moment (just like when changing the buffer / audio engine is reset), and when it does that the current MIDI note will hang, like if Cubase (or Spitfire ?) was trying to use the disabled core.
This is 100% process scheduling fault right here.
It now remains to be determined whether it comes from Cubase, Spitfire, or Windows.
I have sent a ticket to Spitfire and put a link to this topic.
Good work @Louis_R And I thought the same: link the thread for spitfire support. They can see all we tried and maybe have a giggle at our understanding of processing 
. Lets see where the ball drops, who blames who…
I hope it is an easy fix!
Yeah, that is weird poop… I cannot begin to think why disabling one core should lead to a different result. 
Alright, the issue is being investigated by the Spitfire developers.
I’ll update here as soon as I hear back.
What was the answer to this problem? I have exactly the same issue 1 year later. What did you come up with Louis?
Hi, the latest answer I got from Spitfire is from August 2023, saying the developers have been notified and will investigate the issue (it’s been the third time I’m getting told the same story so I don’t expect the issue to be investigated at all, it’s been one year lol)
Most probable thing is that the issue originates from the VST code, so it’s Steinberg’s job to do that. Many plugins exhibit the same issue (“dropouts on playback when multi-core is enabled” to name it, regardless of the trigger) so this proves it isn’t plugin-specific but global. There may be some broken code at some point when using specific VST parameters combinations. There’s no other explanation.
Thanks for replying Louis. I searched this topic for a while before I found your thread. I noticed a number of Kontakt player users having the same problem. I emailed Spitfire and referred to your posts. No answers from them, Cubase 13 did not fix the problem either. My Laptop and Tower are both showing the same CPU spike using Cubase 13.
I tried many workarounds, but I’m currently using this solution that I passed on to Spitfire.
Create 2 spitfire instances (Instruments) Then create 2 midi tracks assigning them to each Spitfire instruments. Arm only the midi tracks. There is still some spiking, but my audio doesn’t drop out anymore. What’s more interesting when playing back the recording it plays back perfectly, no CPU spiking. The recorded parts seem fine where it did Spike, only happened twice during the recording.
I was reading about a few Kontakt Player users thought it was a midi overload/feedback problem. You also mentioned it could be a midi related issue. Give this a try if you haven’t already. I’m curious to see if it works for you.
Thanks, Pete.