watarupop

When the CPU usage is very high, Max messages sent via send object are delayed.

My live set patch is a collection of bpatchers (kick, sample player, granular and etc) synced by master transport.

At the main patch, master bangs (16n) are generated by metro and transport objects and sent via send object. All the sub patchers have different sequences(live.step) and they are triggered by the bang sent from the parent patch.

There is no problem when the patch uses around 40 % of CPU. The bang is sent instantly to every sub patchers. However, at the high CPU usage like 50 ~ 60%, the bang (16n) is suddenly delayed like 20 - 30milliseconds. It occurs randomly. some sub patchers receive the bang instantly while others not. And once it is delayed, it keeps delayed.

The issue mostly occurred when other applications demand CPU and the problem is, I can't predict when to happen this.

It has been bothering me much as my live performance is a kind of techno and the trigger timing is very important. ( Imagine every hi-hat suddenly becomes out of sync to 4 to 4 beat. It is just horrible experience when you perform)

So, my question is, is there any way to improve the timing, or any solutions to fix this?

I thought send object causes the problem. Might I need to stop using it for sending the master clock and add transport + metro objects to every sub patchers?

My live set patch is a collection of bpatchers (kick, sample player, granular and etc) synced by master transport. 

When the CPU usage is very high, Max messages sent via send object are delayed.
My live set patch is a collection of bpatchers (kick, sample

messages-sent-via-send-object-are-delayed-at-the-high-cpu-usage

those 20 ms are most likely one vector. if a bang can not be delivered in time you might loose a complete vector (compared to other places) when it triggers something signal.

i cant comment on the exact reason why send doesnt work in live.


those 20 ms are most likely one vector. if a bang can not be delivered in time you might loose a complete vector (compared to other places) when it triggers something signal.

i cant comment on the exact reason why send doesnt work in live.


There isn't anyt any trouble while the patch makes use of round 40 % of CPU. The bang is despatched immediately to each sub patchers. However, on the excessive CPU utilization like 50 ~ 60%, the bang (16n) is unexpectedly behind schedule like 20 - 30milliseconds. It happens randomly. a few sub patchers get hold of the bang immediately at the same time as others not. And as soon as it's far behind schedule, it maintains behind schedule.

You might want to check that what is not important time-wise is sent "slower" than what is important.

If some events are less critical than others (for instance UI updates, etc.), you can forward them to the low-priority thread (using [deferlow], for instance.)

Other idea: slow down the graphical updates that don't need to be that fast (how fast do you update your [meter~], etc.? )

Other idea: experiment with vector size and the Audio Status settings. Maybe a larger vector size would be better for you: you might prefer everything in sync~ rather than smallest latency?

You might want to check that what is not important time-wise is sent "slower" than what is important.
If some events are less critical than others (for instance UI updates, etc.), you can forward them to the low-priority thread (using [deferlow], for instance.)
Other idea: slow down the graphical updates that don't need to be that fast (how fast do you update your [meter~], etc.? )
Other idea: experiment with vector size and the Audio Status settings. Maybe a larger vector size would be better for you: you might prefer everything in sync~ rather than smallest latency?

It looks the issue would be only solved by the sum of small improvements.

Increasing vector size causes loose rhythm in my experiments so I might need to stick to smaller vector size to keep the trigger timing tighter. Instead, I will check time-wisely unnecessary messages that are consuming vector and send them to low-priority thread. slowing down the graphical updates could be effective, too.

It looks the issue would be only solved by the sum of small improvements. 

Increasing vector size causes loose rhythm in my experiments so I might need to stick to smaller vector size to keep the trigger timing tighter. Instead, I will check time-wisely unnecessary messages that are consuming vector and send them to low-priority thread.  slowing down the graphical updates could be effective, too.

Messages sent via send object are delayed at the high CPU usage