noob math question
Sorry, I have some lack in some basic maths...
- I have a dynamic value X,
- a slider (range 0.127.)
how to dynamically select only the outputs of the slider that are the division of 128./X
If I change X to 3, the slider only outputs : 0. / 64. / 127.
etc..
the "step" attribute seems to do not be a solution here because I need that each value can be triggered several times.
This slider is mapped to an expression pedal.
If the slider has 3 positions, the pedal should trigger an event when it is totally down / totallu up / at middle position. And only at these positions.
With the "step" attribute, it's working but if I hit several time the 0 position of the pedal (and never go after 64) the sound is triggered only the first time because the slider "don"t understand" as a change a value which is not 0 , 64 or 127..
Not sure if it's very clear.. sorry
for now
a/ I divide 128 by X and create a list where this value is added to itself X times
b/ the slider feed a scale object with the max output value set to X
c/ a zl sect object is feed with a/ and b/
I am sure it's easy but I find only not very elegant solution..
thank you !
For now it's working, but it seems a bit complicate...
In case I understand what you want ...
which might not be the case without seeing the patch and
understanding the purpose of output values .
This theoretical thing will never work well in practice,
because you will produce too many unwanted "hits"
if really using expression Pedal with more divisions.
What if you want to hit top (127) and then bottom (0), without executing the middle value ?
Trust me, it is going to stress you to get the values right with the pedal.
Even if you set up some rules, like pedal has to remain for 100 ms
in the range to trigger the value, it will stress you to get the timing right.
In theory one could make a multy switch out of a slider, but one would need
a clever division of ranges, safe areas of values between the trigger
ranges, and some sort of speed of movement detector to allow
crossing of trigger ranges without executing them, to be able to
jump instead of slide between the trigger points.
-----------
But let's take it the way it is.
you can't divide range 0 - 127 with equal slices of arbitrary divisions,
because you use ints and not floats.
So you would prefill a list with closest "hits"
for selected division.
let's take 5 for example :
you want 0 and 127 to be lowest and highest "hits", and so need equaly positioned 3 more
"hits" in the middle 32, 64 , 96 (128 / 4 = 32)
now your list is 0 32 64 96 127.
as you say you use zl sect, then it should output the values when you
match them with the pedal.
To the next problem - retriggering same "hits"
simply go a bit above or under the "hit" value and cross it again...
No need for scale object...
thank you !
It's not a problem here for me if "64" is eachtime triggered when I go from 0 to 127 and vive versa.
Did you see the patch I posted just before ? It's almost working...
some random bits:
- mapping a range to an integer range in practice often involves either truncation or rounding at one point.
- this is can (like probably here, too) involve truncation or rounding in steps of more than just "1".
- when i need to do something like that i usually start with 2 messageboxeswith some example values for the desired in- and output so that you see it side by side. the algorithm is not far then.
- you called it a "math" problem. in fact there is a lot of logic and data formatting involved in this kind of jobs.
"you can't divide range 0 - 127 with equal slices of arbitrary divisions"
this often happens to people when you come from midi.
the solution i usually implement is to clip the original range.
example: how to divide up a 7-bit controller range into 5 equal spaces? - by simply not using 125, 126, and 127.
0-127
split 0 124
/ 5.
* 1, * 2, ....
all unavoidable-in-int inaccuracies are now shifted f.e. to the upper end of the physical modwheel - but you code is clean: all sections are of the same range.
p.s.:
and in schlam´s original patch you should at least do all calcualtions in float, then round to integer, in order to get nearer to the best possible values.
No, I did not see the patch before responding.
What is not working for you in the patch you posted ?
I don't use live , so can't say much about it's problems.
I see you inserted that everynumber thing, is it because live.slider sucks ?
And... if you don't want to recalculate that values all the time,
you can fill umenu with premade lists .
round
round used that way is a perfect choice to
split the slider range.
But to pick only selected values one needs
sel or zl sect.
Round can be well used to create the list
for zl sect
thank you all. I, thought my patch was too complicated for that purpose and that I missed something essential.. but it seems not =)
All is working as expected , just sometimes there is a problem after the thresh where the list sometimes is doubled "0 64 127 0 64 127" for example. So I choose to replace it with a dynamical [zl group].
The final device is here.
It allows to choose any clip in Live and the slider will "scrub" it all the way long. It can be fun
The main idea was to use that with a drum clip and to play this clip only with one foot for a human band project. Of course it's fun with melodies too, there is interesting results when the slider is mapped to an LFO wave or random..
Thank you again !
for information the [p everynumber] in this patch was created by Chris Muir and found in this forum, it's a great little utility that never skips a value even if you move a controller very quickly.
... but it does not let you click directly and output only clicked value.
if you click 127 and then 0 , you will get all 128 numbers from 127 - 0 out.
Which might cause trouble if recipient is some heavy loaded stuff.
It won't output number if input unchanged.
So take care when inserting such things in the path.
Yes ! Thank you for your advice. I only use that when the slider is controlled by an hardware knob or pedal when I need to select a precise value of the course which can be skip without that if I move it quickly.
Actually midi input should not drop a single int from a stream.
Only Max GUI objects like sliders or numboxes etc produce drops
when moved by mouse.
Maybe even worse with Live objects ?
Uzi to midi out and back in does not drop a single number.
Not with IAC Bus
And also not with old Motu midi interface
one could build a patch which fills the missing numbers back into the stream.
but i´ve never did that because for what? ;)
if you do it, you will rather do it by an interpolation function over time.
Does this do what you want, in a simpler way?
Voila !
Yes ! I was sure it should have a very easier way to achieve that ! Thank you Nick
The only problem is that the slider is continuously outputting the current data when you move it.
In my case a simple [change] cannot be a solution because I need that each value can be triggered several time even if it doesn't change...
If you decide to use round and change object,
then you need some retrigger option.
A simpe one would be to use inc - dec split to reset change object
whenever Pedal changes direction within same range.
Example :
you use 7 numbers - actually 6 ranges
0 21 42 64 85 106 127
you move pedal from 0 to 28, and so trigger 0 and 21
now every time you change pedal direction and remain between 21 - 41
you will retrigger 21.
because I need that each value can be triggered several time even if it doesn't change...
It's not completely clear to me exactly when you do want the output to change, so I'm guessing a bit - here is a simple solution that triggers every time the value changes and also (re-)triggers each time the pedal hits either end of the its travel;
Thank you again Nick !
almost that ! I was looking for an easier way than the last patch posted to do exactly what your last patch does, but for each value. It's that but every choosen values (number depending of the number) could be triggered like behave the 0 and 127 in your example.
@Source audio
sorry I didn't see your post.
another elegant way!
thank you