Hello everybody! I'm new to PD and I'm italian (so sorry for my bad english), I'm trying to make a patch where a person voice triggers an opposite sample. For example: if I scream loud I will trigger a really calm soundtrack, otherwise if I say something really quietly the music will have more rhythm. I know it's really basic, but I searched on the forum and couldn't find a solution, or maybe I couldn't understand it.
For now, I've managed to make Pure Data respond to my trigger, but I want it to analyse the amplitude (?) or the loudness(it's right?) so it could choose which sample should play. For what I read here, the best way to do it is with env~, but I don't really know how to use it. Could someone help?

micprova.zip

@greglitch Try this.....
micp2.zip
It is also an introduction to abstractions. If you don't understand I will make it again in the simple way......
The next problem is......... do you want one to stop when the other starts?
David.

@whale-av
Thanks David! It worked! It's fantastic, now I could put a module for every volume!
There's just an issue, when the 0.8 module plays, the 0.3 module starts too... there's some kind of condition I should put? Like: if 0.8 is playing, don't play the 0.3 or "always play the highest"?

By the way, regarding the problem you were talking about, I don't really mind, because I'll put very short audio files, like 10 seconds, so it doesn't really matter to me.
micprova2.zip

Again, thank you very much, I'm starting to understand more of PureData.

@greglitch Yes..... I thought this would be your next problem! I will think about it and post a reply here.....

When I have a solution....
David.

@whale-av
Well, you've been really helpful so far, so thank you very much whether you have a solution or not.
Thank you again, now i'll start looking something up in the forum!

@greglitch Here.......... micp3.zip
A louder or softer one will stop the others (all others) and the same level again should just let it run to the end.......
Of course if you are using a microphone anywhere near the speakers that will complicate it a bit!...... but the patch should be correct. I tested it with the speakers off.
David.

Thank you @whale-av, sorry I'm replying now, but I hade very unpleasant shifts at work.
By the way, it works, I just need to read it calmly to understand it. Thank you, you've been really helpful.

@whale-av Hey, I'm sorry to bother you again, I have just one question, how is it exactly possible that a more intense sound doesn't trigger the softer one? is it because a louder or softer one will stop the others? Also, is it possibile to do a similar thing without abstraction and using for example ~env object? I tried but I only manage to play two samples with the random object

@greglitch Yes, you are correct, when a module is triggered it sends it's trigger value to [s me_bigger_or_smaller]. The other abstractions see the value arrive, and if they are not the one that sent the value (it is not equal to their value) they send the [stop( message to their [readsf~]. The module that sent the message sees the same value arrive, and does not stop. So a bigger trigger, or a smaller trigger will stop all of the others. Because there is a "de-bounce" in [threshold~] this can only happen after the de-bounce time has elaplsed. Because you are playing the tracks in the same space as the microphone it is likely that a smaller value will not be sent while a track is playing..... and so it is always a "louder" track that is triggered (even though your selected "louder" tracks are in fact "quieter") until that track ends naturally........ confused?

Here is the same thing again with [env~]......... micprova4.zip
As you still need the debounce of [threshold~] I have built you a replacement called [threshold_env~] which does the same thing using [env~]....... nearly.....

1. [threshold~] was peak to peak, and [env~] outputs rms.
2. The "set" message can no longer be sent to the audio inlet, so there is an extra inlet in the middle that will receive the message.

If you want to use [env~] outside of an abstraction you would need to copy and paste the contents of [threshold_env~] (probably without the "rest" part) many times across your patch, with different trigger values and attach them to many [readsf~] objects. It would become really hard.....very quickly.... to see what is going on......that is the advantage of abstractions......especially as if you need to change something for every abstraction you only need to do it once.
See......http://forum.pdpatchrepo.info/topic/9774/pure-data-noob...... the first screenshot gives you an idea about what you would end up with on your screen without using abstractions! You can very quickly run out of screen space.

The fact that I was able to just "drop in" [threshold_env~] in place of [threshold~] should convince you of the advantage of abstractions. Without them I would have had to copy it numerous times, and if it didn't work correct it many times, and then reconnect everything up... with many opportunities to make a mistake. You can now copy [module_play_env~ xxx nn] as many times as you wish........
David.