smawil

I'm working on an autotuner that only shifts to certain ratios from the root frequency defined in a list. I've worked out the math to select ratios I want and build a list from their multiples and divisors, so I have a long list of available ratios.

where I'm stuck somewhat is figuring out how to deal with this long list in an efficient way to determine which ratio to shift to. I've attached the portion of the patch that given two consecutive ratios from the list and the ratio of the input (determined by pitch~ and division by the root frequency) can determine which of the two to shift to. but for a list that could be up to a few hundred items long, breaking down the list into pairs and repeating this code for each pair seems tedious and probably ultimately not suited to a variable length list.

is there some way I can reference consecutive pairs in a list in an abstract way (without programming $f1 $f2 $f3 $f4 etc.) in vexpr? or am I leading myself towards an unnecessarily complicated solution with what I've got so far?

efficient-list-processing-for-pairs-in-long-list

this patch quantises the input to an arbitrary list of numbers (ascending order)

is this what you want?
this patch quantises the input to an arbitrary list of numbers (ascending order)


i think this is s better version-- it compares the mean of the logs of two adjacent ratios, rather than the mean of the ratios themselves

thanks a lot -- this second version is a lot clearer even if i don't understand all the math yet. before your response i went through the tedious business of unpacking the long list into pairs and then individually running these through my math bit. while this worked, it mostly pointed to some other larger issues with my patch. your solution is a lot more elegant of course and is going to make these further refinements a lot less tedious.

at this point in learning max the major business seems to be figuring out how to avoid long tedious patching processes. which sometimes ends up being tedious itself, ha ha.

thanks a lot -- this second version is a lot clearer even if i don't understand all the math yet. before your response i went through the tedious business of unpacking the long list into pairs and then individually running these through my math bit. while this worked, it mostly pointed to some other larger issues with my patch. your solution is a lot more elegant of course and is going to make these further refinements a lot less tedious.
at this point in learning max the major business seems to be figuring out how to avoid long tedious patching processes. which sometimes ends up being tedious itself, ha ha.
thanks again terry.


another way (much simpler, with adjustable precision, but w/o avg):

in answer to your question about learning max without going up a 'tedious patching' path, i guess if a method starts to get repetitive and tedious, it usually indicates there is a better way to do it, but the only way i know is to get to know as many objects as possible, and study other people's patches. from andrzej's example you can see there is _always_ more than one way of figuring out a solution. if it's not too pressing, you can leave the problem for a an hour or so (or a day or so) and try to get back to it with a different approach-- there's a certain amount of intuition involved in working out solutions in any kind of (programming) problem; perhaps more so in max...

in answer to your question about learning max without  going up a 'tedious patching' path, i guess if a method starts to get repetitive and tedious, it usually indicates there is a better way to do it, but the only way i know is to get to know as many objects as possible, and study other people's patches.  from andrzej's example you can see there is _always_ more than one way of figuring out a solution. if it's not too pressing, you can leave the problem for a an hour or so (or a day or so) and try to get back to it with a different approach-- there's a certain amount of intuition involved in working out solutions in any kind of (programming) problem; perhaps more so in max...


andrzej, can you explain the adjustable precision in your patch? it doesn't seem to 'round up' for me.

for example if my list contains '.8 and 1.', even with an input of .99 my final output is still .8 .

in terry's patch, any input > .9 will quantize to 1.

andrzej, can you explain the adjustable precision in your patch? it doesn't seem to 'round up' for me.
for example if my list contains '.8 and 1.', even with an input of .99 my final output is still .8 .
in terry's patch, any input > .9 will quantize to 1.

efficient list processing for pairs in long list