skyvat

This patch is an attempt at controlling a series of gui objects using lfos. The "point and click" assignment of the lfos is the tricky part right now.

If you can, please look at the patch. Assignment is done by first clicking one of the "settarget" buttons in the assign patch. Click it, and then click one of the sliders in the gui patch. The lfo data should bind to the slider and take control. To reassign, just click settarget again and choose a new slider.

Works pretty well with one lfo. But when using two, I'm getting conflicting messages out of pattrstorage that prevent the second lfo from taking the assignment on the first try. If you add a third lfo, the system doesn't work at all, because the changing messages coming out of pattrstorage won't work on my filtering method.

Anyone have some suggestions on fixing this? I'm still trying to grasp all the nuances of the pattr objects. Eventually I would want 3-5 separate lfos with 3 potential assignments each.

Note: You need Jasch objects "changelist" for this patch.

This patch is an attempt at controlling a series of gui objects using lfos.  The "point and click" assignment of the lfos is the tricky part right now.  

If you can, please look at the patch.  Assignment is done by first clicking one of the "settarget" buttons in the assign patch.  Click it, and then click one of the sliders in the gui patch.  The lfo data should bind to the slider and take control.  To reassign, just click settarget again and choose a new slider.

Works pretty well with one lfo.  But when using two, I'm getting conflicting messages out of pattrstorage that prevent the second lfo from taking the assignment on the first try. If you add a third lfo, the system doesn't work at all, because the changing messages coming out of pattrstorage won't work on my filtering method.

Anyone have some suggestions on fixing this?  I'm still trying to grasp all the nuances of the pattr objects.  Eventually I would want 3-5 separate lfos with 3 potential assignments each.

Note:  You need Jasch objects "changelist" for this patch. 

pattrized-slider-control-via-lfos

OK, I'm trying to figure out exactly what you're doing here. My first instinct is to say that you don't need the pattrstorage object in this patch at all, if the basic idea is that you simply want to deal with the communication routing of a pattrforward object. Relying on the 'outputmode' data of pattrstorage is a little sketchy (not because it's unreliable, but because you're trying to use it to get information that it doesn't really contain -- if I am understanding the logic of the patch correctly).

Here's a modified version of the two patchers, which work (as far as I can tell) properly. Pattrstorage has been removed, as well as the hacky logic. Instead, we're using 'mousestate' in combination with 'hover' to determine which bpatcher was clicked. If you're using more than a single controllable UI object per bpatcher, you'll need to be a little more rigorous.

Hacking on this makes it clear that a 'pattrpath' object might be useful -- a kind of Google maps of pattr objects. Given a 'target' object and a 'starting point', you get the complete path from the start to the target, if you can get there from here. So, if I want to know how to talk to 'slider1' in my current patch from the pattrstorage that I know should be located two levels higher (without using js), I send 'slider1' to 'pattrpath @start parent::parent::psto' and get 'foo::bar::slider1'.

Hover is a new object for me - thank you for pointing it out.

Pattrstorage is being used for preset storage and message sending in the actual patch (this is just an example). I thought I could use the outputmode to report the mouseclicks because the sliders send data when clicked, but your approach is definitely more direct and eliminates the need for filtering out the unwanted messages - the source of my problems. Would the presence of pattrstorage in the main patch conflict with anything you've done here? I wouldn't expect it to.

Pattrpath sounds useful to me, especially if I'm sending these messages to multiple patcher windows.

Pattrstorage is being used for preset storage and message sending in the actual patch (this is just an example).  I thought I could use the outputmode to report the mouseclicks because the sliders send data when clicked, but your approach is definitely more direct and eliminates the need for filtering out the unwanted messages - the source of my problems.  Would the presence of pattrstorage in the main patch conflict with anything you've done here? I wouldn't expect it to.

Quote: skyvat wrote on Mon, 21 July 2008 21:30

----------------------------------------------------

> Hover is a new object for me - thank you for pointing it out.

hover used to be a Tap.Tools object, if I recall. Tim slipped it into the Max 5 distro.

> Would the presence of pattrstorage in the main patch conflict with anything you've done here? I wouldn't expect it to.

> Pattrpath sounds useful to me, especially if I'm sending these messages to multiple patcher windows.

OK, I'll think about that for a rainy day.

Quote: skyvat wrote on Mon, 21 July 2008 21:30
----------------------------------------------------

Hmmm - on further inspection, I am realizing that the patch does have multiple GUI objects and that hover is only reporting the scripting name of the bpatcher, not the named objects within it. Perhaps my example patch wasn't thorough enough.

Any thoughts or hints on how a similar system could work with this?

Hmmm - on further inspection, I am realizing that the patch does have multiple GUI objects and that hover is only reporting the scripting name of the bpatcher, not the named objects within it.  Perhaps my example patch wasn't thorough enough.

That's what I was afraid of... since the example patch only had 1 object per bpatcher, it was fairly easy. However, you should be able to move the hover logic to the bpatcher level and, with a bit of rewriting, get it working. Having that 'pattrpath' object would be a bit of a help, though, as you'll soon discover...

Yes - I see that a hover-per-bpatcher gets me moving in the right direction. I'll hack away at this - if you've got ideas on how to coordinate all this stuff I would love an example.

Also, any speculation on the performance hit of having all these hovers going at once? I have over 20 bpatchers :-/

Yes - I see that a hover-per-bpatcher gets me moving in the right direction.  I'll hack away at this - if you've got ideas on how to coordinate all this stuff I would love an example.

Also, any speculation on the performance hit of having all these hovers going at once?  I have over 20 bpatchers :-/

'hover' in Max 5 is very efficient and doesn't need to poll. 'mousestate' would be a performance hit, so use a single one and send/receive to deal with that.

Everytime I am on my bike, generally as soon as I am as far from where I am coming as to where I am going, it begins to pour. Beautiful summer here.

could you just explain the use of the 'route none' and 'trigger none' with 'zl reg'? I'm not sure if I completely understand what's going on there.

could you just explain the use of the 'route none' and 'trigger none' with 'zl reg'?   I'm not sure if I completely understand what's going on there.

Yo, it's just a hack. First, we ensure that the symbol 'none' is stored in the 'zl reg' if the mouse leaves any object or enters an unnamed object. Also, if a mouse click causes the 'hovered' object's name to be reported. Some of that is likely overkill, but I was in a hurry and just wanted to cover my bases.

Second, if the symbol 'none' comes out of 'zl reg', we don't pass it. That is, we do nothing. We're just using 'route' as a filter for good names ("if (symbol) != 'none' then pass(symbol) else return" in some kind of pseudocode).

pattrized slider control via lfos