Midi clock weirdness
So I've noticed some odd behavior that maybe one of you guys can clarify for me.
I have two computers connected via midi network and sending midi sync messages from machine A (Master) to machine B (slave).
What I noticed is that M4L plugins if being used on machine B cause huge spikes in CPU usage after play is pushed. The more plugins you have and the more complex they are the more it makes the usage spike. I'm talking about going from 7% to 38-42%, with nothing happening other than running the transport.
This does not happen if
1) machine B is set to master and machine A set to slave (keeping everything the same otherwise, meaning less M4L plugins being run on the slave)
or
2) the machines are not synced and machine B is set to play on its own
I tried with non-M4L plugins and there are no serious CPU spikes, regardless of how large I make a project with lots of VSTs, effects, etc.
Why would M4L plugins be affected by the host program being a slave?
It gets weirder.
I've noticed that the more I open a project that has lots of more complex M4L plugins without quitting Live first, the higher the usage goes up.
First time I open the project and push play it'll start at ~22%. The second time I open the project (without quitting Live first) it'll go up to ~30%. Third, up to ~42%. So on.
Anyone have an explanation for this????
I'm so confused...
EDIT:
What I've noticed:
When I run machine B solo the spike only occurs at the beginning of the arrangement loop. I have it looping on 1 bar for quantization purposes and when it starts the loop over again, that's where the spike happens.
Bump?
it's hard to speculate without seeing what devices you're working with, also it might be worth emailing support for a more thorough investigation
It doesn't matter what devices are being used, it occurs as long as there are M4L plugins. If there are no M4L plugins, no problem.
What I noticed is that the M4L patches can actually have NOTHING in them, but the more there are of them the more there's a spike that occurs on the slave and only at the beginning of the arrangement loop.
Does not happen if not on the loop but still slave
Does not happen if not slave but on the loop
I also tested making both machines slaves and using a standalone Max patch to send midi clock signals to both, same result but on both machines
If it's slave and looping = spike
I think you're right though, should probably bring it to their attention.
Also want to bring up the whole
"Parameter: record_length (optional)
launch_quantization (optional)
Fires the clip or triggers the stop button, if any. Starts recording if slot is empty and track is armed. Starts recording of armed and empty subtracks if Preferences->Launch->Start Recording on Scene Launch is ON. If record_length is provided, the slot will record for the given length in beats. launch_quantization overrides the global quantization if provided."
From the LOM, launch_quantization for clip_slots doesn't work.
sounds like it may be some kind of bug, or it's something unavoidable about Max's implementation in Live.
As for launch_quantization, I'm not sure I understand what you're saying. You know that it's just the name for an optional argument you would pass along with the "fire" call to a clip_slot right? Are you saying that the fire function doesn't work or that passing the argument with the call has no effect? You may be getting the syntax wrong or you need to pass the launch_quantization argument after the record_length for it to be understood as such.
I've just realized I've made a huge mistake. The launch_quantization is not set the same as the record_quantization.
1. You need to set the arrangement loop to the first bar
2. Record_quantization is in beats
3. Launch_quantization is in clip_trigger_quantization integers i.e. 1= 8 bars, 3= 2 bars, etc. (not in beats like I thought it was)
EDIT: doesn't allow for call firing with launch_quantization on already existing clips though