EarHax

Is there any way to override the minimum allowable object height in Max for Live? It seems I can't resize anything smaller than a height of 10 in my patch.

For the device I'm making, it would be really ideal if I could size some horizontal rsliders to a height of 5 or 6 instead of 10.

Is there any way to override the minimum allowable object height in Max for Live? It seems I can't resize anything smaller than a height of 10 in my patch. 

Is there any way to override the minimum allowable object height in Max for Live? It seems I can't resize anything smaller than a height of 

override-minimum-object-height-1

- you could put the GUI object into a bpatcher

- you could abuse a waveform~ object as range slider, that will look really great. (to do so you need to fix a whole bunch of settings to waveform, associate it to an emtpy dummy [buffer~] and choose a length in samples such as 0-1000 or 1-10000...)

 - you could put the GUI object into a bpatcher

 - you could abuse a waveform~ object as range slider, that will look really great.    (to do so you need to fix a whole bunch of settings to waveform, associate it to an emtpy dummy [buffer~] and choose a length in samples such as 0-1000 or 1-10000...)


very but dirty solution: if you are going to have a group of rsliders, you could simply place them overlapping each other - and add a panel for the last one.

I will try out the waveform~ object as you describe. However, I am making a Max MIDI device for Live. If I start adding MSP objects to it, do you know if it will still load on a track as a MIDI device?

Unfortunately, for the project I'm working on, each rslider is going to be bound to a different parameter, and I want them each to appear horizontally in a limited amount of space under each live.dial (or other UI). So the overlapping method won't be much use for that, nor would using bpatchers since those also can only be resized to a minimum height of 10.

My main issue here is being able to cram more UI into a small space, and not having it overlap other controls. When I post the finished device, I'll let you know so you can see what I'm talking about. But I don't think it's ready to share yet... still too many loose ends, and a few bugs to fix.

I will try out the waveform~ object as you describe. However, I am making a Max MIDI device for Live. If I start adding MSP objects to it, do you know if it will still load on a track as a MIDI device? 

Bummer. I thought maybe waveform~ would resize smaller than a height of 10, but it looks like that is limited to the same minimum height as the other Max objects.

I wonder if there is some way I could script my own UI for an rslider that would be smaller than a height of 10. I think I either need to do that, or figure out how Native Instruments did the range selection UI for the dial controls in Massive. That would be the best possible implementation: a range selector that wraps around each dial so that it is actually part of the dial (in an abstraction, most likely).

in max 4.x bpatcher and waveform can be 1x1 pixel if you want them to. on mac it is perfect, including pluggo, on windows you must be careful not to size waveform to 0x0 because that crashes max.

are you sure it does not work in max 7? (i cant try right now) maybe it is only a limit for the mouse input and will work by using the "size" message?

that´s right, if it should control the limits of a dial GUI it would be best to include it there.

you should recreate live.dial using lcd, it is relatively easy. then you can either add a second ring around it for the range, or use a modifier key.

the latter might cause trouble in max4live again, says my crystal ball.

you should recreate live.dial using lcd, it is relatively easy. then you can either add a second ring around it for the range, or use a modifier key. 

I will try using the size message. That may override it. I even tried changing it to less than 10 in the inspector attributes, but that didn't work either.

Actually, in looking at the attribute messages for rslider, the size message is used to set the range of the rslider. What I'm looking to do is to set the height of the patching_rect or presentation_rect to $1 $2 50. 5., but the lowest it will go for the height of the UI is 10, which is the same for any Max object as far as I can tell.

I have no idea how to recreate live.dial using lcd. But I am guessing I can probably search and find the info here somewhere, unless you know offhand of a good thread or other resource to recommend to save me the time of googling for it. =)

But yes, the second ring to be used as an rslider with the mouse and key modifier to set the min/max range would be ideal.

Actually, in looking at the attribute messages for rslider, the size message is used to set the range of the rslider. What I'm looking to do is to set the height of the patching_rect or  presentation_rect to $1 $2 50. 5., but the lowest it will go for the height of the UI is 10, which is the same for any Max object as far as I can tell. 

I have no idea how to recreate live.dial using lcd. But I am guessing I can probably search and find the info here somewhere, unless you  know offhand of a good thread or other resource to recommend to save me the time of googling for it. =)

lcd reports mouse up and down, and it also reports mouse drag and mouse move position when you enable that by "idle 1"

a basic circular slider display can be made like that:

"brgb 0 0 0, clear, paintarc 10 10 91 91 190 340 127 127 127, paintarc 10 10 91 91 190 $i1 255 255 255,

at any new parameter value input the whole thing has to be triggered again.

since max 7 you may also use floating point input because/and the drawing is interpolated. but i would still prefer an odd number for the size so that you can determine where the center of the circle is located. even for a rectangle interface element you´d sometimes like to have a center...

the rangeslider is a bit more complicated and you need some geometry to know where the mouse is, but it is doable.

start building it in a second lcd object until it works - then combine the two things. you will have to calculate the angle of the mouse position, which can found by the distance to the center. you will have a gate somewhere, which routes the mouse position to either the inner or the outer slider.

when the GUI stuff works, add the in and out mapping you need for your 3 ableton parameters and put the whole thing in a bpatcher.

1. 
lcd reports mouse  up and down, and it also reports mouse drag and mouse move position when you enable that by "idle 1"

2.
a basic circular slider display can be made like that: 

lcd object of size 101x101,

"brgb 0 0 0, clear, paintarc 10 10 91 91 190 340 127 127 127, paintarc 10 10 91 91 190 $i1 255 255 255,
paintoval 20 20 81 81 0 0 0"

3.
at any new parameter  value input the whole thing has to be triggered again.

4.
since max 7 you may also use floating point input because/and the drawing is interpolated. but i would still prefer an odd number for the size so that you can determine where the center of the circle is located. even for a rectangle interface element you´d sometimes like to have a center...

5.
the rangeslider is a bit more complicated and you need some geometry to know where the mouse is, but it is doable.

start building it in a second lcd object until it works - then combine the two things. you will have to calculate the angle of the mouse position, which can found by the distance to the center. you will have a gate somewhere, which routes the mouse position to either the inner or the outer slider.

6.
when the GUI stuff works, add the in and out mapping you need for your 3 ableton parameters and put the whole thing in a bpatcher.

7.
have phun :)

i assume that you dont really want a circular mousing but just up and down: to change the value, just measure if the mouse´s horizontal value is rising or falling ("delta"), i.e. no matter where you started dragging.

ah. i forgot 3,5:
i assume that you dont really want a circular mousing but just up and down: to change the value, just measure if the mouse´s horizontal value is rising or falling ("delta"), i.e. no matter where you started dragging.

Man, I hope I'm eventually skilled enough with Max to write patches without needing to even open the app like that someday too. I've actually started teaching myself JavaScript as a means to that end, so I suspect I'll get there sooner or later. But like with any programming language, the most difficult part isn't learning the grammar, but the vocabulary.

I definitely appreciate the help with all of this. My project is getting really close to being finished (well, v1.0, at least :)). I can't wait for it to be done so I can finally share it with the community. And this bit will definitely help with the last few parts of it for the range-limited random UI.

$1 or course, not $i1 (or use triggers and pack)

Not quite sure why I would need to use triggers & pack with $i1 but not $1. But I think I'll just take your word for it and go the simpler route of using $1. :)

the way i wrote it (with commas) suggested that it is for a messagebox - which doesnt want the i or f in variables. :)

does it work btw or does it look strange?

Not sure. I haven't gotten to try it yet. I'm at work today. I'll probably be working on it when I get home, though.

Short version: do you know if Live will still let me map to and save/automate lcd UI object (if it has parameter mode capability)? That will be a crucial part of determining if I can make this work properly. For more details, read on.

I'm using pictctrl for my dials now, setting them to ignore click, and centering them in back of/underneath a live.dial that I made transparent so that my UI looks much nicer, yet is still able to be automated in Live (don't know if pictctrl dials can be mapped or saved/automated). So I just need lcd to make the rslider arc that will wrap around the pictctrl dial and live.dial and allow me to set randomization range of the dial using mouse click & drag with a key modifier, and won't need to also use lcd as a dial.

Then again, I'm not sure if it'll work that way, because in order to be able to click and control the live.dial it'll need to be the frontmost object, and it may end up obstructing the lcd object under it that is drawing/controlling the rslider arc/range value output. And I think I need the live.dial on top so it's clickable in order to be able to map it in Live for control by other devices (like an LFO or something), or to one of the macro dials on a Live rack enclosing the device.

On top of that, I still need to figure out how to make the lcd object work like an rslider (visibly, and functionally), so that it draws the arc corresponding to the min-max range it gets set to. I also currently have a setup using 2 live.text buttons to set the min or max range of an rslider based on the current value of a live.dial (for more precisely setting the min & max range for randomization) which I would want to apply to the lcd-based rslider arc as well.

I get the sense that this may end up taking quite a while to figure out, and then may still not solve the problem of conserving space in the UI, if does turn out that the lcd-based rslider arc in a bpatcher underneath the live.dial isn't clickable due to the live.dial being in the way.

I guess the only other option would be to just make a horizontal lcd-based rslider, but only if I can make the LCD object shorter than the minimum height of 10 that the rslider and most (or all) other objects all seem limited to in Max 7, so that it won't end up overlapping other controls the way the rsliders currently are with a minimum object height of 10.

Then again, maybe Live will still work with lcd-based UI objects, and I would still be able to map parameters by clicking/moving the mouse on the LCD object, and Live would still be able to save and automate the MIDI CC parameters they are connected to, just like it does with a live.dial?

I guess I won't know until I get to try all of this out and see if it works, unless maybe you know if the lcd object has parameter mode, and can me mapped and saved/automated in Live like a live.dial can be, which would allow me to eliminate the live.dials from my patch and just use lcd objects instead.

Anyway, hopefully I'll figure it all out quickly, and be able to make it work somehow. Fingers crossed!

Short version: do you know if Live will still let me map to and save/automate lcd UI object (if it has parameter mode capability)? That will be a crucial part of determining if I can make this work properly. For more details, read on.e capability)? That will be a crucial part of determining if I can make this work properly. For more details, read on.

NotNot sure. I haven't gotten to try it yet. I'm at work today. I'll probably be working on it when I get home, though.

However, now that I'm using pictctrl for knobs, setting them to ignore click, and centering them in back of/underneath a live.dial that I made transparent so that my UI looks much nicer, yet is still able to be automated in Live, I just need lcd to make the rslider arc that will wrap around the pictctrl dial and allow me to set randomization range of the dial using the mouse click & drag with a key modifier.

I get the sense that this may end up taking quite a while to figure out, and then may still not solve the problem of conserving space in the UI, if it turns out that the lcd rslider arc in a bpatcher underneath the live.dial isn't clickable due to the live.dial being in the way.

I guess the only other option would be to just make a horizontal lcd-based rslider, but only if I can make the LCD object shorter than the minimum height of 10 that the rslider and most (or all) other objects all seem limited to in Max 7, so that it won't end up overlapping other controls the way the rsliders currently are at an object height of 10.

Just made the lcd with the message you wrote. Works great! Next step is checking to see if it'll work with the live.dial on top of it.

i have been doing this for onthefly patches, standalones and pluggo plug-ins and no, you can not expect to have automatic automation.

rather you would have to use a live object as "THE parameter" and connect it to your custom whatever, where the mouse will be connected directly, the GUi will have to be connected via "set" to the live parameter.

it is not so uncommon to go paths like that, btw. in "real" VST world for example, in the beginning they also started using the GUI objects themselves as parameters - but many people noticed that it is silly and started very soon to have the actualprameter value stored somewhere else, running the knob in parallel.

i have no idea about live devices (yet *hint*) so i dont know if [pp] will till work, you will, however probably use [pattr] (in parameter mode) in most cases because connecting it is very easy (only one connection)

it is a matter of taste... but i would probably just design my custom GUI thing to be able to connect a flonum to it in a feedback loop, then adopt that lonely flonum with a pattr.

knob -> parameter -> aim 
knob -> parameter -> host

host -> parameter -> aim
host -> knob (set without output)

it is a matter of taste... but i would probably just design my custom GUI thing to be able to connect a flonum to it in a feedback loop, then adopt that lonely flonum with a pattr.


... or actually three flonums when you also want the min and max of the range slider to be included in presets and automation, too.

the lcd itself will also output mouse data when in background, but i would avoid using different objects for that same purpose in one control.

circding17.JPG

lcd-circrange.zip

110.ols-2.zip

the tracking is shit, i should have used the real values for the mouse movement.

Awesome! I'll check it out and see if it performs better with real values. Thanks!

Seeing an error: newobj: 110.ols-sub: No such object

110.ols-sub.zip

One last thing - do you know a way to make the background of the LCD transparent? It seems like the only way I could use it with the pictctrl knob I want to use is to create the dial and circular rslider using LCD, then based on distance from the center of it, determine which control is being adjusted using a switch or gate, then route the output from LCD and scale it to the pictctrl dial, my live.dial, and the range-limited randomizer subpatch. But to still be able to see the pictctrl knob with the LCD-based rslider circling around it, I'd need to make the background of the LCD transparent, and center the LCD over the pictctrl knob.

Also, if this isn't possible with LCD, do you know if I could do it with jit.mgraphics?

i know well how you feel about making a ring around something spherical with max GUI objects. no transparancy usualy means you have to waste space. :) 

you have probably a lot of options, but not in the lcd window itself.

i would do it all in lcd here, because a dial is relatively simple to make. for sliders of all kind i often use a pictcontrol on top of lcd, because that at least supports a 2-bit transparancy map (just dont select any background picture source and it is transparent)

what i also sometimes do is to split things across LCDs.

i.e. build one lcd here with the dial and another one there with your range (-slider or -display), and when everything programming works, replace the two lcds with

and now you can easily sum (and modify) the lcd content with jitter objects of your choice and display them in a pwindow.

for the mouse, just put one single lcd behind it - and the whole thing will work 100% as before with the 2 separated lcds.

what i dont do is using sprites. check the helpfile and see if you like that.

you can add various things made of picture files right inside lcd with sprites. you will be able to move them, exchange sources, stretch them, and sprites even support some basic copy modes.

i am not using it because of initialisation problems when loading picture files on slower systems.

looking forward to do the final quality control when you´re done!

  i know well how you feel about making a ring around something spherical with max GUI objects. no transparancy usualy means you have to waste space. :) 

you have probably a lot of options, but not in the lcd window itself.

i.e. build one lcd here with the dial and another one there with your range  (-slider or -display), and when everything programming works, replace the two lcds with

t b l
jit.lcd

and now you can easily sum (and modify) the lcd content with jitter objects of your choice and display them in a pwindow.

...

what i dont do is using sprites. check the helpfile and see if  you like that.

you can add various things made of picture files right inside lcd with sprites. you will be able to move them, exchange sources, stretch them, and sprites even support some basic copy modes.

looking forward to do the final quality control when you´re done!


Huzzah! I can't believe I didn't notice this sooner. There is a "transparent background" checkbox in the LCD inspector properties. Checking that makes it possible to overlay the LCD on top of my other UI elements, and still have them be visible. Problem solved!

Well, mostly. I'm still having issues getting the min & max for the LCD range setting to be clipped to the range of the dial's UI, and to clear properly before drawing the arc again and seeing it connect to the last drawn points. Maybe you can shed some light on this. If only I could figure out how to offset the cartopol output so that angle 0 was at 12 o'clock instead of 3 o'clock. Too tired to figure it out right now.

Just realized I wrote in a comment to click/drag "horizontally," when it should have been "vertically".

Almost have this finished now. Just figuring out how to limit the drawing of the arc to the extent of the dial, and drawing differently based on key modifiers the same as rslider.

be careful with all things "transparent background". and dont worry, nobody knows the difference between vertical and horizontal anyway.

Okay so I've been crazy busy at work lately, but I've been burning the midnight oil and made some progress on this.

I now have LCD set up to paint a framearc extending outwards around a dial using the angle of the click from the center of the LCD as the starting point. I wanted to do it this way as it fits my workflow best (dial a control in, estimate the range I want it to have for random, and drag the range out from that current setting).

I also have the idle mouse position split based on the location of the arc so that it'll output differently and not draw it when clicking & dragging inside of the arc drawing radius, and can send the mouse y data from those clicks out to my live.dial.

I just need to figure out the following issues now:

-how to best get the value of the live.dial before setting it when outputting y mouse movement to it, and scale the y mouse movement value so that, rather than jump to the new value based on mouse Y position, it will just increase/decrease the current value of the live.dial

-how to best prevent framearc drawing from wrapping past the 0 and 10 positions of the dial limits (in vertical mode), or wrapping past 360°, clearing the arc, and starting to draw again from the point where it closed a circle

-how to poll the modifier object (at the correct time) only when the mouse is clicked to see if a modifier is being held on the click (planning to use ⌘)

-minor stuff like scaling the output of the drawn framearc range to the dial range for randomizing (probably use rawfloat to keep it universal/simple)

-potentially using jit.pwindow instead of lcd or jit.lcd, and displaying a rotating dial image either as frames in a mov file (128 frames, one for each dial value/position) in addition to the framearc being drawn, so that everything is in one object, and I can include an image-based dial

-how to clip or scale the output of mouse data from lcd so that when I hit the limits of the dial I don't need to move the mouse back past the value of the limit of the dial to get the dial to adjust, but as soon as I start moving in the other direction, the dial will too (basically, thinking I'll need to change the scaling of the output of mouse y value on the fly once the dial limit is hit).

-lastly, sometimes the lcd will flicker when drawing the arc, not sure why, but need to figure that out and prevent it

There may be more than this left to do. But this is what I'm working on now. I figured I would share to the forum to see if I could get any more helpful tips to speed me up along the way. :)

Okay so I've been crazy busy at work lately, but I've been burning the midnight oil and made some progress on this.

I now have LCD set up to paint a framearc extending outwards around a dial using the angle of the click from the center of the LCD as the starting point. I wanted to do it this way as it fits my workflow best (dial a control in, estimate the range I want it to have for random, and drag the range out from that current setting).

I also have the idle mouse position split based on the location of the arc so that it'll output differently and not draw it when clicking & dragging inside of the arc drawing radius, and can send the mouse y data from those clicks out to my live.dial.

I just need to figure out the following issues now:

-how to best get the value of the live.dial before setting it when outputting y mouse movement to it, and scale the y mouse movement value so that, rather than jump to the new value based on mouse Y position, it will just increase/decrease the current value of the live.dial
-how to best prevent framearc drawing from wrapping past the 0 and 10 positions of the dial limits (in vertical mode), or wrapping past 360°, clearing the arc, and starting to draw again from the point where it closed a circle
-how to poll the modifier object (at the correct time) only when the mouse is clicked to see if a modifier is being held on the click (planning to use ⌘)
-minor stuff like scaling the output of the drawn framearc range to the dial range for randomizing (probably use rawfloat to keep it universal/simple)
-potentially using jit.pwindow instead of lcd or jit.lcd, and displaying a rotating dial image either as frames in a mov file (128 frames, one for each dial value/position) in addition to the framearc being drawn, so that everything is in one object, and I can include an image-based dial
-how to clip or scale the output of mouse data from lcd so that when I hit the limits of the dial I don't need to move the mouse back past the value of the limit of the dial to get the dial to adjust, but as soon as I start moving in the other direction, the dial will too (basically, thinking I'll need to change the scaling of the output of mouse y value on the fly once the dial limit is hit).
-lastly, sometimes the lcd will flicker when drawing the arc, not sure why, but need to figure that out and prevent it

There may be more than this left to do. But this is what I'm working on now. I figured I would share to the forum to see if I could get any more helpful tips to speed me up along the way. :)

1. honestly, if you want to have full control over the math to make a dial which can be acumlated to with the mpouse, i wouldnt use something like live.dial at all, which is very specific already, and most people dont even get it to work for what it was made for.

2. that really depends. from what i see here, limiting the relative mouse output using min and max should already be enough, no?

3. with lcd mouse out ot is tricky. but you could basically make an "⌘-gate" abstraction which only lets data through when the modifier is pressed or something in that direction.

4. yes scale everything in your life into a range of 0. 1. then everything is compatible which each other. i´ve done that with my coffee pot and now it is compatible with the cat!

6. are you sure you have already made the final decision of the design? if you create your own stuff you should see that it is better than the usual range slider, isnt it? while keeping the GUI as much as "following the guidelines" as possible. 

i find your method, where i have to click in the middle and then it extends the min and max when i move the mouse away from the center of the circle very strange. in an ideal case i would like to 1. set min and max by dragging, 2. move the range linearily up and down by holding a modifier. 

7. that might become better when you switch to jit-.lcd and/or replace the live object with lcd.

1. honestly, if you want to have full control over the math to make a dial which can be acumlated to with the mpouse, i wouldnt use something like live.dial at all, which is very specific already, and most people dont even get it to work for what it was made for.

2. that really depends. from what i see here, limiting the relative mouse output using min and max should already be enough, no?


3. with lcd mouse out ot is tricky. but you could basically make an "⌘-gate" abstraction which only lets data through when the modifier is pressed or something in that direction.


4. yes scale everything in your life into a range of 0. 1. then everything is compatible which each other. i´ve done that with my coffee pot and now it is compatible with the cat!


5. hrm.

6. are you sure you have already made the final decision of the design? if you create your own stuff you should see that it is better than the usual range slider, isnt it? while keeping the GUI as much as "following the guidelines" as possible. 
i find your method, where i have to click in the middle and then it extends the min and max when i move the mouse away from the center of the circle very strange. in an ideal case i would like to 1. set min and max by dragging, 2. move the range linearily up and down by holding a modifier. 
everything else is optional.

7. that might become better when you switch to jit-.lcd and/or replace the live object with lcd.

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 :)

i see you already understood rule number one.

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.

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.

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. :)

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)

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.

damn, i just noticed something very ugly.

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

lcd-issue.png

lcd-issue7.png

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.

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

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...

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

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.

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

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


Override minimum object height?