[PD] Strange bug with cup and moses

[IOhannes m zmoelnig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2012-10-09 10:03, Rick T wrote:
> I added the trigger like you suggested to see if it would help, but
> the strange behaviour still occurs, granted it is most likely that
> I wired something incorrectly.  They say a picture is worth a
> thousand words so by making a 720p video with annotations I thought
> it would better show/describe the problem.

definitely not.


anyhow, i didn't look at your probloem, so suggesting that it was a
[trigger] problem was merely a random guess (though one that happens
to fix the problem in most cases, esp. for beginners)

so let's look at your real problem:

> 
> I use moses .98 (Bangs when it reaches a section/point greater than
> .98 of a wave file)

i'm most grateful for your comment. it tells more than a thousand 720p
videos.

you are misunderstanding the [moses] object.
[moses] devides a stream of numbers based on a threshold. whenever a
number comes in that is <0.98, it will send that very number to the
left outlet, if its bigger it will send that very number to the right
outlet.
[moses] will never ever send out a [bang(!


> |

let's assume that you connected the 2nd outlet of [moses] to the
following object, since this is more what you want.



> cup (increments by one)

i don't know what [cup] does (i guess it's a short for "count up", so
i assume it is a counter).
esp. i don't know what [cup] does if it receives a number, rather than
a bang (remember, if [moses] gets e.g. "4", it will pass this number
"4" through it's second outlet to [cup])

i guess that most simple counter implementations will - when you send
them a number - set their internal value to that number (and probably
increment it).

so if your original number was 42, [moses] will pass it to [cup] and
[cup] will then output 42 (or 43 if it increments that value),
regardless or whether this is the first time you sent the number or not.

this is not what you want!
(you want to make [cup] output "1", the first time a value >0.98 (e.g.
42) is sent)


btw, you really should think about building the counter yourself.
building a coutner takes about 3 Pd-objects, and we wouldn't have to
worry about what [cup] does exactly, because we would know.


> | moses 5      (when it reaches 5)


again, [moses] will not do what you want.

for one thing, even if your counting works, it will output a message
(the current number) to its right outlet every time, once the
threshold is reached.

> |
 again, let's assume that you connected the 2nd outlet of [moses]

> pd dsp 0 (    (turns off patch when moses reaches 5)

this finally does "what you want": turning off audio-processing globally.
since [moses] will output a message for each iteration once the
threshold is reached, you will keep turning off the DSP, which might
not be exactly what you want, as it might interfere with other patches
running at the same time.
it might be a better idea to mute the output of your looper, or use
[switch~] to switch it off locally.



> 
> What happens is 1) moses and cup don't always start incrementing
> and filtering when the patch is enabled. 2) When the moses and cup
> section do work, after the "pd dsp 0" command is triggered after
> moses reaches 5 the wave file /sound stops but cup still 
> increments.
> 

well, #2 is not very suprising, as you never told the counter to stop?
sending [; pd dsp 0( will suspend all audio-processing, but messages
still continue to work.

it seems that the biggest problem you have is the wrong use of [moses].
what you really want to do (and which is what you already describe in
your comments) is compare a number with a threshold and output a
"bang" if it is bigger.
comparing 2 numbers can be done with [>], it will output '1', if the
1st number is bigger than the 2nd or '0' otherwise.
checking whether a number has a certain value, can be done with
[select]: it will output a [bang( on the outlet that matches your number.
if you don't care about duplicates, you might want to filter them out
using [change].

so your patch boils down to:

[f]
|
[> 0.98]   (outputs 1 if input is bigger than 0.98)
|
[select 1] (outputs a bang if above condition is met)
|
| +---------+
[i]         |
|           |
[t f f]     |
|     |     |
|     [+ 1] |  (counts up every time it gets a bang)
|     |     |
|     +-----+
|
[>= 5]         (compare counter with threshold)
|
[change]       (filter out duplicate values, to avoid multiple triggers
|               once 5 is reached)
|
[select 1]     (output bang once 5 is reached)
|
[; pd dsp 0(   (turn off audio processing)


if you want to stop counting after that, use [spigot] before the 1st
comparision to filter any incoming messages.




> * i also attached the pd file*

great.

fgmasdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlBz5y0ACgkQkX2Xpv6ydvR0jwCdEE7e+sYBV0h+eFIwEaoPVEin
MYsAoLFiEj15k9O1gTzTlzQhCJJa9EFc
=P56K
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2320 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20121009/a9dd3f50/attachment.bin>