Kjel Sidloski

Hi first time poster. So I'm just starting to design a patch that will listen to an input live and when it hears a large enough signal it will record it into a buffer and then move onto the next buffer. Essentially I will be able to record a series of percussive sounds in a live setting and load them into a sample bank to then be used in a beat maker thing I've already made. That's the context. Right now I'm just working on the part that captures the sound. For the record I've done stuff like this using meter~ and a gate, but I'm trying to learn more about the signal domain and keep it out of the scheduler as much as I can. What I have been trying so far (unsuccessfully) is to use sah~ to act as a gatekeeper with the argument being the threshold of signal required to start recording. Once it goes above that number signal should be passed to delta which should give a zero when sah~ is below threshold and holding steady and non-zero when it is above threshold and passing values. Then edge~ is used to check for that non-zero so that it can start recording into the buffer as soon as the threshold is passed. <~0 is probably redundant but I got it from the click~ helpfile and I figured it wouldn't hurt. The problem is that for whatever reason. No matter what threshold I give, edge~ just bangs repeatedly when the threshold gets passed. I'm not exactly sure why. I'll post what I'm looking at here. Any tips are appreciated. Also if you have a different method entirely (preferably in signal domain/sample accurate stuff as I'm trying to learn more about it) that's totally cool too. This was just my first idea. Thanks!

message

button

ezdac~

live.gain~

play~

count~

edge~

poke~

number~

meter~

delta~

buffer~

ezadc~

sah~

Hi first time poster. So I'm just starting to design a patch that will listen to an input live and when it hears a large enough signal it will record it into a buffer and then move onto the next buffer. Essentially I will be able to record a series of percussive sounds in a live setting and load them into a sample bank to then be used in a beat maker thing I've already made. That's the context. Right now I'm just working on the part that captures the sound. For the record I've done stuff like this using meter~ and a gate, but I'm trying to learn more about the signal domain and keep it out of the scheduler as much as I can.  What I have been trying so far (unsuccessfully) is to use sah~ to act as a gatekeeper with the argument being the threshold of signal required to start recording.  Once it goes above that number signal should be passed to delta which should give a zero when sah~ is below threshold and holding steady and non-zero when it is above threshold and passing values. Then edge~ is used to check for that non-zero so that it can start recording into the buffer as soon as the threshold is passed. <~0 is probably redundant but I got it from the click~ helpfile and I figured it wouldn't hurt. The problem is that for whatever reason. No matter what threshold I give, edge~ just bangs repeatedly when the threshold gets passed. I'm not exactly sure why. I'll post what I'm looking at here. Any tips are appreciated. Also if you have a different method entirely (preferably in signal domain/sample accurate stuff as I'm trying to learn more about it) that's totally cool too. This was just my first idea. Thanks! 

Hi first time poster. So I'm just starting to design a patch that will listen to an input live and when it hears a large enough signal it wi

sample-grabber-in-signal-domain

try recopying your patch using "copy Compressed" rather than just "copy", otherwise no one will want to look at your patch. From your description it's probably that you need to low pass filter your signal first so you are analysing the overall envelope of the signal rather than the instantaneous amplitude of the signal (which varies thousands of times a second)

try recopying your patch using "copy Compressed" rather than just "copy", otherwise no one will want to look at your patch. From your description it's probably that you need to low pass filter your signal first so you are analysing the  overall envelope of the signal rather than the instantaneous amplitude of the signal (which varies thousands of times a second)

Thank you! So I tried lores~, onepole~, and svf~ with different cutoffs but I'm still getting a bunch of bangs from edge, even when the delta~ is just reading zero. That's one things that's been confusing me about signal. How can an object be affecting anything if I attach a number~ object to it and it says zero. Like in the click~ helpfile if I attach number~ to the <~0 or the click~ itself, it reads zero, but yet we're hearing sound. Is it just happening faster than the computer can render visually? Or is there some kind of mysterious other data being transmitted that can't be tracked with number~? I feel like that same thing might be happening in my patch. Here it is with the lowpass.

I tried using a rampsmoother~ and I also tried putting the lowpass and smoother before the sah~ but alas. It didn't work.

Reacting to peak to start recording means missing waveform beginning.

I would rather use stutter~ and copy the captured audio to external buffer.

delayed by waveform length minus attack time.

Depending on audio material, it could be done really simply.

To start, look as this - very simple detector using sah~,

Reacting to peak to start recording means missing waveform beginning.
I would rather use stutter~ and copy the captured audio to external buffer.
Using onset detection, trigger the copy function
delayed by waveform length minus attack time.
Depending on audio material, it could be done really simply.
To start, look as this - very simple detector using sah~,
because You seem to like that  object...


Hey so I searched the term onset detection and found some awesome resources that will work for me. Didn't know what to call it before. Thanks for your help!

Sample grabber in signal domain?