More 'z' variables please . . .

[Macciza]

Hi
Still not really sure what you mean . . .

Though I now suspect maybe part of your problem may have been having 'Capture' enabled, which means Touches are 'captured' by a Pad even when the finger leaves if it does not lift up . .

Try switching Capture off this lets you seamlessly slide from one pad to another activating them as you go . . .
This would have been the normal action if you had used an array of Pads instead of separate Pads . . .

Anyway - Lemur 4 adds z variable on Range, MultiSlider, Knob and RingArea objects

Cheers
MM

[Traxus]

Anyway - Lemur 4 adds z variable on Range, MultiSlider, Knob and RingArea objects

I would argue that knob is far huger than anything else, as it will let us use endless encoders to control platters on dj software. Without a Z on the knob I cannot stop the platter when holding the knob, only jump it forward and backwards. I think this could get the software a lot more attention. The lack of Z on the knob is what actually sent me to this thread.

One more shot at explaining this...

As far as the pad array, part of the difficulty was not being able to re-initiate the fade out of the fader using the Pad's release time. So if you manually move the fader, or are using the pad to move it and then hit 'Lock' the fader will remain in the spot you left it. When the fader is not actively moving the 'Release' button (i use a pad but whatever) appears and the 'Lock' button disappears. The idea is to eventually be able to fade out effects over 16 or 32 beats or whatever by hitting the 'Release' button.

It would have been ideal if there were a way to send a quick (10ms) signal to the pad from another object to initiate the Pad's release cycle, but I could not find a way to do that so had to build my own Attack and Release functions and call them from the various objects. Because of all that, some extra work also had to be done so that initiating the Attack cycle from the pad would correctly and seamlessly over ride the release cycle if it were active and this is where a true Z value for the pad would have been nice. I basically had to set all the Pad's envelope values to 0 and utilize its X as a Z value, and then store the attack/release as separate variables, as well as the timed functions that employ them.

The bigger pain in the ass that resulted was mimicking the hold ('Freeze' button) function, so that when you let go of it, the fade in would continue at the correct rate, or if the Pad was no longer being held, the release cycle would be fired, or if you let go of the pad and then re pressed it while holding it would still fade in correctly etc... I also did some work to feign the brightness of the pad, which works correctly except when you're actually touching it (jumps straight to full brightness but will be set to the correct value on release).

So I guess the initial issue was that there was no way to activate a Pad's DSR cycle without actually touching it very briefly (no way to do this from another object)... Realizing that was a very quirky feature to ask for I kind of worked around it, but then became confused as to why only a few of the objects had Z references.

Anyway, long story short I think you should move towards giving every object a Z value, albeit the objects you mentioned should take priority as there is virtually no work around for them

[Macciza]

Hi

I think I see what you mean - your 'z' is an adsr type thing like in MultiBall . . .
Personally I would have called it something else . . .

I take a more 'classical' view of 'z' (like in x,y,z axis) - z is simply 'in/out' data . . .
it tells you whether it is touched - or ideally when we have pressure it will give that value . . .
Implementing z as an adsr does not really fit in with how I view the other objects or the z parameter

Ideally I would like to see 'z' as a floating point value showing 'pressure'(area of blob?) but that has inherent difficulties . ..
In that context I would certainly want a Pad object with both x and z vars . . .
Until then 'z' is a flag indicating whether an object is presently touched.

Cheers
MM

[Traxus]

Yes, when I say Z, I just mean a Boolean tied to whether the object has an active cursor controlling it or not.

In light of your floating point wish, Z is probably a bad name for it (your idea is more fitting), C would probably be better for the cursor, but the convention is already in affect. I can see where the language will need a huge overhaul in the future regarding its patterns and naming conventions but I don't expect that any time soon.

[macay]

I'd like to see the z variable for Pads and Switches in the near future.