adding drag and drop routing to a max patch
Hi all, if any of you have ever used NI Massive you'll know how great drag and drop routing can be! Just wondering if there's anyway of doing this in Max 5? Basically I would like to have one dial and be able to drag a variety of parameters onto that dial and control them, clear them, then drag a whole new set onto the dial ad infinitum. I know there are other ways to do this but I'd really like to implement drag and drop. Cheers!
i dont think thats possible..
at least not with max and its objects.
maybe with some java scripting and bits of jitter... i dont know.
seems like a dumb idea but maybe you could try to stretch an x-y pad all over the interface.. send it to the background and then work with its coordinates..
if x = 120 and y = 80 then open a gate so lfo gets through to the filter.
this way you could have one drag and drop routing...
the x-y pad is in the [pictslider] helpfile, i think.
maybe you can even layer them... iam not sure if you can then control them seperatly...
almost forgot...
massive is the bomb.
Drag and drop support would be awesome!
There is already some drag and drop implementation (dropfile), but this works for dropping files only (hence the name). I would welcome a more extensive drag 'n drop implementation!
bpatchers are your friend.
name this ddd
name this whatever
NOTE!!!!
You can just erase the dial in the ddd.maxpat and you have a generic drag and drop thing to lay over any interface element you want.
If you guys are interested, I could put together a script that would take the bpatcher's dimensions into account. right now they are hardcoded as 40x40
Thanks for this tip, AudioMatt, it works great. You just forgot to add that dd.maxpat should be set to automatically open in presentation mode. The only thing that lacks is a modification of the mouse cursor icon/color when the user drags and drop, but as far as I know, it's kind of impossible with max.
alexis
Thanks.
Dang! Copy compressed doesn't copy presentation mode.
As for the cursor, this used to be possible in max 4.x with externals. There are other ways of notifying your users about that activity.
The point is that there a lot of things you can do in max even though there's no blatant predefined code for them. I hear this a lot from Cycling on this board in response to feature requests... "Don't ask me to code it. Just do it yourself!"
"I hear this a lot from Cycling on this board in response to feature requests... 'Don't ask me to code it. Just do it yourself!'"
Although i'm a new poster, been a reader a very long time, and i've never seen cycling devs use anything like this wording(prove me wrong, though: if you have a link to a specific thread where they said that... i will then think that the devs do not do enough to moderate themselves, but i can't find anything like that)... could it be that you interpreted whatever was said into these words because that's what you, yourself were expecting to hear once you realized you could already do it yourself?
(i have a slight qualm with misquotes... so many misunderstandings happen that way, if you meant that the wording is a basic gist of what they said, then just be careful not to put it in quotes... that's all i'm saying...)
great patch, though! with max, i care more about the basic functionality implemented rather than some extraneous UI perks... i think the patch provides exactly what was needed.
I didn't mean to say that anything the cycling staff has ever said was mean spirited. I just feel a lot of feature request responses come in the form of patches. The one specific one I can call up in my head was where that guy built a dock in max 4.6 that emulated the tool bar and everyone freaked out at how cool it was. In a way, toolbox was like that too. No one thought that sort of thing was possible and we all kept making silly requests. Now when I make a suggestion, it's for either max as IDE or something systemic.
In short, I've been shown time and time again that things I think are limitations are actually things that need to be built.
"I just feel a lot of feature request responses come in the form of patches.... In short, I've been shown time and time again that things I think are limitations are actually things that need to be built."
Well put.
ya, that archive is even better! it handles the UI problem of cursor-changes: all you need is some graphic telling you from where and to where and for it to change as you drag so that you know it's happening and in what direction(doesn't necessarily need to be a mouse/cursor change). this does all that perfectly. Thanks for sharing!
Here's another version using [hover] and [mousestate]. Was trickier than I thought. It's not perfect (what patch ever is?) but the functionality is there. Would need to work out a few details like auto-returning the draggable objects to their original position, and deal with the highlighting. But for a basic example it works, with any scripting-name object.
Because [hover] only works with interactive objects, and you don't really want them to interact except for dragging, I used [textbuttons] that don't change color when you click or hover over them (though of course you could).
From doing this, and seeing that it was a bit tricky, it would be great to have some draggable functionality built-in. Not sure to what extent (maybe a "draggable" attribute on any object is overkill) but possibly have an object which could be dragged in this way, just a picture file with transparency. That would be a nice first step, to have the objects manage the dragging for you, and have the option to snap back to its previous location upon release. Also having a second image show up when clicked and/or hovered over would be nice, to highlight the interaction. Sort of like the Up, Over, Down states in Flash.
The second step would be a new object, maybe called "collision_detect", which takes two scripting names of objects as arguments and sends out a 1 or 0 if their patching_rect and/or presentation_rect attributes overlap. Even further would be a general collision_detect object, which sends out the names and positions of any overlapping named objects, even if there are more than two at once. It would send out just the latest names when a new overlap/collision occurs, and could have a "dump" message to send all sets of currently-overlapping objects as a grouped list, with coordinates of each object's left/top/right/bottom.
Anyway... just a few thoughts. I remember having "draggable" as an option when using Director back in the day, and made some good use of it, as it was so easy to add. And of course, having these new objects would provide a lot of options for game-like patches, without digging into separate libraries or fiddling with [mousestate] and gates etc...
Thanks for the inventive solutions guys - You both rock!
this might be helpful to someone. The button on the right you can click and drag to the fpic on the left and an fpic will follow the mouse. When u release it knows where it was released and so this could be used to drag and drop between fields. I'm testing this to see if I could drag and drop midi sysex presets.
with [mousestate], [lcd], and similar objects you can build all kind of "drag" mechanisms.
i just wouldnt count on them to work in bpatchers, too.
-110
Hey guys would this work with live?