So I'm nearing completion of a somewhat large hardware control patch using Vanilla objects only in the most minimal and elegant manner I can come up with. It's mostly done, but there's one specific scaling issue that's holding things up ATM. I've come up with some ideas to solve the problem but those solutions are a bit ungainly and overly complex relative to the way I've coded the rest of the patch. So I'm interested if anyone on here has any better Vanilla-compatible ideas (trying to avoid use of externals here).

The hardware device has a number of parameters which can be accessed either by standard low-resolution midi control (0-127) OR by higher resolution system exclusive control (in one case, 0-164 thou the hi res max values vary between the different parameters being accessed). The patch contains dual sliders so that the parameters in question can be accessed both ways, and these sliders send data to both the receiving device to change the actual value as well as to a [set $1( message which is then connected to the other slider to reflect the updated value. Obviously this slider update value has to be compressed or expanded before being converted to the "set" value. That's not so much of a problem except that it has to replicate the same exact scaling that the hardware device uses or the updated value will be inaccurate relative to the adjusted hardware parameter.

For example, in the case of the 0-164 parameter, the hardware scales this to standard midi by jumping every 4th digit (so it drops 4, 8, 13, 17 etc from the hi res value). What is the simplest and most elegant way to add or subtract from the control range in order to replicate the same scaling in Pd Vanilla?

@NoDSP said:

in the case of the 0-164 parameter, the hardware scales this to standard midi by jumping every 4th digit (so it drops 4, 8, 13, 17 etc from the hi res value).

Just so I understand you, are you trying to build a scaling formula that converts a range of 0-164 into a range of 0-127 by dropping every 4th digit? As opposed to just doing something like this:

Thank you for your response, but yes, been there done that. Not what I'm looking for here. The hardware scaling has to be replicated exactly or the values will not match up, and I need to do it both ways -- compressed from 164 to 127 and expanded from 127 to 164. I also have to do the same with a 150 hi res value but I need to double check which numbers get dropped on that one.

@NoDSP Ok so it sounds like you have figured out the formula as far as how to translate your ranges (i.e. skip every 4th digit etc.) Would typing out the whole list one time into an array or [coll] be too much work? Then you could have your [ctlin]s access this table via [tabread] or go straight into [coll] and have them be translated everytime.

Well, first of all there's no [ctlin] objects involved here, this is just one slider in Pd updating another slider in the same patch.

I haven't used those objects you mentioned yet but I was experimenting with a somewhat similar idea on the compression side of using a [select] object with all the dropped values triggering subtract values to be applied to the [select] "reject" output. I haven't really finished that bit yet because as I said it was getting a bit ungainly and I was really hoping for a more elegant solution. It's just one of those things that seems like it shouldn't be that messy and involved to implement

@NoDSP Why not do it algorithmically?

skipnumber.pd

@NoDSP And for compression, simply search your array for the index at a given value:

Thank You.

The expansion patch works, still a bit more complex than I was going for but it does work. Unfortunately the compression patch has one fatal flaw for my purposes -- [mrpeach] is not a Vanilla object. This is a large patch that was created with the intention of being fully Vanilla compatible and having to load an external just for this doesn't really make sense as I only need this function to scale two sets of variables in a patch that controls well over a hundred that don't need this scaling.

For the heck of it I made a combined version of those two patches in L20rk just to test it out. The expansion side still doesn't quite work -- seems to stop functioning intermittently when moving the 164 slider to the top or bottom of it's range. This may be academic thou as I was really hoping I could solve this problem with a pair of expression objects. It really just shouldn't have to be this complex. I may just try to go back to my [select] idea and see how far I can get with that.

@NoDSP good luck! Let me know what you come up with. Just for the sake of being academic, to acheive vanilla compatible "compression", you could simply make another table and reverse the cords going into [tabread] which will give you a "compression" look up table with indexes from 0-168 with a range of 0-127.

OK I think I've figured this out.

Your efforts were not wasted rjp9, because one way or another they got me thinking while I poked at this problem again. I went back to my initial idea of using [select], the way I was trying to use it before, but then I found the problem and realized why I wasn't getting the results I wanted. The same issue may apply to the your suggestions as well.

Basically, reatime calculation is out on this one. This is because of the tendency for both number and slider objects to jump values instead of outputting a continuous stream. The whole incremental subtraction (or addition) of values won't work if the increments are being skipped over. Some of the values I was getting were going over, under and all over the place.

I'm trying something a bit different now. Still using [select] but now I'm placing the entire input range into [select] and connecting only the values I need to map to hard-coded message boxes to generate the exact values I need on the other end. Tedious, but it should be much more robust and precise once it's done.