Question about gen~ 'chopper' examples

Sep 22, 2012 at 1:16am

Question about gen~ 'chopper' examples

I really dig the sound of the basic gen~ chopper example, and just now noticed the chopper_repeat version has been changed quite drastically (not looked at it in a while). It sounds amazing, and I like the extended control.

One thing I can’t figure out (I don’t really understand the code behind either gen~) is how to make the ‘repeat’ version behave like the regular version when no audio is playing. With both having the capture parameter always engaged, when you stop audio input going into the regular chopper it freezes on the current segment, and this produces a single static pitch (often inaudible). I really like that behavior, and use it often. The repeater one (regardless of how I tweak it, including de-commenting stuff in the codebox guts) always stops on a static/gristle type sound.

I suppose I can tie the ‘hold’ parameter to incoming level (peakamp~) but I’m wondering if there’s a better way to go about that. Or if that’s what the regular chopper is actually doing (holding the last segment until audio comes back in).

#64444
Oct 6, 2012 at 9:53pm

I’ll try and explain what’s happening with both of these examples. There’s a recording section, which continuously captures new grains bounded at zero-crossings (wavesets), and a playback section, which continuously plays back the captured segments one-by-one.

Each grain is written into / read from a different channel of the (Data segment_data), and the length of each grain is recorded in (Data segment_length). It supports up to 64 grains.

The recording section is always writing into one of the grains (one of the segment_data channels), according to the write_segment variable. It counts the zero-crossings (in crossing_count variable), and if enough zero-crossings have occurred, it stores the grain length, switches to the next recording grain, and resets the recording counters. There’s some extra logic in there to ignore segments that are too long, and to make sure it doesn’t start writing into a currently playing grain.

The playback section is always playing back from one of the grains, according to the play_segment variable. Most of the work is in determining which grain to play next, when the current grain (with repeats) has finished. There’s a bunch of different strategies in the code that can be uncommented, from random selections, random walks, ordered playback etc. Most of them include extra logic to make sure that it doesn’t start playing the grain that is currently being recorded.

But to match the original chopper example, the strategy is just to play back the most recently recorded grain, which in code looks like this:

play_segment = wrap(write_segment – 1, 0, num_segments);

This means take the index of the currently recording grain, minus one to get the previously recorded grain (which is therefore the most recently completed one), and then wrapped into the range of possible grains (so grain index -1 safely becomes grain index 63).

So just comment out the part that is doing the random walk, and put that line in instead.

Setting the crossings param to 1, stretch to 1, min_length to 1 and rate to 3 sounds almost the same as the old chopper, maybe a little softer (I probably didn’t avoid all the possible clicks in the original chopper example…)

Setting min_length to about 300 and rate to 1, leads to an almost perfect reconstruction.

I’ve added a way to switch between playback strategies. Having a lot of fun playing with this:

– Pasted Max Patch, click to expand. –
#232452
Oct 6, 2012 at 11:14pm

Thanks for this!

I did notice all the commented code but didn’t play with it much. It’s amazing the difference it makes. Very powerful option/choice/control.

I don’t know if I’m doing something wrong, but there seems to be some wicked clicking in this (heavily based on the stretch parameter).

#232453
Oct 7, 2012 at 12:50am

Here I’ve updated it to deal with the clickiness at switching/looping segments. There’s an extra sample recorded in the loop, and the playback cross-fades the extra samples according to the fractional sample index. Seems to get almost perfect reconstructions, which is nice! Also sounds pretty much like the original chopper example with the right settings.

– Pasted Max Patch, click to expand. –
#232454
Oct 7, 2012 at 8:54am

Badass. This is quickly becoming my favorite “effect” in terms of range/complexity. Great stuff.

#232455
Oct 8, 2012 at 12:54am

Yeah, I’ve been having a lot of fun with this too.

The next-to-last outlet gives the current grain duration, which can be inverted to give you a frequency estimator too. Now that the durations are sub-sample accurate, the frequency estimation isn’t too bad either. For example, it can be fun to also use play_index / play_len as a phasor to drive another waveform, for waveform substitution.

There’s a ton of other things that could be done with it.

The input signal could be low-pass filtered before being sent to the trigger detector (while the grain actually records the un-filtered input), so that high-frequency fizz doesn’t create lots of tiny grains. It would be important to keep the same phase delay for the filtered and unfiltered parts, which could be achieved with the crossover filter example.
Or the trigger section could be modified to be sensitive not just to zero-crossings, but also paired with other analysis properties, such as spectral changes.

I made the analysis also store the average loudness of a segment, which could be used to compress or expand the playback amplitudes…

It wouldn’t be hard to add more than one playback section, for multiple overlapping grains. Multiple recorders (for sampling more than one source at a time) would be trickier, but possible.

Omitting grains, or inserting small pauses between grains, may introduce some interesting distortions or formant-like effects.

Instead of a fixed number of repetitions, it could repeat until a new grain has been recorded (in ‘recent’ mode). That should preserve the ordering without jumps.

Another thing to try would be to adjust the playback rate according to the grain length, so that it makes a continuous and controlable ‘tone’. I added that in the one below, as well as some different ways of changing the pitch over grain repetitions.

Plenty of more ideas could be drawn from Trevor Wishart’s ‘On Sonic Art’ [1], or the waveset tools in the Composer’s Desktop Project [2], and so on.
[1] http://books.google.com/books/about/On_Sonic_Art.html?id=h2J9v3hx_FgC
[2] http://people.bath.ac.uk/masjpf/CDP/docsrefs.htm#XLST

– Pasted Max Patch, click to expand. –
#232456
Jul 24, 2013 at 5:22pm

Hi,

gen~.chopper_repeat / max 6.1.3

Once i release the ‘capture’ button I get a really nice, click free loop that I would like to write into an external buffer for further processing

however, i’m a bit stuck and think the answer to either of these questions might help.

how do i return the total length (in samples) of all 64 play segments?
or
is there anyway of outputting a bang once play segment 63 has finished?

sorry if these questions have obvious answers.

thanks

#257067
Aug 18, 2013 at 5:32pm

You could keep track of the total duration by updating a History object in the if(is_complete) section. E.g., where it currently states

len = write_index + offset – prev_offset – 1;
poke(length_data, len, write_segment, 0);

You could replace it with (assuming History total_length is declared above):

prev_length = peek(length_data, write_segment, 0);
len = write_index + offset – prev_offset – 1;
total_length = total_length – prev_length + len;
poke(length_data, len, write_segment, 0);

That updates the total length every time a new segment is recorded. Then you can simply output that from another outlet. (see below)

There’s no way to output a bang from gen~, but you can very simply test according to the value of the write segment (e.g. [==~ 63] -> [change]) to get a trigger signal.

– Pasted Max Patch, click to expand. –
#259219

You must be logged in to reply to this topic.