Hi,
I want to play audio I have stored, I guess in an array, but I want the samples not to be played strictly left to right, but some samples shifted in time or order. And if possible, I'd like parts of the array to be read from right to left. When I say right or left I am referring to the timeline of the audio file, from beggining (left) to end (right).

Does anyone have any suggestions as to how to approach this? What i am trying to achieve is a type of glitchy effect when playing an audio file. I also don't want to change the pitch of anything, just the order in which the samples are played.

If anyone has some ideas please let me know. I feel like this is a real typical sound in Max or Pd, but I have never really been able to do it.

thank you in advance for your suggestions.

If I have an audio file entered into an array,

@nicnut This might be useful...... it's the old help file from Pd extended and includes at least reversing an array...... all_about_arrays.pd
But an array is indexed...... so can be played backwards anyway by counting down instead of up.
You need the total size of the array (so as to preserve the pitch) and then you can use [phasor~] if you want repeats, or [line~] if you don't, to play parts or all of the array in both directions.
You just need to calculate the range according to the total size of the array.
Here is an old attempt using [phasor~]....... Microsound-granular.pd
It is all just maths...
David.

Hi
I thought I would have a go
maybe this might help
Cheers
Balwyn
random-read.zip

@Balwyn
Hi Balwyn. Wow this is exactly the type of sound I was envisioning. I am going to need to study your patch a little, but it sounds incredible.

So, an audio file is fed into the patch, a soundfiler determines the length of the file in samples. Then a phasor randomly selects a sample to do playback from. And there is forward and reverse audio output.

I adjusted it a little and added a metro with a randomized tempo to generate the random numbers, so the rhythm wouldn't be so even.

But this is really amazing and exactly what I was trying to figure out.

Thank you. Nick

FWIW -- Pd's native interface for sound files is difficult. While that's consistent with the "minimal core" philosophy, I find it annoying enough to work with that I would sometimes be tempted to avoid using sound files just because of rebuilding basic functionality.

For example, a couple of factors that haven't been mentioned in this thread yet:

• What if the sound file is at a different sample rate from the audio system?
• Also, audio engineering 101, every audio segment hitting the speakers should have an envelope, even if it's just a trapezoidal envelope with a very short attack and release. Otherwise you will get clicks at every splice point. This means, then, using two players and toggling between them (because the ideal splice is a short crossfade, not a jump cut).

A while back, I made a set of abstractions to simplify these problems. Using those, this is how I would do it.

24-0210-segmenter.pd

Here, the logic is:

• Choose a random duration.
• Choose a random direction, +1 or -1.
• Random starting position is chosen based on dur * direction.
  • Random range is 0 to (soundfile dur - abs(dur)).
  • Then, if dur is negative, we have to shift the entire random range up, by subtracting the negative number.
• Then the endpoint in the sound file is start + (dur * direction). Backwards playback is start > end.
• Last, toggle 0 or 1 to choose one of two sound file players.

monofile and sf-play~ are abstractions of mine. sf-play~ uses cyclone. Note that cyclone's play~ claims to take time indices in ms, but it doesn't compensate for sample rate. My abstraction does this automatically -- ms go in, ms come out.

YMMV but I find working with sound files is much easier when the programming interface is more usable.

hjh

@ddw_music Very good. For joining 2 parts of a continuous sound a good crossfade in the right place and in phase is vital for a decent edit.
I don't find 2 players necessary though, where 2 different parts are joined, such as in a glitch.... in my patch above there is a simple duck... 3ms down, 3ms up.
It is obvious that there is a "join" and our brains cannot adjust quickly enough to hear any silence.
Our ears are quite quick... necessary for phase information (there is a lion behind me) but our brains are slow.....
Tone....... change_perception.pd
Noise...... https://pubmed.ncbi.nlm.nih.gov/3843099/
David.