Brian H.

OK, here's an example of what makes me want to give up: [pattrstorage] can store names with slots– Great! So now we need a way to get those names to an interface to store and recall, name appropriately, and keep the lists current. This is a pretty basic requirement, and clearly Cycling had it in mind. But gluing this simple thing together is unreasonably clunky, at the least the way I conceived of going about it. I'm no expert, but I'm not new– this shouldn't take hours to do.

What's the magic bullet (or totally different approach) I'm missing in the sloppy, incomplete attempt below?

prepend

message

pack

zl.slice

number

dialog

umenu

loadbang

textbutton

autopattr

pattrstorage

OK, here's an example of what makes me want to give up:  [pattrstorage] can store names with slots– Great!  So now we need a way to get those names to an interface to store and recall, name appropriately, and keep the lists current.  This is a pretty basic requirement, and clearly Cycling had it in mind.  But gluing this simple thing together is unreasonably clunky, at the least the way I conceived of going about it.  I'm no expert, but I'm not new– this shouldn't take hours to do.

Hi Braintrust,
OK, here's an example of what makes me want to give up:  [pattrstorage] can store names with slots– Great!  So now we need a 

-pattr-naming-help

Basically, you're doing it right. Pattrstorage is very fiddly, and if you want to take andvantage of all of its slick possibilities, you have to make a pretty ugly patch, I'm afraid....

Basically, you're doing it right.  Pattrstorage is very fiddly, and if you want to take andvantage of all of its slick possibilities, you have to make a pretty ugly patch, I'm afraid....

It just calls for making an abstraction with the interface features you want (for instance: names in a menu, the ability to make your user save a name with a preset, or not). Then you can reuse that abstraction as a bpatcher connected to your [pattrstorage] in any new device/patch you make. You'll get a ton of mileage out of it that way, and you get the flexibility of making it how you want it even if it seems like a lot more fiddling up front.

It just calls for making an abstraction with the interface features you want (for instance: names in a menu, the ability to make your user save a name with a preset, or not).  Then you can reuse that abstraction as a bpatcher connected to your [pattrstorage] in any new device/patch you make.  You'll get a ton of mileage out of it that way, and you get the flexibility of making it how you want it even if it seems like a lot more fiddling up front.

Thanks for the replies, sorry it took me awhile!

The issue with UI abstractions in Max is always that then you're boxed into those interface elements, layout, and look. That's why I tend to try to put them on the top-level patcher much of the time, and use abstractions for the guts. Sort of an attempt at Model-View-Controller. Maybe there's another approach that does as well or better?

The issue with UI abstractions in Max is always that then you're boxed into those interface elements, layout, and look.  That's why I tend to try to put them on the top-level patcher much of the time, and use abstractions for the guts.  Sort of an attempt at Model-View-Controller.  Maybe there's another approach that does as well or better?

[pattr] naming mess...