Asunto: Re: [PD] problem with mixer project De: IOhannes m zmölnig zmoelnig@iem.at Fecha: Sat, 07 May 2011 11:33:03 +0200 Para: pd-list@iem.at
Para: pd-list@iem.at
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/06/2011 08:45 PM, Fernando Gadea wrote:
Hi list! If I move any slider in my controller to raise the volume of any channel, it works perfectly well, but if I move the master level the latency starts to get crazy and the resulting values come really slowly,
Pd is designed to have a constant latency.
so Pd's (and the system's) latency will never when moving a slider (well, unless you control a delay with the slider or do some other explicit latency fuddling, but that's a different story)
or maybe you are referring to GUI latency? e.g the slider starts to visually respond very slowly (it seems like in CM-talk, "latency" mostly refers to audio latency). without having looked at your patch, a good chance is that you have created some control feedback.
Reading my mail I realized that I did not explain it all: the latency problem starts when the dac~ is computing audio. As you can see in the mixer, when I rise the master volume audio computation starts, meanwhile if I set master volume to zero it ends. It is while computing audio that the latency problem exists, so I guess the control side is not the problem (am I in the right logic?) Nevertheless I have done what I believe is an extensive control check in my patch, before and after finding that deleting the mixer channels the problem ended. After that I did another control check on the mixer part of the patch and found no control feedback (my checks are visual, following line after line, so, as human, I might be wrong, but I cannot find my error if I did one). It seems that the latency is present not only in GUI. I send the values to a symbol in the main patch to see what I am doing, so I am preety sure I also hear the audio consecuences with the same latency (the audio rises just when the mixer volume rises, about a second after moving the slider if dac~ is on). Anyway, I will look for some other posibilities of control feedback. Thank you for your advice
fgmasdrt IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3FEc8ACgkQkX2Xpv6ydvR1fQCdEGsRD4QqEaMLxhJpEr3MblTO kpcAoPTP2Rf14/nCN+GI3IOhBTP9B4xV =Oh4I -----END PGP SIGNATURE-----
Pd-list mailing list Pd-list@iem.at to manage your subscription (including un-subscription) see http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/07/2011 12:58 PM, Fernando Gadea wrote:
Reading my mail I realized that I did not explain it all: the latency problem starts when the dac~ is computing audio. As you can see in the
i still have no clue what you mean by "latency". please clarify.
fgasmdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/07/2011 04:13 PM, IOhannes m zmölnig wrote:
i still have no clue what you mean by "latency". please clarify.
you probably should have a closer look at [delay] and what it does if you send it a number.
ah, btw, you could simplify the following
<complex> [expr $f1; if ($f1 == 0, 0, 1] | +----------------------------+ | [change] | [select 1 0] | [;pd dsp 0( [;pd dsp 1( </complex>
to this
<simple> [!= 0] (actually this should be [> 0] | [change] | [;pd dsp $1( </simple>
gdsft IOhannes
-
Fernando Gadea -
IOhannes m zmölnig