# EvilDragon introduces (pt. 7) - Just watch and be amazed!



## EvilDragon (Oct 6, 2010)

This time I am not giving out the secred on how to do this. Just watch and drool! 8) 


http://img571.imageshack.us/img571/2567/spherepower.gif



SPHERE POWER! =o


----------



## Hannes_F (Oct 6, 2010)

Very nice Mario. Is it automateable?


----------



## EvilDragon (Oct 6, 2010)

Yep, why not? :D


----------



## polypx (Oct 6, 2010)

If you've got a switch and a slider occupying the same location, MIDI automation might only be able to be assigned to one of them?

I don't know if that's how you did it. But that's how I'd do it. 

Cool though, 
cheers
Dan


----------



## EvilDragon (Oct 6, 2010)

Works on both parts here, polypx


----------



## RiffWraith (Oct 6, 2010)

That is very cool.

So for your next challenge (I think someone like you enjoys a good challenge  ) is volume and pan.







Whereas the outside of the button (the outermost red part) would be volume, what is now wet/dry would be pan.

And of course, both L & R would be independent of each other.

Cheers.

--edit-- Or maybe the red button could be on/off (mute, or solo, perhaps?) and what is now wet/dry would be volume L/R.


----------



## EvilDragon (Oct 6, 2010)

That's a little bit more tricky. Will look up into it when I get some time. Not sure if separate L/R panners are plausible because Kontakt doesn't have a dual panner?


----------



## EvilDragon (Oct 6, 2010)

Holy crap! Does the middle rim move as well?

o-[][]-o


----------



## EvilDragon (Oct 6, 2010)

Freaking amazing! I have started an avalanche here. :D


----------



## gregjazz (Oct 6, 2010)

Avalanche!! Everybody get off of VI-control immediately!


----------



## Mark Belbin (Oct 6, 2010)

You guys must all be on crack, I swear. >8o 

-M


----------



## snapshot (Oct 6, 2010)

hahahah thats some funky s**t guys :D amazing indeed !


----------



## kotori (Oct 7, 2010)

It would be more useful if one had the option to specify a hit-test mask (or use the png alpha channel for that purpose). As cool as the examples above are, it seems to me that it could be confusing to users that they cannot begin to drag at any point but are limited to one of the edges of the bounding rectangle of the control.


----------



## EvilDragon (Oct 7, 2010)

Still, it saves space. Care for an example of that hit-test mask, Nils?


But I noticed that each reapplying of the script which does this increases the memory usage (ESPECIALLY with bigger images, like I have a 300x300 rim for this library I'm working on) until Kontakt crashes! Even if I turn the undo OFF!!! Seems like a memory leak...

On a positive note, the script would be locked and casual user wouldn't be reapplying it, but still, memory leaks should be fixed, no?


----------



## kotori (Oct 7, 2010)

EvilDragon @ Thu Oct 07 said:


> Still, it saves space. Care for an example of that hit-test mask, Nils?


Yes, if the user is aware of how to handle it it's a nice solution.
By hit-test I mean a function that takes mouse click coordinates as input and returns a boolean value indicating whether the click hit the control or whether it occured outside of it and therefor should be ignored. The current hit-test in Kontakt simply returns true if the coordinate is within the boundsrect of the control, but one could of course envision other types of shapes than a rectangle (a circle in your example). One way to achieve this is to have the hit-test routine return true/false depending on the corresponding pixel value of a bitmap mask.


----------



## David Story (Oct 7, 2010)

Amazing programing! Can you scale the button size so it's easy to find the rim when working fast? Thanks!


----------



## EvilDragon (Oct 7, 2010)

Nils, I can now see what you were talking about:

http://img101.imageshack.us/img101/8534/74056297.jpg

The rims aren't accessible on those parts where the transparent button parts overlap with the sliders...

NI should be aware of this, and since they have already been so nice to introduce proper pixel placement, one would think that z-ordering was a REQUIREMENT to add along that feature, right? Also, transparent parts of the image shouldn't be clickable...


----------



## kotori (Oct 7, 2010)

EvilDragon @ Thu Oct 07 said:


> NI should be aware of this, and since they have already been so nice to introduce proper pixel placement, one would think that z-ordering was a REQUIREMENT to add along that feature, right? Also, transparent parts of the image shouldn't be clickable...



It is possible to control z-order by declaration order but only within the group of the same control type which is a bit limiting.

Anyway, I don't believe transparent parts generally should be non-clickable. In some cases it's quite convenient to use transparent buttons (possibly with a semitransparent hover state). But as an option I agree that it would be nice.


----------



## EvilDragon (Oct 7, 2010)

Exactly "a bit limiting" is not a good thing. I think it's really a lot limiting regarding UI stuff. NI should change this and really give some more thought to KSP.

Yes, additional line in the image text file would work great for making it optional.

My current solution for the above problem is hacky, but works:

http://img825.imageshack.us/img825/8030/hits.gif

Instead of obstructing the slider images with the button, I'd rather sacrifice the clickable area (which is over 80% clickable here anyways, that should do it!). So instead of changing pictures for buttons to show different spaces, I'm doing it with picture state on a label, and 100% transparent resizeable image for all the hit-buttons. Works pretty well!


----------

