Need a seconds counter, but it is slow..

[Davide D'Angelo]

Hi, I needed a way to count the passing time, and in Processing I used the millis() function..

Here, I don't remember where, I've read Neil suggested to use an audio:clock to have realtime precision. (tell me if I just dreamed..)

I've setup an Audio:Clock with 60bpm and 10 subdivision, to have tenths of seconds, than the output goes inside a Core:Routing:Send directed to a video custom component to display the timer text, using a Trigger like this:

@T(0) void timerTrigger() {

        playTimeDSeconds++;

    }

and the String output is made with this function:

private String dSecondsToString(double dsecs) {

        int secs = (int)(dsecs/10)%60;

        int mins = (secs/60)%60;

        int ores = (mins/60)%60;

        String tempo = String.format("%02d" , ores)+":"+String.format("%02d" , mins)+":"+String.format("%02d" , secs);

        return tempo;

    }

The problem is that after every minute the counter is loosing a second gradually. it means after 30 seconds, it is loosing half a second etc...

What am I missing?

I thougth it was because I draw too much plus the 2 camera streaming, but I tryied to reduce to the bare minimum described above, and the error is the same.

Attached a minimal project to replicate.

[Neil C Smith]

Hi,

On Sat, 30 Mar 2019, 18:22 Davide D'Angelo, <77d...@gmail.com> wrote:

Hi, I needed a way to count the passing time, and in Processing I used the millis() function..

Here, I don't remember where, I've read Neil suggested to use an audio:clock to have realtime precision. (tell me if I just dreamed..)

Short answer - use millis(). This actually runs off the high performance clock in PraxisLIVE anyway.

The audio:clock runs off the sample card clock quantized to the buffer size. It's useful for getting regular timing of events in an audio patch, not really for anything else. It displays the actual bpm it's running to. Whether that's actually 60bpm depends on your sample rate. If 48khz it should be fairly accurate though?!

Best wishes, 

Neil

[Davide D'Angelo]

Hi, The project I've done is working well, except for some glitch in the live smpte reading (I'm going to investigate on this further) and CPU and GPU temperatures that go really too high.

I mean after 3 minutes CPU temp goes over 85° Celsius and GPU over 80°. is it normal when using Praxis? (tried both Live and Core).

my CPU is  a i7-4710HQ CPU @ 2.50GHz with 4 * 2 threads cores.

my GPU is a Nvidia GTX-850M

Attached a screenshot of what I've done till now.. in the pic smpte is turned off because buggy..

Wish you like it.

Thank you again, Davide.

[Neil C Smith]

On Thu, 4 Apr 2019 at 12:57, Davide D'Angelo <77d...@gmail.com> wrote:
> I mean after 3 minutes CPU temp goes over 85° Celsius and GPU over 80°. is it normal when using Praxis? (tried both Live and Core).

The most likely culprit is the video sources. You're using
video:capture right? Try starting / stopping, and specifying
source-width, source-height, source-fps, and see what effect this has
on the CPU and GPU usage.

At the moment, we don't have OpenGL context sharing between GStreamer
and Processing which makes this more inefficient. This is something
in discussion between the various projects so will hopefully be an
option soon.

Best wishes,

Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net

PraxisLIVE - hybrid visual live programming
for creatives, for programmers, for students, for tinkerers
www.praxislive.org

[Davide D'Angelo]

Il giorno giovedì 4 aprile 2019 15:21:48 UTC+2, Neil C Smith ha scritto:

On Thu, 4 Apr 2019 at 12:57, Davide D'Angelo <77d...@gmail.com> wrote:
> I mean after 3 minutes CPU temp goes over 85° Celsius and GPU over 80°. is it normal when using Praxis? (tried both Live and Core).

The most likely culprit is the video sources.  You're using
video:capture right?  Try starting / stopping, and specifying
source-width, source-height, source-fps, and see what effect this has
on the CPU and GPU usage.

Ok, will try with different settings.. now they are two streamings, both at 1080p and the project is set at 60fps.

 

At the moment, we don't have OpenGL context sharing between GStreamer
and Processing which makes this more inefficient.  This is something
in discussion between the various projects so will hopefully be an
option soon.

Best wishes,

Neil

regarding this, can you explain why there are 5 OpenGL renderers and which should one choose?

Thanks, Davide.

[Neil C Smith]

On Thu, 4 Apr 2019 at 14:28, Davide D'Angelo <77d...@gmail.com> wrote:
> regarding this, can you explain why there are 5 OpenGL renderers and which should one choose?

Generally just OpenGL. Processing offers 4 different settings for the
requested OpenGL profile - these are just a way of exposing them if
you need to set a specific requirement.

Mind you, try with GL3 (or GL4) and let me know if they improve the
performance. The default setting *may* be missing out an optimization
that would help with video playback.

[Neil C Smith]

PS. Also see https://github.com/processing/processing/wiki/Advanced-OpenGL
and the description of PJOGL.profile which is what this is actually
setting.

[Neil C Smith]

Hi,

For your information I've just published v4.2.0. This includes
changes to the GStreamer components, but also updates Processing and
various other libraries. Will be properly announced tomorrow.

https://github.com/praxis-live/praxis-live/releases/tag/v4.2.0

Best wishes,

Neil

[Davide D'Angelo]

The most likely culprit is the video sources.  You're using 
video:capture right?  Try starting / stopping, and specifying 
source-width, source-height, source-fps, and see what effect this has 
on the CPU and GPU usage.

I had time to try, and simply if I don't connect any camera, CPU and GPU temperature stay within 54° C.

As soon as I put my hands on the cameras again, I'll try different resolutions / fps..

Thanks.

[Davide D'Angelo]

Just wanted to confirm that with the camera set to send video at 780p instead of 1080p, and with praxis fps set to 30, CPU temp stay below 67°C.

Thank you very much.