Dear list,
how is it possible that measuring a metro 1000 with realtime object i get 333.3 as a result? I am testing it on an Ubuntu 18.04 and time just goes 3 times faster than it should. On a Mac OS the result for the same test is expectedly 1000ms. Please advice!
Popesz
Hey
On Sun, 2018-09-30 at 20:55 +0200, Csaba Láng wrote:
how is it possible that measuring a metro 1000 with realtime object i get 333.3 as a result?
I get same when running pd with -r 14700 while my soundcard is configured to run at 44100Hz. Interestingly, this mismatch only has an effect while DSP is on. When turning DSP off, [realtime] measures 1000ms.
I am testing it on an Ubuntu 18.04 and time just goes 3 times faster than it should.
It's most likely not related to the OS. What soundcard are you using?
On a Mac OS the result for the same test is expectedly 1000ms. Please advice!
On your Mac, there is apparently no mismatch between what SR Pd thinks it gets from the soundcard and the actual soundcard setting.
Roman
mabye you could set dsp on (and off again if needed) this will synchronize pd in a more reasonable way … and keep an eye permanently on this aspect if time measurement is critical for ur patch (high load might blow pd out, means 1 second is lasting three seconds or so, in this latter case there is little to do besides optimizing the patch) JM
Le 30 sept. 2018 à 20:55, Csaba Láng langcsaba@gmail.com a écrit :
Dear list,
how is it possible that measuring a metro 1000 with realtime object i get 333.3 as a result? I am testing it on an Ubuntu 18.04 and time just goes 3 times faster than it should. On a Mac OS the result for the same test is expectedly 1000ms. Please advice!
Popesz _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Thanks for the hints, probably the best idea is to turn off dsp every time it is not needed. However playing a video and audio with metro control (sending the bangs according to the frame rate) and using cameras in the same time makes pd totally loose sense of time. Very disappointing, as I trusted more in metro than in God. Popesz
On Sun, Sep 30, 2018 at 9:23 PM Jean-Marie Adrien jm.adrien.mnt@gmail.com wrote:
mabye you could set dsp on (and off again if needed) this will synchronize pd in a more reasonable way … and keep an eye permanently on this aspect if time measurement is critical for ur patch (high load might blow pd out, means 1 second is lasting three seconds or so, in this latter case there is little to do besides optimizing the patch) JM
Le 30 sept. 2018 à 20:55, Csaba Láng langcsaba@gmail.com a écrit :
Dear list,
how is it possible that measuring a metro 1000 with realtime object i
get 333.3 as a result?
I am testing it on an Ubuntu 18.04 and time just goes 3 times faster
than it should.
On a Mac OS the result for the same test is expectedly 1000ms. Please advice!
Popesz _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
" I trusted more in metro than in God" Wins today's star prize...
On Mon, 1 Oct 2018 at 11:26, Csaba Láng langcsaba@gmail.com wrote:
Thanks for the hints, probably the best idea is to turn off dsp every time it is not needed. However playing a video and audio with metro control (sending the bangs according to the frame rate) and using cameras in the same time makes pd totally loose sense of time. Very disappointing, as I trusted more in metro than in God. Popesz
On Sun, Sep 30, 2018 at 9:23 PM Jean-Marie Adrien jm.adrien.mnt@gmail.com wrote:
mabye you could set dsp on (and off again if needed) this will synchronize pd in a more reasonable way … and keep an eye permanently on this aspect if time measurement is critical for ur patch (high load might blow pd out, means 1 second is lasting three seconds or so, in this latter case there is little to do besides optimizing the patch) JM
Le 30 sept. 2018 à 20:55, Csaba Láng langcsaba@gmail.com a écrit :
Dear list,
how is it possible that measuring a metro 1000 with realtime object i
get 333.3 as a result?
I am testing it on an Ubuntu 18.04 and time just goes 3 times faster
than it should.
On a Mac OS the result for the same test is expectedly 1000ms. Please advice!
Popesz _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mon, 2018-10-01 at 12:15 +0200, Csaba Láng wrote:
Thanks for the hints, probably the best idea is to turn off dsp every time it is not needed. However playing a video and audio with metro control (sending the bangs according to the frame rate) and using cameras in the same time makes pd totally loose sense of time. Very disappointing, as I trusted more in metro than in God. Popesz
Pd is designed to be deterministic. There is no notion of skipping some task in order to keep synchronicity with real time, unlike many media players that are able to skip frames in order to playback a movie file with no interruption.
It has been discussed many times on this list about how to deal with audio and video in Pd. Probably the best way is to run the audio and video part in two separate instances of Pd, whereas the audio instance does all the time-critical stuff and the video part is controlled by the audio part through some communication channel (network socket, unix socket, [pd~], etc.).
Roman
On Sun, Sep 30, 2018 at 9:23 PM Jean-Marie Adrien < jm.adrien.mnt@gmail.com> wrote:
mabye you could set dsp on (and off again if needed) this will synchronize pd in a more reasonable way … and keep an eye permanently on this aspect if time measurement is critical for ur patch (high load might blow pd out, means 1 second is lasting three seconds or so, in this latter case there is little to do besides optimizing the patch) JM
Le 30 sept. 2018 à 20:55, Csaba Láng langcsaba@gmail.com a
écrit :
Dear list,
how is it possible that measuring a metro 1000 with realtime
object i get 333.3 as a result?
I am testing it on an Ubuntu 18.04 and time just goes 3 times
faster than it should.
On a Mac OS the result for the same test is expectedly 1000ms. Please advice!
Popesz _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
You could try if (far less powerfull than Gem) Pof externals could suit your needs, cause the GPU thread is decoupled from the audio thread. Not sure that the available deken version will work on 18.04 though...
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
Le lun. 1 oct. 2018 à 12:54, Roman Haefeli reduzent@gmail.com a écrit :
On Mon, 2018-10-01 at 12:15 +0200, Csaba Láng wrote:
Thanks for the hints, probably the best idea is to turn off dsp every time it is not needed. However playing a video and audio with metro control (sending the bangs according to the frame rate) and using cameras in the same time makes pd totally loose sense of time. Very disappointing, as I trusted more in metro than in God. Popesz
Pd is designed to be deterministic. There is no notion of skipping some task in order to keep synchronicity with real time, unlike many media players that are able to skip frames in order to playback a movie file with no interruption.
It has been discussed many times on this list about how to deal with audio and video in Pd. Probably the best way is to run the audio and video part in two separate instances of Pd, whereas the audio instance does all the time-critical stuff and the video part is controlled by the audio part through some communication channel (network socket, unix socket, [pd~], etc.).
Roman
On Sun, Sep 30, 2018 at 9:23 PM Jean-Marie Adrien < jm.adrien.mnt@gmail.com> wrote:
mabye you could set dsp on (and off again if needed) this will synchronize pd in a more reasonable way … and keep an eye permanently on this aspect if time measurement is critical for ur patch (high load might blow pd out, means 1 second is lasting three seconds or so, in this latter case there is little to do besides optimizing the patch) JM
Le 30 sept. 2018 à 20:55, Csaba Láng langcsaba@gmail.com a
écrit :
Dear list,
how is it possible that measuring a metro 1000 with realtime
object i get 333.3 as a result?
I am testing it on an Ubuntu 18.04 and time just goes 3 times
faster than it should.
On a Mac OS the result for the same test is expectedly 1000ms. Please advice!
Popesz _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 01.10.2018 12:54, Roman Haefeli wrote:
It has been discussed many times on this list about how to deal with audio and video in Pd. Probably the best way is to run the audio and video part in two separate instances of Pd, whereas the audio instance does all the time-critical stuff and the video part is controlled by the audio part through some communication channel (network socket, unix socket, [pd~], etc.).
Once upon a time I made a repository to demonstrate the different techniques an I will soon revisit and update it. https://github.com/mxa/AudioVideoPatches
Wow,
nice work, thanks for sharing. Will go through of it one by one and will comment with my experiences. Best, Popesz
On Mon, Oct 1, 2018 at 2:52 PM Max abonnements@revolwear.com wrote:
On 01.10.2018 12:54, Roman Haefeli wrote:
It has been discussed many times on this list about how to deal with audio and video in Pd. Probably the best way is to run the audio and video part in two separate instances of Pd, whereas the audio instance does all the time-critical stuff and the video part is controlled by the audio part through some communication channel (network socket, unix socket, [pd~], etc.).
Once upon a time I made a repository to demonstrate the different techniques an I will soon revisit and update it. https://github.com/mxa/AudioVideoPatches
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Antoine Rousseau -
Csaba Láng -
Jean-Marie Adrien -
Julian Brooks -
Max -
Roman Haefeli