Particle SOP Birth Pulse steps simulation forward, another way to do this?

I was trying to use the Particle SOP to get some built in useful data for a particular technique i’d like to employ that could utilize the built in velocity/physics in the Particle SOP, but I’m just about to scrap that to make some sort of more customized particle system in python/script sop/shader or something. But I wanted to bring to light the issue I’m having as I think it is something that might ought to be looked at.

When using the Birth pulse parameter of the particle SOP it seems, like all other pulses, to force cook the node, which I believe causes another step in the simulation. My hope is to very exactly add a certain number of births with specific starting positions and attributes when these external events occur ( like a midi note), similar to some other questions/posts in the forum. Event CHOP would typically work, but I’d really like the physics part of the ParticleSOP.

In this attached TOX you can see that if you increase the births per release ( in the large constant CHOP towards left of network) the system steps more and more forward, lurching with each cluster of births driven by a Chop execute > frame start execute setup ( i did this in hopes that running the new births at frame start might avoid the hiccup). Would be cool if there was some python method to hand the Particle SOP a list of starting positions and attributes to birth within a single frame or very short range of frames perhaps? Or another solution with current OPs/functionality if anyone has a thought there…

Managing the birthrate and trying to adapt the input for this level of precision doesn’t seem feasible as the events I have coming in may be pretty rapid, and I think I’ll already need to build some kind of buffer to handle them and pop them into whatever system i use.

particleEventsIssue.tox (3.9 KB)