I have a step-sequencer-like patch that plays forwards and backwards. I am using [counter] as the part that controls what beat is currently being triggered. There are controls to set the first and last step, meaning if you want you can loop steps 3-6 or all 1-16, etc. by just adjusting the start and end beat. The problem is that so far it seems I can't send [counter] a min value without it also setting to that value immediately. The max command doesn't work the same way.

Fortunately, [counter] has some outputs that bang when the count gets to the max and so forth, so I have it set up so that the min value stores until it gets to the end of the count and then it fires off the min value again. This way, if I change the starting step, it doesn't affect it until it makes the next pass through the sequence, rather than jumping to the first step as you adjust it.

This is fine in forward play, although a little annoying to implement, however the problem comes in when I reverse the sequence (the steps play in reverse order). Because of the way [counter] bangs its outputs, there seems to be no way of accomplishing this. The closest I have come is setting up a comparator so that when the step it's currently on is the value set by the first beat control, it will restart the counter from the end beat. This doesn't really work that great though, because it only allows you to shorten your sequence, not lengthen it. Meaning, if you are looping steps 4-10 and it's playing in reverse, you can change the beginning step to step 6 and it will wait til it hits step 6 to change the range, but then obviously if you set the beginning step to step 3, it will never change because it never hits step 3!

Hope this makes sense somehow. Basically what I figure I need is a better [counter] element that allows you to set max and min values without it actually affecting where the count is in the sequence.

That's the ticket! The only thing this one didn't do is differentiate between stop and pause, but i managed to take care of that easily enough.

At some point when I feel it's ready, I'll share the monster patch that this is just a part of and you guys can play around with it. It's kind of an all-purpose phrase sampler that gives you the ability to do all sorts of manipulations in real time, including a feature that automatically segments the phrase into a number of beats that you can select and then play those beats back in the correct order or different orders, which is where this sequencer comes in.

Thanks a lot for everyone's help - this was the part that I wanted to get working perfectly before I moved on to adding more features, as everything else works fine and it's actually a kind of impressive instrument, if I do say so myself.

http://www.pdpatchrepo.info/hurleur/sampleworkstation.png

Thanks guys! Some of these are close-but-no-cigar. I'm attaching the existing [counter]-based transport system. It's quite messy, like most of my patches. This is obviously just a small subpatch of a larger patch and it probably won't work by itself because it's not receiving values from the main patch that it needs. But I thought it might help to show how what I eventually get needs to work within the context of the patch.

Note that it needs to be able to start, pause (where start will pick it up again in the same place), stop (same as pause except start causes it to resume from the first step), retrigger (pressing start causes it instantly to start playing from the first step) and reverse (on next firing of counter), and be able to adjust first and last beats without it affecting the count. So far, the existing one does all of these except adjusting of min value while in reverse. In all other behaviors it works as I want. Also, as you can see, working with offsets would appear to complicate the patch whereas right now the rest of the thing is designed to respond to simple step numbers.

http://www.pdpatchrepo.info/hurleur/seq-transport.pd

Starting from scratch, I tried to make my own and this is what I've come up with so far. It needs some tweaking, but it seems to work alright for the most part. It seems if you hit reverse and it is currently on the max step and then hit reverse again to get it to go forward it will go onto the next step after the max one and then keep going. Haven't exactly figured out why it's doing that.

http://www.pdpatchrepo.info/hurleur/new-counter.pd

thanks, this works pretty well, although not exactly as i need it for the patch i'm working on. one part i fixed already: i added one bang connected from the +1 and -1 messages to the + element. without it, the change in direction doesn't take effect until the following number in the count. meaning if you're on 4 and you click switch direction, on the next one it should go to 3, not to 5 and then to 4 and 3. such was the behavior without this additional bang.

the other behavior i'm not exactly sure how to fix yet. i'm still learning the problem is that the min and max values don't take effect until it reaches the existing max or min value. meaning, if you are currently looping 3-14 and it's counting back from step 14 and you click to set min at 6, the current behavior of this patch is that it will count backwards to 3, then starting back at 14 count backwards to 6. same for forwards. trying to figure out a way around this at the moment.

the funny thing is my existing jury-rig of [counter] did all these things except reset min properly when going backwards ;P i'm sure in the end i'll wind up with a superior way of doing it, but it feels like i'm starting at square one so far.