How to randomise a value whilst keeping the index of that value static during automation?
Hello again!
I have edited this post with another query which I’m hoping somebody could help me with.
I am using Multislider which outputs a list (16 values in this case) and each step (index) is being automated to move left at every metro bang.
I am trying to randomise a value whilst keeping the index of that value static, the values of each of the indexes are automated to move along one step at a time, think of the Live.Step object with the left or right message being sent into it.
The problem I am facing is how to randomise only one of the indexes / steps without it moving along or effecting all the other values that aren't randomised but static in value?
I tried using [zl nth] object to select one of the numbers in the list to randomise but it keeps moving along due to the [zl rot] rotating the whole list...
Hmmm, I hope this makes some sense? :)
I have posted my patch (with no randomisation) just to help visualise what I’m trying to do...
I am trying to randomise a value whilst keeping the index of that value static, the values of each of the indexes are automated to move along one step at a time, think of the Live.Step object with the left or right message being sent into it.
*friendly bump!
Here's a patch that randomizes the fifth slider and rotates the others
Hmm, after looking at Rick's patch i might not have fully understood your question properly, but here's my contribution. It's a javascript implementation, which freezes a value at a certain location in the list while rotating the others an arbitrary amount. To do that you need to rotate, then swap the value at the frozen location with the value at the frozen location, less the rotation amount. you could probably do this in max vanilla, but I did this in javascript as an exercise. you need to include the js file "freezeElement". Will work for any length list, and any rotation step size. can only freeze one location at a time. Hope it's of use. You could extend the code to do the random value change pretty easily.
I am hoping Rick or Floating point (or anybody!) could still chime in and help resolve issue I am facing in this patch.
After spending some time with both solutions (Thank you guys!), Rick's offering is the closest to what I am after but not quite right, it isn't as dynamic as I was hoping for. (Changing the index of a step or steps to randomise requires altering too much of the patch) I also noticed the sequence skips the randomised step resulting in less steps (15 instead of the 16 needed for a sequencer)
I believe the 2nd patch I posted will do as you requested. All you need to do is put the js file in your max search path and the file will be instantiated as an object. The example patch provided illustrates how the object works.
Thanks for getting back to me, problem with your patch isn't that it randomises one of the indexes, it doesn't allow me to change the value of the other sliders if metro is running.
Also, you mention in your patch that only one index can be randomised, I was hoping to randomise more than one slider.
Just to give a bit more context in what I’m trying to achieve, I am building a sequencer with the option of turning steps on / off, each on step will turn the randomisation of that index on, the issue I am facing is how to randomise a step whilst the steps are rotating and when that is solved, how to randomise more than one step.
well it does what you originally wanted, but if I get time I'll have another look-- in the mean time you might be able to figure it out yourself (clue: multiple instances of same object)
I appreciate that, perhaps I should have explained better.
I made a small change so you can update the list while it's rotating-- this new js object has 2 inlets, which is in line with normal max object paradigm so it behaves better (right inlet takes list as initial values, left input takes a bang to trigger transformation); but the multiple non-rotating locations is a little trickier...
Awesome, yes this is a great starting point for me, I will take a dive into this and see if I can add more to it (add the ability to freeze additional indexes)
Thank you so much Floating Point, much appreciated!
After spending a bit more time with your patch, I have observed that the moving steps (rot) is skipping the frozen step which exhibits the same behaviour as Rick's patch.
So as the sequence moves, the frozen step should still be accounted for, the sequence is moving along 15 steps as opposed to the 16 I am after.
I'll try and rebuild this idea from scratch again. If I find a solution, I'll post it here.
Thanks for the help anyway Floating Point.
This works as you require.
I had to make an extra
copy of the array inside js for it to work properly.
you can now chain as many instances of the js object together for each location you want to freeze.
The only object that needs the rotation parameter to be non-zero is the first in the chain.
The output of one object needs to go into the right inlet of the next, otherwise it won't wait for the next bang to output the transformation.
the max patch here illustrates this with 3 stages:
Thanks for the update, I have noticed some issues. It seems the frozen index is affecting the current value onto the following step.
For the sake of this example, I disconnected the drunk object and the other two frozen steps are unfrozen
All steps are at 0, frozen index at 0 (first step) and chose a number in the number box connected to freeze 1, every time I move one of the other steps which isn't frozen, this causes the step next to the frozen step (index 16 in this case) to have the same value.
try putting the multislider list into the first inlet of the first js object. but keep other stages going into their right inlets. Also make multislider non-continuous output (in inspector)
That doesn't work, it still causes the frozen value to leave a stream (like it's feedbacking)
I believe continuous output is needed to keep the UI updated in realtime, although I did try it without continuous output like you suggested.
sorry cannot reproduce your issue-- maybe you inadvertently altered the patch in some way.
I guess you could post a simplified version of the patch illustrating the problem.
(use this as a starting point)
I have left some comments for you to follow with the patch below..
it's just to do with the way you modify values and the UI-- if the list values are changed by dragging the mouse in the multislider, and then if that mouse drag is interrupted by a bang from the metro to update the rotation then only some values will be updated-- (that's why I suggested changing multislider to non-continuous mode, although it's not really a 'fix'). Anyway it's not a malfunction of the js object as such; it's just how you incorporate it into your patch, and how you design your patch to achieve what you want.
here's a version with a separate multislider to enter /alter values: the top one outputs non-continuously into the rotating one which can't be changed by the user
Even with the separate multi slider, the patch still exhibits issues. Try it yourself, double or triple click the top multi slider and you'll see the bottom multi slider steps resetting itself.
probably the reason for your problem is as described in my previous post (your list updates are interrupted by a metro bang). Anyway try this:
here the list is stored in a zl reg and only sent to the js object once every cycle (hence counter) to ensure continuity of your rotational cycle. (but this will only work for single step rotations-- you need to have a think for yourself about other types of rotations). This is really a patch design issue and is to do with what you want your patch to do. I have no idea what this is for so you should probably nut out these sorts of issues yourself. Having said that I could probably make another js object which incorporates the functionality of the current cascaded objects as they stand.
Thanks for the help so far, I mentioned in a couple of posts above the idea is for a sequencer I am working on. Similar to Live.step and its rotation commands messages (Left / Right) but I wanted to do away with live step and build a lighter version with additional features like the frozen index which can be modulated whilst the other steps are moving along the sequence.
I feel that although your solution is close, it isn't working with continuous data which is something I require.
but a step sequencer isn't continuous, it's discrete--by definition you have to wait for the next step (metro) before it updates ...
Yes that's right but the UI through the user's interaction of the step sequencer isn't updated the same way. Have a look at Live.step or Rick's patch near the top, this is basically very close to what I am aiming for, but the problem with his patch, is trying to implement more frozen indexes isn't intuitive, besides his patch is skipping a step (which yours fixed)
Doesn't seem to be working, the bottom Multislider isn't changing the top Multislider.
Ok weird, after moving some of the parameters, it started working.
Thanks Floating Point. Appreciate the effort you've put in.