Hey! I don't hear any degrading..? best

now i got them.. but its the recording mechanism, not the playback, isn't it? its recording and not recording(ie resampling) with a high frequency but not high enough to be inaudible,, sample rate reduction..isn't it?

Yes it's the recording mechanism.

Who knows how to do it right?

i'm not sure if i actually understand what you are trying to achieve, but i guess you should define a "recording length"if you know what i mean. So in case the signal triggers the recording process, it shouldn't stop recording until a specified time. I just had a brief look at your patch, but i guess that should be the problem. Good luck Cheers

edit: or you could do envelope following.. lowpass filtering, if you want it to stop automatically

The problem is the degradation in playback, I've stripped out all the other parts of the patch so now gen~ is just recording a sine wave and groove is playing it back. You can see and hear the distortion.

Can someone explain what's going on - do i need some kind of interpolation?

Cheers,

John.

alright

woyteg - I'm not sure what you are showing me in that patch - but thanks for trying.

I've just worked out what is wrong - the sample increment using '%' was causing all the problems, switching it to a 'wrap' makes it work perfectly. I'm not really sure why because I checked the output of '%'.

I wish there were some simple gen~ tutorials, have i just missed them?

working:

hey leavecutter.. what i wanted to show you is, at least on my machine, the buffer was filled with the sample i was hearing. A short burst of about 8000 hz.

hello, below my version of original problem. Did you find more a concise way? I'm also GEN beginner, so thanks for opportunity for learning!

Nice one Andrze,

I like what you did with the top sah! I got rid of the other gates and made the zero crossing detector simpler. Poke is made to stop recording by driving it's index out of range of the buffer.

John.

smart zerocrossing detector! But I think 'out of range' also means negative values (no need for all those zeros ;))

Hi there,

The strange behavior with % appears to be due to some kind of floating point error, as far as I can tell, in how the % operator is implemented. Although it doesn't show up in the number~ box, there's an extremely small fractional offset of the value which is sometimes pushing the sample writing position forward by 1 sample, causing the distortion. The [wrap] operator on the other hand is implemented in a more complex set of instructions which take more care to ensure valid results.

The implementation of % has been flagged for further investigation (ticket #3624). In particular, in this case it should be possible to deduce that it can operate on integers only, which would avoid the problem entirely.

Best,

Graham

I got curious about something that only records the significant portions, and does not record the quiet parts; so the recording position doesn't update if the input level is too low. here's a first shot:

Without clicks:

graham, that is a beautifully simple and fantastic patch. thanks. now to try modify it for smooth starts/stops of recording, and perhaps writing the 'rejected' below-threshold parts of the recording to a different buffer...

by the way, is gen~accepting-message-rate-inputs new to 6.0.7? i am sure this did not work before (had to be param or signal inputs).

Ah well done Andrzej, I thought there might be a way of getting rid of all the zeros!

Graham, Thanks for looking into % - I was checking it with number~ and capture~ and just seeing ints so I was getting a little bit confused. Like the patch - here is a version built in plain MSP partly because I wanted to hear the difference between Gen and Msp and also compare the cpu load.

This version records high and low amps separately and plays them back together. Quite a lot of fun!

Yes, number (float and int) inputs to gen~ are one of the new features in 6.0.7. No need to use [sig~] anymore.

The recording should be smooth (ish) already, I hope... at least in the second one I posted. The rejected audio could be grabbed just by scaling the input by the output of the [clip] -> [!- 1], and using that to drive another writer I guess. That one will have clicks though...