Mike S

Some more CPU related questions. This is for a piece of software that displays the playhead's location on a waveform~ object. Originally I was using 4 waveforms~ but I figured that was taking quite a lot of CPU with the line message. It runs at around 30% CPU on my machine, this wouldn't be a problem but there's a lot of other stuff going on!

So here's the patch, an example of how I'm displaying the playheads. I wonder if this could be done using less CPU? Could Jitter be applicable here? And are there any reasons not to use LCD for this?

Some more CPU related questions. This is for a piece of software that displays the playhead's location on a waveform~ object. Originally I was using 4 waveforms~ but I figured that was taking quite a lot of CPU with the line message. It runs at around 30% CPU on my machine, this wouldn't be a problem but there's a lot of other stuff going on! 

So here's the patch, an example of how I'm displaying the playheads. I wonder if this could be done using less CPU? Could Jitter be applicable here? And are there any reasons not to use LCD for this?


lcd-for-drawing-playheads

You could use a [multislider] or multiple instances thereof with the background set to transparent. I've found that very effective before.

You could reduce your CPU usage by raising the 

's time grain (the default is 20ms, i.e. 50Hz). You'll need to find the right balance between visual smoothness and CPU.

Did you try using 4 sprites (no clear message needed) ? It doesn't make a big difference on my Mac, but maybe on yours!

You could reduce your CPU usage by raising the line's time grain (the default is 20ms, i.e. 50Hz). You'll need to find the right balance between visual smoothness and CPU.

Hello all, thanks for the suggestions, I will try them soon and report back.

Roman - What IS wrong with [counter]? Have you spoke with him recently?

This is an example of the patch in action - 

http://www.youtube.com/watch?v=xsy716A23vU

Hello all, thanks for the suggestions, I will try them soon and report back. 

Roman - What IS wrong with [counter]? Have you spoke with him recently? 

This is an example of the patch in action - http://www.youtube.com/watch?v=xsy716A23vU


synchronizing the draw messages with a separate qmetro

synchronizing the draw messages with a separate qmetro
otherwise take the next step with jit.gl


I had no idea how expensive the rate of update on these objects could be.

mike´s dog: counter would at least not be high priority, like line is.

Roman's 90's graphics: it's not an option unfortunately, but thanks for taking the usual two posts to make yourself clear.

beeing as cryptic as possible is an artform itself.

and since raja has us back, i am even allowed to.

>> vanille béchamel : "- You can not get transparency with openGL window ..."

Of course you can do some transparency with openGL! And it can be nice and useful! : 

https://cycling74.com/forums/gl-render-fsaa-not-working-in-fullscreen-newbie-in-jit-gl-mesh-question

First of all, using Jit.lcd is ten times faster than using lcd (because lcd is antialiased while jit.lcd is not)

After, using openGL might be faster again...

Of course you can do some transparency with openGL! And it can be nice and useful! : https://cycling74.com/forums/gl-render-fsaa-not-working-in-fullscreen-newbie-in-jit-gl-mesh-question (second patch attached in the topic)

First of all, using Jit.lcd is ten times faster than using lcd (because lcd is antialiased while jit.lcd is not)
After, using openGL might be faster again...


On my MBP, drawing in lcd in max5 is ten times slower than in max4...

Most of the time it doesn't matter because you can use jit.lcd if you want instead, but no sprites in jit.lcd...

On my MBP, drawing in lcd in max5 is ten times slower than in max4...
Most of the time it doesn't matter because you can use jit.lcd if you want instead, but no sprites in jit.lcd...


LCD for drawing playheads