ComfortableInClouds

Hello - I feel relatively proficient in some parts of maxing nowadays, but lists aren't one of them. I am looking to make a 'groover' for bangs and need help in altering the lists as I intend. The idea is this:

You have a multislider (variable # of steps), which can move up or down to either groove ahead of the beat, or behind the beat (by knowing the amount of time between bangs, and sending each bang through [delay] whose time is adjusted accordingly). However, if you shift one slider either up or down, a slider X number of sliders away has the opposite amount added to it, so that no matter how "groovy" the bangs get, after they have traversed the multislider, they are guaranteed to be 'nsync. I accomplished something similar without lists before, through this schematic:

but found that changing the sliders while the bangs were running would lead to variations in time. So it works fine for predetermined, sequenced patterns, but can't be toyed with in real time, during a performance.

Any list-wisdom from some more experienced maxers would be much appreciated. No need to build this groover for me, but at least just set me in the right direction. I've been floundering around with [zl], [counter], [iter], [coll] and [uzi] to no avail.

need-help-with-list-problem

(note: patch makes use of an Lobject - if you didn't have this library, download it right now. It's awesome.):

That of course is just the multislider portion, but a groover from that will be super simple to create.

man - i spoke too soon. :-( i just saw a bunch of sliders moving and thought it worked :-P The slider doesn't seem to balance itself out. I think it might have to do with the slider's range. The question is, what to do if a slider tries to move out of range?

More fundamentally, the question is how to weight values. Say you have the number 100, and 4 different sliders controlling that value. How can you get it so that If you raise one slider from, say 25 to 37, the other sliders will go from 25 to 21?

Okay, I'm not 100% sure I understand your entire question, but I think I understand the part about adding/subtracting in order to keep the whole thing in sync. One thought occurs: at any given time you are in the middle of one of the "beats" (namely, the pipe object), so changing the delay time value will not change the actual delay time since you are already in it. It seems that that would need to be taken into account when you compensate in the other beats. I might be way off, but this could explain why it gets out of sync when you change it in real time.

Stephen, first thanks for the reply; I was afraid I was just getting ignored on here :-D. I think I see what you're saying with being in the delay time, but the amount needed to add/subtract always gets passed to the next bang, so that you aren't trying to alter values that are currently being used. I'm not even so sure the "gruver" I posted gets out sync, might of jsut been faulty testing. I did, however, realized that I forgot a key bang in the "gruver" patch I posted earlier, so that it probably didn't work at all for anyone who tried it out. Here it is fixed, and a bit stripped down, if anyone is interested. Added a reset sequencer, too, just to be safe with the whole sync thing.

As for my first question - it's basically like this: I'd like to create a multisder where the sum total of all its sliders can only be X at any given time. If a value moves above or below that number, all other sliders are adjusted slightly to balance out the slider value. I know it's possible with lists, but for now my gruver patch is working as I'd like it to, so I'm going to let it rest for now. If anyone is intersted in trying to solve this, please let me know as I would very much like to gain some more list wisdom.

Where's Chris Muir in all this? It seems like any time I have a problem like this he's here within the hour with just the answer I was looking for. 

Perhaps you could use a watchpoint or print object to monitor the sum of all the rhythmic values. You could also monitor the delta time from beginning to beginning of the phrase. With those two values, you should be able to figure out if the phrase is momentarily changing in duration or if it is somehow shifting/getting out of phase. I haven't looked at the patch in depth enough to see exactly how you are adjusting the rhythmic values to compensate for changes, but here's how I would do it: Find the total duration of the phrase and divide it into the "target" duration. Then multiply that value by each element in the list using vexpr.

I think that a rhythm created by running stuff through pipe will probably tend to drift out of sync due to rounding errors, even if it does not have any actual bugs. If you want it to stay exactly in sync with another patch or program, you might consider using phasor~ along with some >~ and edge~ objects. The reset sequencer you mentioned would also work, but phasor~ would give you a lot of flexibility in terms of changing the tempo/direction or modifying the rhythm in interesting ways (think kink~).

I haven't got Max on this computer so I haven' t seen your patches. and may be totally misunderstanding you're problem - but I built a 'groover' (16 step sequencer with temporal variation on each step) a couple of years ago.

The idea was to then randomise these within a certain range to get a humanised effect.

Simplified, I used a count- 0-63 (4 banks), prepend getcolumn for matrixcontrol, pack into a list of 0's n 1's for each step, where a 1 triggers the sound. 

The difference being - the 0 count would actually correspond to the 2nd step, the 1 to the 3rd step and so on. 

In the default position- where nothing is swung, every step had a delay of half the time in ms of 2 steps - depending on the current tempo.

That way you change the pipe delay to make the trigger early or late. 

Because the first step is triggered by the last getcolumn of the matrix sequence, you need to output a list for the first column when play/start is pressed, otherwise you'll miss it altogether.

However, doing it this way, my patch was limited in that there was no provision to trigger a pre-delay for when play/start gets pressed :)

I haven't got Max on this computer so I haven' t seen your patches. and may be totally misunderstanding you're problem - but I built a 'groover' (16 step sequencer with temporal variation on each step) a couple of years ago.
The idea was to then randomise these within a certain range to get a humanised effect.

Simplified, I used a count- 0-63 (4 banks), prepend getcolumn for matrixcontrol, pack  into a list of 0's n 1's for each step, where a 1 triggers the sound. 
As you would your normal sequencer.

The difference being - the 0 count would actually correspond to the 2nd step, the 1 to the 3rd step and so on. 
In the default position- where nothing is swung, every step had a delay of half the time in ms of 2 steps - depending on the current tempo.
That way you change the pipe delay to make the trigger early or late. 
Because the first step is triggered by the last getcolumn of the matrix sequence, you need to output a list for the first column when play/start is pressed, otherwise you'll miss it altogether.

However, doing it this way, my patch was limited in that there was no provision to trigger a pre-delay for when play/start gets pressed :)


Need Help with List Problem