Ptolemy

I'm having a bit of a problem getting a smooth read out on the snapshot~ and number~ objects. They work fine in small patches but as soon as I start using multiple instances of a patch I've been workiong on in the same patch the read out gets really slow and jittery. I'm guessing it's due to the size of the bpatchers as I'm using many many bpatchers inside a single bpatcher.

Setting the update interval to a higher number seems to help the issue somewhat, but then it is perhaps not as acurate as I would like. The number~ object in the right envelope follower has an update interval of 70 ms where the one on the left is set at 20 ms. The one on the right is definitely smoother on my machine. Deleting the bpatcher below the envelope followers and LFO makes them work like normal again, which is strage as my DSP was never close to 100% nor were any of the patches connected.

Has anyone come across this problem before and or know of a workaround? What am I doing wrong as I really need a smooth readout for this?

The file size is too big for the forum so I have had to upload it to send space. I hope this is ok.

snapshot-and-number-not-working-properly

I have kind of the same problem i think. Works fine in simple patches but both snapshot~ and number~ are not accurate and even totally stop working when i use them in (multiple) bpatchers.

I have kind of the same problem i think. Works fine in simple patches but both snapshot~ and number~ are not accurate and even totally stop working when i use them in (multiple) bpatchers.
No solution yet.


about how many instances are we talking, hundreds?

then try this: use different starting point for the objects or even different interval settings (such as 40, 41, 42, 43, and 44 ms)

this should release some pressure from the scheduler.

Also, limit the readings to what's necessary in your application. If it's for display, no need to display faster than what the eyes will see. Most application might even tolerate a slow update rate (100 ms?)

Also, you mention your DSP not at 100%: keep in mind that the DSP status shows only the percentage of CPU used by audio DSP (MSP objects). That means that lots of things are not counted in this percentage (Max, scheduler, Jitter...)

Also, limit the readings to what's necessary in your application. If it's for display, no need to display faster than what the eyes will see. Most application might even tolerate a slow update rate (100 ms?)
Also, you mention your DSP not at 100%: keep in mind that the DSP status shows only the percentage of CPU used by audio DSP (MSP objects). That means that lots of things are not counted in this percentage (Max, scheduler, Jitter...)


I had (have) a similar problem with a single snapshot object (triggered by the render bangs) which would sometime just stop outputting numbers.

I have an installation that rely on this single snapshot and the only workaround I found was to create an msp object (any) and it would start working again (so I added a small script that create a number~ box and then delete it: not ideal...)

I can't reproduce that consistently in a simple patch

I had (have) a similar problem with a single snapshot object (triggered by the render bangs) which would sometime just stop outputting numbers.
I have an installation that rely on this single snapshot and the only workaround I found was to create an msp object (any) and it would start working again (so I added a small script that create a number~ box and then delete it: not ideal...)

I can't reproduce that consistently in a simple patch


I looked for this thread because I had the problem, that I had to manually delete and retrieve certain [snapshot~] objects in subpatches and abstractions—which is a no-go of course—for them to process signals again, changing its attributes didn't do anything either. In my case, it all boiled down to a [mute~] object connected to the abstraction which of course turned off DSP for the subpatch. Just incase this is true for someone else in here, go check on those objects…

Snapshot~ and Number~ not working properly