'Pulse Generator' irregularity of pulse triggers emitted?

Woland

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!