'Pulse Generator' irregularity of pulse triggers emitted?

bonemap

Hi,

I often use the 'Pulse Generator' to add particle instances through the '3D Particles' module. I know there have been previous threads that discuss the inconsistency of Pulse Generator triggers. Currently, it appears the Pulse Generator accuracy and consistency is easily disrupted by other operations within the Isadora program for example, cross fading between scenes, scrolling the Scene Editor etc.

Is there any updated advice for achieving an accurate and consistent pulse trigger? Or advice about how to generate a consistent and regulated stream of triggers that will not be so noticeably affected by other operations?

best wishes

bonemap

mark

@bonemap said:

Is there any updated advice for achieving an accurate and consistent pulse trigger? Or advice about how to generate a consistent and regulated stream of triggers that will not be so noticeably affected by other operations?

At the bottom right corner of the main user interface you'll see Cycles value. This number indicates how many times per second Isadora can execute all of the actors in the scene that need attention. This frequency of this number is determined by the Target Frame Rate and General Service Task settings in the General tab of the Isadora Preferences. The default for these values is 30 fps and 8 cycles per frame, which yields a target Cycles per second of 240.

The key to addressing the issue you bring up is keeping the Cycles value as rate as high as possible. Video plugins are typically processed at the video frame rate, but anything else that deals with time is serviced at the rate indicated by the Cycles value. This includes the Envelope Generator, the Wave Generator, and the Pulse Generator just to name a few.

But, if the number of pulses is inaccurate, it indicates a bigger problem with your patch in terms of demand. If you have a Pulse Generator running at 60 Hz, and the Cycles value dips to 15 cycles per second (cps) during a heavy cross fade, certainly the pulses will be inaccurate because that actor is getting serviced at a rate less than the desired pulse rate. But more importantly, whatever the Pulse Generator is connected to is also being serviced at a rate less than you desire.

I'm assuming you're using the Pulse Generator to trigger the addition of Particles to a particle system. Using the example above where the Cycles value drops to 15 cps (meaning 15Hz), not only is the Pulse Generator getting serviced at a low rate, but so is your 3D Particles actor. Even if the Pulse Generator was pulsing at 60Hz, it wouldn't matter because the 3D Particles actor would only add a particle 15 times per second.

The bottom line basically comes down to an old saying we have in English: "you can't get blood from a turnip." If the cycles rate stays high, the Pulse Generator can pulse at the desired rate and it will not seem inaccurate. If it gets too low, all actors are running slowly and you need to find a way to reduce the bandwidth/CPU demands of your patch.

Best Wishes,
Mark

bonemap

@mark

Thank you for your advice, I will tweak the frame service settings some more, but basically the approach you are suggesting is to find an acceptable balance at the limit of what can be achieved by available cycles and beware of additional processes that will effect these available cycle rates.

Or to look at a way to pre-render these non-video generative outputs (perhaps with more moderate demands) and reiterate as video files in the patch?

In such a case the real-time generative quality is compromised - but the playback presentation can be flawless?

Best wishes,

Bonemap

mark

@bonemap

Tweaking the settings isn't really going to help if you're CPU is overloaded with work. There simply won't be any cycles available, regardless of how you set the preferences.

The 3D Particles actor, when you've got mucho particles, can be a CPU hog -- especially if you've got lots of 3D Particles actors running at the same time. At a certain point, rendering those out to video would likely benefit your situation.

Best Wishes,
Mark

Woland

@mark @bonemap

Strange idea, but would ditching the Pulse Generator and hooking up a Wave Generator actor (for a constant flow of data/triggers) to a Multiblocker actor (set so that it allows triggers through at the desired rate) make any difference, or would it still have the same issue?

Theoretically, you could use a single Wave Generator and hook it up to any number of Multiblockers (each set to the rate of what each of your Pulse Generators used to be), thereby reducing a bit of strain on the computer, as it'll only be running one Wave Generator instead of "x" number of Pulse Generators.

I'm in the middle of something so I've not actually tested if this works the way I think it will though.

Best wishes,

Woland

mark

@woland said:

Strange idea, but would ditching the Pulse Generator and hooking up a Wave Generator actor (for a constant flow of data/triggers) to a Multiblocker actor (set so that it allows triggers through at the desired rate) make any difference, or would it still have the same issue?

Nice idea Lucas, but it unfortunately won't offer any improvement over the Pulse Generator. As I said, you can't get blood from a turnip: if your whole patch is running at 15 cycles per second, you can get anything inside it to go any faster than that.

Best Wishes,
Mark

DusX

process optimization is really the only 'fix' and that's assuming there is something that can be done more 'light weight'.

Eg: just yesterday I used a vector clock I built as a user actor in a new way (not my original intention). I set it up so that it would scale to a rhythm, in fact it scales thru itself to a reverse view... anyway... the scaling was bringing my frame rate down to 10 (and my cycles). I dug into the user actor and eventually found that switching off (using the user actor on/off) that one sub user actor was causing the slow down. In side this I was using the horz and vert inputs of a few Edit Text actors (one for each: 12,3,6,9). Luckily these fed directly to a projector each.. so I changed the positioning to be done by the Projectors. This allowed the text to be rendered once only.

Now runs smooth at 30fps and 200++ cycles.

bonemap

@dusx said:

Now runs smooth at 30fps and 200++ cycles.

Thanks Ryan,

I had prepared my patch to meet an optimum running rate i.e. around 30 FPS and 240 cps. The issue is then what happens next, if I cross fade to another Scene, for example, I will loose cycles on both the current and next scenes and more disruptive there is a noticeable jump/glitch reminiscent of ‘dropping frames’ at precisely the moment that the next Scene Editor appears in the view port.

As reported by others in previous forum threads scrolling around the Scene Editor viewport significantly reduces FPS and cps. I would be interested to know why and if I can do anything to fix it.

I am building Isadora states that are intended to compliment types of improvised performance including sonic and choreographic forms. I dreamt of building a responsive engine that could meet the free impro of my collaborators in movement and sound. It is the small glitches that break the magic for me.

Best wishes

Bonemap

DusX

cross fade jumps are hard. You are running double the processing during the jump.

mark

@bonemap said:

As reported by others in previous forum threads scrolling around the Scene Editor viewport significantly reduces FPS and cps. I would be interested to know why and if I can do anything to fix it.

First, you are probably particularly susceptible to this slowdown because the 3D Particles actor are CPU intensive. Because you're already pushing things so hard with this actor in most of your patches, you are particularly susceptible to problems with scrolling because the CPU is already heading towards a maxed out state.

That said, the main issue –- which seems noticeably worse on High Sierra -- is drawing all the text in the actors. I think you can prove this is true with the following experiment: in a scene where you see this slowdown during scrolling, create two actors that are way to the left of your "real" actors, one at the top left and one to the left and far enough down that you can scroll quite a ways. If you line up the screen so you only see these two actors, the others will be beyond the right edge of the Scene Editor and will not be drawn. If you then scroll vertically, you should see little noticeable affect.Another experiment: put big chunks of your patch inside User Actors. You'll see the same improvement I reckon.

We did several things to improve this substantially in v2.5.2... if you run v2.2.2 you'll see that this issue is much more noticeable.

I communicated with Apple Tech Support about this when High Sierra first appeared. Their response to my extensive bug report which showed that text drawing on High Sierra was noticeably slower than on previous versions was, essentially, "That observation sounds correct to us" instead of "Oh my! We'll make that better." :-(

And, while I'm sure you know this already, make sure that Adobe Creative Cloud is disabled entirely. (Read more in this knowledge base article.)

In Isadora 3 (pre-release versions of which will appear in the first quarter of 2018) we will address this by moving the drawing of the User Interface into a separate thread, something that we couldn't do for v2.6 for technical reasons. (Though, if text drawing remains slow because of whatever Apple did in High Sierra, it won't solve the problem entirely – it may not effect the playback engine, but it will still take noticeable time for the UI to be drawn when you scroll if you have a lot of actors.)

Certainly, @bonemap, with your many 3D Particle actors which have more inputs/outputs than most actors, you may experience this behavior more noticeably than others. One thing that might help in the short term is to double-click the "eye" icon and hide unused inputs on your 3D Particles actors. If the inputs/outputs aren't visible, they don't need to be drawn.

In any case, while there may be some limitations now, I believe you will be able to achieve your dream with Isadora 3. You're a great resource in the ways in which you stress the program, and we'll be listening to your feedback as we head towards the next version.

Best Wishes,
Mark

DusX

@bonemap

I, like you have patches with large amounts of text being drawn (mine often from streaming JSON data sets).
As Mark, mentioned, embedding sections of your patch into user actors makes a HUGE difference.
I generally like to top level of my patches to have just a few user actors, with minimal connections between them for this reason.
The other often forgotten feature that will help is the 'collapse actor' feature. If you collapse the actors that have many inputs/outputs you will see a dramatic improvement.

Woland

@mark said:

@woland said:
Strange idea, but would ditching the Pulse Generator and hooking up a Wave Generator actor (for a constant flow of data/triggers) to a Multiblocker actor (set so that it allows triggers through at the desired rate) make any difference, or would it still have the same issue?
Nice idea Lucas, but it unfortunately won't offer any improvement over the Pulse Generator. As I said, you can't get blood from a turnip: if your whole patch is running at 15 cycles per second, you can get anything inside it to go any faster than that.
Best Wishes,
Mark

But if there are many, many Pulse Generators, would replacing them all with a singular Wave Generator reduce the load on the system in any significant way?

bonemap

@woland said:

many, many Pulse Generators

Hi Lucas,

It could be that Mark is responding to the 3D Particles patch that I forwarded in another thread. In that patch I use just the one Pulse Generator, but have it specified for multiple sequential outputs each going to a different instance of the 3D Particles module.

Best wishes

Bonemap

mark

@woland said:

But if there are many, many Pulse Generators, would replacing them all with a singular Wave Generator reduce the load on the system in any significant way?

Sorry, I'm afraid not. The Pulse Generator itself is extremely lightweight You could have hundreds of those in a patch with no significant overhead. It is the heaviness of the rest of the patch that is executing (or, in the case of a cross fade, the two patches that are executiing) that is the problem.

Best Wishes,
Mark

Woland

@mark

I assumed the rest of @bonemap 's Patch would be complex, I just didn't know how much Pulse Generators contributed to the strain. Now I know, so thanks!