dial is active?
Is it possible to determine when a dial is active (ie, is currently being turned) or inactive (ie, is not being turned)? I want something to be triggered when the dial starts being turned, and then again when it stops being turned. Any advice most appreciated.
Does this work for you?
It should technically be possible to make circular dials work like this too, but someone better than me would have to figure out the math behind making the LCD output the correct values.
I would do something like that :
Ch.
Thank you both for your responses, but I'm obviously a total newbie because even though I copy the text from the forum posts, the "paste" command is not available in Max 5, and if I choose "New from clipboard" it simply pastes the text itself as text, not as a patcher or object. What am I doing wrong?
From the sticky:
"Opening patches posted to the forum
Max can create objects from text on the clipboard in the old Max 4 text format, the Max 5 format, or the compressed format.
Because there may be a lot of text involved in the patcher data, the easiest technique for selecting all of the data is select a line at the beginning of the text, then scroll to the end of the message and Shift-click to select the end of the text.
Once all of the text is selected, choose Copy from the Edit menu in your browser. If you are manually selecting all the data, be sure to include the begin_max5_patcher and end_max5_patcher lines in their entirety.
Switch to Max. If you want to create a new patcher window with the patcher data you've received, choose New From Clipboard from the File menu. A new patcher window will appear with the objects from the forum post.
If you want to paste the objects in the forum post into an existing unlocked patcher, choose Paste from the Edit menu."
Here's a method that can tell you when the output of the [dial] is changing rather than just when the mouse is released. It triggers a 1 when movement starts and a 0 when the mouse is released. It also outputs a 0 if no movement data is received in the time specified in the number box.
lh
(Doh, I forgot to include the "begin" and "end" blocks when I copied.)
Thanks very much for both these example patches - the mousefilter is definitely the kind of functionality I was after, but I was hoping there was a similar functionality built in to (or able to be tacked on to) the dial itself, since ultimately it will be controlled by an actual physical dial, not a mouse.
In the meantime, I can build the software model using mousefilter, and hope I can emulate that behaviour later on when using a physical dial.
Thanks again for the help (and patience with my irritating newbie problem), most appreciated!
This will work with a physical dial input. I've thrown in some [change] coolness as well.
Well, wait. Is the physical dial similar to the ones found on the protools ICON boards, where they are actually touch-sensitive? If that's the case then it's just a matter of figuring out how to pick up the touch sensor output from within max.
Thankyou Timlloyd, this works perfectly.Analysing the patch, am I right in saying that basically the uzi is firing 100 '1's to the toggle for every message it receives from the dial, which prevents the '0' from being noticed until 200ms after the last message from the dial?
The physical dials will be plain vanilla potentiometers, without touch-senisitivity.
Yes, the uzi will fire 100 bang messages as fast as possible for each bang in its input, preventing the [t 0] from turning off the toggle.
Not 100% sure if it's necessary, the patch will probably work just as well if you replace the [t b b] with a [t b 1] (connected straight into the toggle), its just the way I happened to do it. But I suspect that using uzi will make it more reliable.
Another thing you might find useful is giving each dial a mouse-over function, for example a toggle is turned on whenever the mouse is over the dial, and off when it's not. Could be used to distinguish between mouse-control or hardware-control of the dial .
You could do this easily by giving each dial a unique scripting name (using the inspector) and using the [hover] object. It will work using hover, sel and trigger. Remember that sel can select messages as well as ints and floats.
IF you don't get it working I'll post an example.
I had an example ready to post, but for some reason any vigorous movement on my MIDI keyboard controls crashes max........very odd.....I think I need to check that my search path is all in order. hmm
The [uzi] isn't really needed. See the patch I posted above, it is very similar and will do the job for mouse input or not. Be careful of overloading [ctlin], it's a bit buggy. Using [midiin] and [midiparse] is better and might stop the crashes you're getting.
lh
You're right, the uzi isn't needed. I just tried your patch though and with the control change value from midiparse connected to the dial the toggle flickers rather than staying on.
Also just managed to crash max again by using midiin > midiparse with vigorous midi input.
It may be a bug with my keyboard or with max, not sure how to find out.
I've been having issues with max for a few days though, It is really unresponsive for a few minutes after startup, and I keep getting the harvesting metadata load-screen nearly every time I start up. I made a thread about it hoping someone could tell me why it might be happening, but It must be to do with the search path. I may have some duplicates of things in different locations that are confusing max....gotta fix that
Try increasing the [delay] time until it reaches a level you're happy with. With regards to general max problems try quitting and then trashing your preferences, that seems to sort out most little problems although it could be something else entirely.
lh
Ah, okay, thanks lh, I didn't realise your example worked independently of the mousefilter. Thank you very much for this, it is very instructive, especially as I am very new to MAX/MSP, I am learning a lot from these examples. Thanks again all, I really appreciate your time.
Its entirely possible that I'm being really stupid (need some sleep) but I still can't get your mousefilter example to work without being mouse-controlled.
With a metro at 10ms counting between values 20 and 100 of the dial or with midi input, the toggle still flickers and prints alternating 0 and 1 regardless of the delay time.
Cheers Tim, you're absolutely right, my bad. Remove the [mousefilter] and use the simple delay technique for non-mouse controlled objects. I didn't test it with any other form of input. However if you do want to use this method with a mouse then its A-OK!
lh
Its actually really odd that the mousefilter stops the previous 1 and bang message from working properly.
It doesn't really make sense to me that it doesn't work.
edit - actually does make sense to me now - mouse button is up when using metro+counter or midi therefore letting the values through constantly.
Hmm, not sure I understand - I've completely removed the mousefilter from this patch and it still works perfectly. Mind you, I'm still using the mouse to control the dial. Are you saying that it wouldn't work if I controlled the dial with, for example, a pot on my midi keyboard?
It's because when the mouse button is up, such as when using MIDI rather than clicking on the dial, the mousefilter lets the values through constantly, and each of those values triggers the [t 0] object really quickly, turning off the toggle and making it flicker.
It will work with midi, as long as you don't use mousefilter, because it is using only the output of the dial to turn the toggle on and off, not relying on anything else, if that makes sense.