multiple amplitude-windowing of a buffer`
I've been puzzling over this for a bit this evening, can't seem to work it out. Basically, I record a loop, then replace segments of that loop with new audio wherever/whenever I want.
But, I want to be able to get rid of the little clicks that inevitably happen at the start/end of each replaced segment. I've got to a place where I thought it should work, but am having no luck.
The patch needs the CNMAT accumulate~ object, it is included in the zip file.
hmm....I actually just noticed a big problem with my method. If you replace a long segment, and then replace segments within the replaced segment (if that makes sense) there is no way to detect the (2nd layer) smaller segments.
Does anyone have any suggestions on how I could record a very short (lets say a vector-length) spike into the window buffer~ (ie a spike at the beginning of each new segment, and another at the end) instead of a block of signal? That way the above problem wouldn't exist. I want to stay away from click~ as it isn't controlled at audio rate.
Also.....there is occasional glitching when replacing, I've got no idea why it occurs, and why only sometimes.
Sorry for the lengthy post, I'm very grateful for suggestions.
Hi.
You might give a try to [xrecord~] by Thomas Grill (this is in fact the [xsample] object).
You can find here (with some other goodies):http://grrrr.org/ext/beta/
It works really nicely.
Cheers,
_y
I don't want to change the way I've set up that patch unless xsample~ is the only option. It is a little piece of a much bigger patch I pulled out to test on.
I think all I need to know now is how to record a signal spike into a buffer in response to a transition of 1 to 2 and 2 to 1.
Rather than recording a "block" signal from the start to the end of replacing, it needs to record a spike at the beginning and one at the end of each segment (ie a spike when the toggle is turned on and another when it is turned off - just like the display of the zerox~ scope).
I'm just not sure how to go about this without using click~. Of course, I could put a [t i b] directly after the replace toggle so it would trigger a click~ impulse and then start replacing, but I really want to keep it all signal controlled for accuracy.
A confusing thing is why putting a [+~ 1] after the output of zerox~ results in no output, rather than resulting in an impulse of 1 to 2 instead of 0 to 1. Because what I need is a signal of 1 with negative spikes at each replace point.
ugh
Am I a million miles off with this new amp-windowing attempt? It doesn't work yet, but as far as I understand, it is pretty much the right concept.
Also attached is a pic of the distortion/glitch that sometimes happens when using the replace function. It would be really helpful if someone can suggest where I am going wrong with this.
I'm just getting increasingly confused about how to make it work.
cheers
-tim
Hi Tim
Quite an interesting idea, and patch! I'm still getting to grips with it at the moment
Have you thought about just using cue points to read from different parts of the original buffer, or is that a bad idea?
I'm not 100% sure what you mean by using cue points instead, but the idea is that I use the patch to record a looped instrumental phrase, and then replace bits of the loop on the fly to make the loop evolve in an unusual way. I'm finding it much more interesting that just overdubbing, as live looping has a tendancy to become rather static. I'm trying to avoid that trap.
So, I need to actually be replacing sections of the previous buffer, which creates a kind of glitchy sound by nature, which is great. It's just the sharp clicks that I need to sort out (set the anticlick flonum to 0, the "reloop" click is the sound I mean). Of course, testing the patch with sine waves will mean I can never get rid of the clicks, but I know it is possible to soften them enough that they are unnoticeable when used with an instrument/voice. Getting rid of the clicks and that unpredictable distortion are vital to making this a viable performance patch.
Something I'm going to try today is a way of crossfading (by a few milliseconds) the new audio into [poke~ one] rather than using selector~. IF that works it's a much better method all around, as the clicks won't exist in the first place.
Also, I'll eventually see if it is possible to build 1 or 2 levels of "undo", which would be really useful in a live situation, and also makes it more interesting for composing. But that might turn out to be stupidly complicated, who knows.
Thanks for the reply
You can swap arbitrary blocks in a buffer with my buffet~ object in faster-than-realtime. To avoid clicks, you'd need to make sure that any play heads are not situated over blocks when they are swapped.
Good luck,
Eric
That looks pretty interesting to experiment with, but it isn't the concept behind what I'm trying to do.
Rather than swapping blocks of audio in a buffer I am replacing blocks of it with new audio in real-time.
I've worked out how to get rid of the clicks in my previously posted patches. Instead of recording the clicks and windowing them out, I'm going to use crossfading rather than selector~ to switch between the two audio sources for [poke~ one] (inspired by your clean_selector but signal controlled).
I just need to work out how to create a half-hann function with a signal transition of 0 to 1 and the opposite function for a signal transition of 1 to 0. It needs to be pretty short as well, < 512 samples if possible, but I'll worry about that when I know how to do it.
I just made a new topic for that question, as I'm new to that level of maths in msp.
If anyone is interested, I sorted out the occasional glitch/distortion that happened when replacing. It was due to the signal inconsistencies inherent in using phasor~ ramp * loop length. Trunc~ was useless for that situation, because it creates points in the signal that increase by more than 1 at a time == glitch in poke~ and index~.
I re-built most of the patch, replacing phasor~ with [+=~], [accumulate~] and [%~]. This is FAR more suitable as a playback signal, as it moves in constant steps of 1. I might ditch phasor~ completely for sample-accurate stuff. I think I saw a thread about that topic a little while ago while searching the forum........
The whole patch is simpler now, which is good, and I'll try and incorporate the hann crossfading tomorrow while replacing, and also when recording the initial loop, as this would eliminate re-loop clicks without the need for the anticlick subpatch. cool
- tim