Yiannis Ioannides

I am very new to Max/MSP, so bare with me!

So I tried creating an audio probability drum machine with some filter effects, and in the past, I created a simple stutter idea, using the buffer~ object, but in this patcher, I use the sfplay~ object to play my soundfiles.

Now, my question is how to use my stutter idea that I have (on the bottom of the patcher) within the current patcher, and stutter my 4 soundfiles without looping them, and all playing at once?

I am very new to Max/MSP, so bare with me!
So I tried creating an audio probability drum machine with some filter effects, and in the past, I created a simple stutter idea, using the buffer~ object, but in this patcher, I use the sfplay~ object to play my soundfiles.

question-for-real-time-playback-stuttering

I hope I copied the patcher's text correctly for you guys, it's my first time, I am sorry in advance.

Can I ask why you made the switch from [buffer~] to [sfplay~]; if you desire loop-length/repeat control over audio then would you not be better off with [groove~] etc?

I can highly recommend this guy's collection of toots:

http://www.youtube.com/watch?v=hcVlPpaG4qQ

I can highly recommend this guy's collection of toots:
http://www.youtube.com/watch?v=hcVlPpaG4qQ
Brendan


Maybe I wasn't very clear on my question, sorry about that, let me rephrase it:

So I have basically 2 patcher ideas, the drum machine idea that loads its individual samples with sfplay~ and then the stutter edit idea, which I imported from another sample, given that I made this a long time.

Now, I am scratching my head on how to implement the stutter edit patch that I made on the bottom, in my patch, in a way that I will use an object just to load the samples, but not loop, I want them to still keep playing randomly (you can always refer to the patch, to see what I am talking about) but stutter all 4 samples together, without them looping back and forth, I just want to stutter the samples by holding down a key, and when I release them, to continue their random motion.

I have seen this guy's video before to get some ideas, but in this case, I didn't want to load an all-in-one rhythm kit clip, I just wanted to have 4 different ideas, playing randomly.

"Now, I am scratching my head on how to implement the stutter edit patch that I made on the bottom, in my patch, in a way that I will use an object just to load the samples, but not loop, I want them to still keep playing randomly (you can always refer to the patch, to see what I am talking about) but stutter all 4 samples together, without them looping back and forth, I just want to stutter the samples by holding down a key, and when I release them, to continue their random motion"

I haven't time to hack your submitted patch, but here's a pretty flaky way to achieve what you want...according to the quote above....

But now the thing is that whenever the gswitch opens, it stutters the soundfile by taking it back to 0 time, while I wanted for it to stutter wherever the loop's position is at the time. Also, in my little example, I have many stutter options, that are a bit more smooth, in regards of timing.

Here's what I mean: (try loading a sample)

"it stutters the soundfile by taking it back to 0 time, while I wanted for it to stutter wherever the loop's position is at the time"

this describes exactly what [groove~] is designed to do; there's no need at all to use separate objects for random triggering and stuttered playback; there's an extensive discussion here:

https://cycling74.com/forums/groove-wont-reverse-on-startloop

The [groove~] and [sfplay~] helpfile should also help; did you know, for example, that [sfplay~] will also do stuttered looping?

It's an interesting discussion, and I will make sure to follow it for future reference, however, unfortunately, it doesn't really solve my problem, on how to merge the two patch ideas that I have together...

You might want to open the two different patches I sent here, so you have a better idea on what I am talking about, if that's not a hustle for you!

I, basically, want to connect my [sfplay~] objects to the stutter edit patch, and take it from there, but I am not sure how to:

2. Stutter whichever soundfile is playing at the time, and NOT go back to time 0. (as I have already done in my stutter patch)

3. Have different stutter choices in durations. (as I also have done in the patch, with the [split] object)

4. Make sure that, by the time everything works, the notes don't loop, like in the stutter patch. I just want them to trigger randomly, like in the Drum Patch!

I took the initiative to send you (and for the forum) the .zip file with all soundfiles and the two patches. The main patch is Drum Patch and the stutter idea is Stutter To Work On.

Again, thank you so much for taking time to help me Brendan, I am trying to get better at it!

1. Get sound from it.
2. Stutter whichever soundfile is playing at the time, and NOT go back to time 0. (as I have already done in my stutter patch)
3. Have different stutter choices in durations. (as I also have done in the patch, with the [split] object)
4. Make sure that, by the time everything works, the notes don't loop, like in the stutter patch. I just want them to trigger randomly, like in the Drum Patch!

Again, thank you so much for taking time to help me Brendan, I am trying to get better at it!


I am more than happy to try to assist, but can you clarify one thing:

1. you want the random-player to connect to the stutter patch, that's clear;

2. but then you say " make sure the notes don't loop"? But surely the stutter effect requires looping?

Everything else is clear, and simple to implement, just clear this up for me and i'll take a look.....

I am more than happy to try to assist, but can you clarify one thing: 

1. you want the random-player to connect to the stutter patch, that's clear;
2. but then you say " make sure the notes don't loop"? But surely the stutter effect requires looping?

2. Of course, loop within the stutter, but after you pull of the key, to just go back to the random mode!

1. Yes!
2. Of course, loop within the stutter, but after you pull of the key, to just go back to the random mode!

it'll be mid week before i get any free time - 2yr old son, PhD and wife to maintain!

Oh yeah, absolutely no problem! There are a couple of things I would like to try too!

Bumping the topic once more, if anyone can solve my problem, I would be really grateful!

Bumping it one last time, sorry for the persistence, I still haven't resolved my problem.

this is all I got time for I'm afraid......not perfect but it does what you ask although it doesn't use the patch elements you submitted - simply don't have time to do others' work for them, sorry

ps, you should look at the [chucker~] object

Hey
this is all I got time for I'm afraid......not perfect but it does what you ask although it doesn't use the patch elements you submitted - simply don't have time to do others' work for them, sorry

Brendan
ps, you should look at the [chucker~] object


I had so much fun with this, that I recorded it:

http://www.youtube.com/watch?v=Isv_PtTA7dI

Not exactly rocket science, but a simple and fun way to do 'granulator' or [chucker~]-type stuff with one [groove~] object.

That's really awesome Brendan, I also subscribed to your channel!

I can put this patch into some use in the very near future, though for my existing patch (not the stuttering one, the main one) I cannot seem to be able to stutter an ongoing signal from the sfplay~ objects. Now, I understand that I don't have to use sfplay~, especially when there are so many linear variations of this object, but with the buffer~ object, it doesn't seem to respond to the bangs that I have from an ongoing signal, it can only store a loop.

To my sad realisation, the stutter patch really doesn't work on the drum patch, even after studying chucker~, buffer~, sfplay~ etc., to find clever alternatives to override that.

Question for real-time-playback stuttering