Override minimum object height?

Yeah, I guess it is a lot. I supoose this is a pretty ambitious undertaking for someone at my level of programming & Max experience. But instead of setting reasonable goals, I have always been one to bite off more than I can chew, choke, spit up, then learn from it and do better the next time. :)

1. Is there another UI object that, within Live, can be automated, saved, and mapped to by other Max for Live devices (like LFOs, envelope followers, etc.) that you would suggest I use instead of a live.dial?

2. "limiting the relative mouse output using min and max" - does that limit the range of values that LCD will actually output from mouse y movement? If so, I'm not sure how to set that. AFAIK, the y value is based on relative pixel distances. So I just figured if you move too far, the value keeps going up until you move back far enough to start lowering it.

3. Yeah, I was thinking of checking the mouse clicked output using change, then triggering modifier, and collecting both the mouse click state and the modifier state before ungating output from the mouse xy outlet. But do you know which device would be best to use to do something like only opening a gate when a & b (or a, b, c... etc.) are all true/matching a condition at the same time?

4. Hahaha. Cats do go well with coffee. ;)

5. Yeah. I thought that might be pretty clever (if I can make it work). :)

6. Yes, but the design won't *only* allow drawing the range as I have it now. That's just the 'one-click-one-drag' method to set a range around a specific point very quickly on the fly. I also plan to use modifiers to do the other things you mentioned the same way as rslider. But I want my "xslider" to also do something rslider *doesn't* do. ;)

And since I plan on making all of my abstractions available separately for anyone else who might want to use them without having to dig through my patch to grab stuff they want, I figured just making a "rotary/semicircular rslider" wouldn't be enough of an achievment on its own. :)

7. I actually have another version of the patch I uploaded here where I did the same setup using jit.lcd, and I noticed it flickers too. And right now I notice it does it even when the LCD isn't outputting to anything else. So maybe its some kind of screen refresh/sync issue? Also, could it be due to using framearc and having it clear & redraw with every pixel of mouse movement instead of paintarc? I really wish there was some way to still use paintarc, but then instead of paintoval to black out the middle, use something else that will erase a circle in the middle. Maybe there is a way to just clear a certain area of the lcd, and do that in the shape of a circle?

Eventually I need to figure out how to do this stuff using vectors instead of pixels. I have a pet peeve for anti-aliasing in UI design, since I like to keep everything scalable, allowing for a condensed overview using a minimal amount of screen real estate, while also allowing the user to zoom in to adjust stuff as needed rather than needing to use tabs/menus/pages/windows/etc. But I know dealing with vector drawing involves a lot more math, and I'm not quite ready to dive that deep just yet. After all, this will only be the first M4L device I release [original/not a mod of an existing one]. I have to leave some room for growth/improvement :)

But instead of setting reasonable goals, I have always been one to bite off more than I can chew, choke, spit up, then learn from it and do better the next time. :)

i see you already understood rule number one.

1.
i would use lcd if i needed to mix and combine it with more lcd. otherwise picturecontrol is a bit more basic and better to control than live objects.

2.
clipping the range of mouse data is one of the most frequent jobs when writing something in lcd / jsui /jitter (and some other things outside max)

the simplest case is a slider. if you dont do "clip 0 100" inside a slider object, you might not be able to make it output 0 at all when you move the mouse fast across the left border. try it with am emtpy lcd object and you see what i mean.

it is exactly what the compiled max GUI objects also do inside.

3.
mixing and summing conditions is always a bit confusing. the term to search for is "logig gate".
one typical strategy is to use a mixture between bools and arithmetic.
step 1: check if each of the conditions are true with a comparison operator > < ==
step 2: now you have a bunch of 0s and 1s, which you can multiply or add with each other. multiplying them does the "OR" jobs, adding them prepeares the "AND" jobs.
of course you can also use arithmentics for the conditions and bools for the second line. just dont use gate objects and routing when plain math would also work. math can often be combined in bigger branches. :)

6. okay i see, this is your preferred method but you might also want or accept others.
well, on the GUI drawing side it is always the same! that is why you distinguish between control and drawing - and code the drawing first.

7. it might be a refresh issue. i seldom see it in max 6 / 7 as i mostly use v4 - where flickering is far worse.

no, the mouse data and the fact that youre drawing a simple figure should not make it flicker. that will run smooth on a 100Mhz computer with built-in graphics.
eventually try if that unwanted effect goes away when you put a black panel behind the LCD.

Maybe there is a way to just clear a certain area of the lcd, and do that in the shape of a circle?

with jit.lcd you could cut out round parts of a matrix, but IMO this makes things only complicated. as a workaround for emergeny cases, yes, but otherwise stay with old-school lcd.

if you really need this slider you are going to make here in many different sizes it might be better to do it with jsui or video objects and use vector graphics.
otoh, you should never forget that you eventually might want to have 50 these sliders following parameter automation one day. quickdraw is the second best here, video and 3d stuff or java and javascript are very hungry compared to a few messages to lcd.

saving screen space is fine, but readabilty sometimes requires graphics to sit comfy in 800% free space. so before you code assembler for a week, you better have made a tracing image with 3 examples knobs in photoshop before. :)

damn, i just noticed something very ugly.

that will brake some of my old patches i am afraid.

this really pisses my on. perfect example why i dont upgrade

Excellently helpful info as always, Roman. Thanks again!

And yuck. Not sure why that is happening, but it looks like the drawing direction from the origin angle is opposite from what it used to be. And I have the same philosophy on upgrades. I hesitate to do it unless I need to in order to fix something, and even then I will only do so if the fix is specifically included in the updated version. The whole idea that customer support people suggest upgrading to the latest version to fix a problem as a first response is irritating, as they assume all ills are fixed by upgrading (which, in my experience, has rarely been the case).

I know I will want to use pictctrl for knobs anyway, since as you said, jit.pwindow with video or vector calculations would be a lot more costly for this use case, as I will have dozens of these controls in my device. Hopefully it is still capable of doing everything I'm using live.dial to do in other areas of my patch. And if it can still be mapped & automated in Live, I can probably eliminate the use of live.dial.

As for clipping the range of mouse data, I'll have to get more info if you're saying this can be done within the LCD object itself to make it send relative mouse data when reversing direction past the clip values. Maybe it's as simple as setting a min & max value for mouse xy output range via arguments to lcd?

Basically, I was using a clip outside of LCD, but since the y coordinate value LCD is outputting will keep incrementing past the clip min/max, e.g. moving the mouse y from 0 to 200 pixels, with [clip] max at 100, I think I would still run into the issue of needing to bring the mouse back down 100 pixels before the value of the dial would decrement, moving from y 200 back to 100 to be within the clip window before [clip] output would decrement the dial's value below the max value.

But in that regard, clip seems superfluous, since I think the live.dial (& others) have an internal clip at min and max value.

So when using a dial normally, if you move the mouse up vertically until it hits its max value, and keep going up, when you change direction and start moving down, the dial will start to decrement right away without needing to go past the mouse location where you hit the max on the dial. That's what I'm trying to get from the LCD output. Maybe there's some object that will just convert the mouse y value into an inc/dec value so that, regardless of the actual y value, all that matters is direction of movement, which can then be converted to set the value of the dial?

The only way I can think of to do it would be to adjust the min & max value of a [scale] based on the current value of the target control (live.dial or other) so that changing direction from inc. to dec. (or vice versa) at any point will immediately change the control value in the other direction. I guess technically it would be a sliding scale.

But with that, if the dial is already at its max, then the [scale] max would start at the starting y value (b), and min would be b-127. Moving the mouse/y value up would increase the [scale] max and min from there. If the dial was at min value (a), then [scale] max value would be a+127, and min would be the y starting value.

Using current rawfloat value from live.dial at mouse clicked on lcd, I could set the [scale] min/max using: [- 0.]_[* 128]_[scale (in min)] and [!- 1.]_[* 128]_[scale (in max)]

Then, take the mouse y value from lcd, and when it passes that many pixels in either direction (min or max), it will begin to shift the scale min/max as it continues past the scale input range limits instead of hitting the scale input. Then as soon as the direction of y movement changes, the switch would send that value through the scale out to the dial, until the other range limit was hit, and it started adjusting the scale input range again.

I don't know. It seems like there should be some easier way of doing this in max - adjusting control range limits on the fly. But maybe not?

I figured I was on the right track for the logic gate stuff for modifier-based control changes. Just thought you might know an easier way. Good to have confirmation though. :)

Maybe the flickering is a result of the "transparent background" setting? Idk. I will have to play around more and see.

And yes, I definitely understand about not "putting the cart before the horse." :) I figure once I get the drawing part working, before I do any of the control stuff, I'll probably try mapping 50 instances to [random]_[line 100] and run them all from a [metro 100] and see how it performs. Then I'll probably take a break and make some music. And then I'll probably be able to do the control stuff, then integrate into my already-(almost)finished patch & UI, and hope it all works smoothly and nothing crashes.

if you're saying this can be done within the LCD object itself to make it send relative mouse data when reversing direction past the clip values

you can simply run 2 streams of mouse data in parallel, clipping the absolute data and using the other one to get direction changes.

sorry that you couldnt see my rangeslider example from above since your max 7 has the counterclockwise virus. ^

i was looking like 10 minutes or so into it now but i dont get how i can easily fix it in a way that will be generic enough to adapt my own work to it.

i guess that if i dont find a nice way to synchronize old and new runtime versions of circular pixel collections, that i will sooner or later have to switch to [jit.mgraphics] for everything "arc". (unless it has the direction change issue too or doesnt exist for max4^^)

luckily my transition from lcd to jit.lcd has in fact not yet really started...

Then as soon as the direction of y movement changes

and then this and than that and in theory it is all easy. but then when you think it should wokr now you will find out that you forgot the situation "user moves in again, then relases the mouse and performs another gesture from out to in" and then you can start all over :D

It seems like there should be some easier way of doing this in max - adjusting control range limits on the fly. But maybe not?

what i often had in the beginning is that you need a different clipping, scaling or whatever for mouse up and mouse down situations. more than 3 levels of logic stuff at the same time often leads into loud screaming.

lol, i dont understand why my slider works but the rangeslider not.

Well, this is unbelievably annoying. I'm on the latest Chrome browser, just cleared all cache and cookies, relaunched it, and yet still, anytime I click in a reply box anywhere in this forum, the page scrolls to the very top - not just the first time I click in it either, but ANY time I do. So trying to select/edit something I'm typing, and BAM! I'm at the top of the page again. And just now I realized selecting text using the keyboard and doing a cut with cmd+x also causes this. Ugh.

Anyway, yeah, if there is anything I've learned it's that you can never predict how other people will do things that you would never have expected, and often things that make no sense whatsoever. But hopefully, this is the smaller percentage of users when you release something. :)

Hopefully they sort out this lcd drawing direction issue at c74. I would write to them about it either way. Pretty annoying incompatibility issue. Of course, since they slapped the "DEPRECATED" label on it, I guess they don't have to maintain lcd anymore. :P But if it also happens in jit.lcd, I'm betting they would want to know.

I'll take another look at the patch you shared for the dual-streams of mouse data. If I can't figure out where you did that, or just figure out how to get it working on my own, I'm sure you'll hear from me about it soon. :)

Hey check it out! I switched the wiring around on the middle example from your patch, and now it seems to work okay. I wonder if this might resolve the weird counter-clockwise paintarc issue you are experiencing too, or if that is caused by something else.

Well, that was almost okay. But after loading the patch, if you set the flonum on the right first, it starts drawing from 0 instead of 190, and will wrap around the bottom, but will pop into the right position when you enter the left/min flonum. And by default, I would want the range to be set from 0-1 (full range) anyway, so...

Also, I'm guessing the reason you sometimes don't get down to a 0 value for x from the mouse movement if you move left off of the lcd too fast is the mouse polling rate. Causes gaps in pen drawing too. Again, wondering if this might be cleared up with jit.lcd