pattrhub shortcomings and a nice crash
Apr 16 2022 | 7:24 am
I'm somehow underwhelmed by the pattr snakepit of objects. For all its bloat and complexity, it doesn't go to 100%, and can crash.... read on. In the control patch below, I'm trying to refer, via [pattrhub ::testui], to a remote top-level UI patcher that contains a [pattrmarker testui].
- I'd expect pattrhub to also send me changes made to parameters in the remote patch, like pattrstorage can do with @outputmode, but that works only in the remote patch, DUH!
- When the remote patch is not open *before*, pattrhub ignores its arg (and you need to resend the "patcher") message, so no loadbang will do, but one needs to devise a send/receive logic where the remote patch says "I'm here now". I'd expect pattrhub to be notified that the pattrmarker is created (by loading the remote patch or creating it), and connect automatically.
- Once connected, after closing the remote UI patch, pattrhub crashes when trying to change a remote param:
Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread 0 com.cycling74.Max 0x00000001018528c6 object_attr_get + 38 1 com.cycling74.Max 0x00000001018993a3 object_attr_getvalueof_imp + 99 2 com.cycling74.Max 0x0000000101853627 object_attr_getobj + 55 3 com.cycling74.pattrhub 0x0000000126dd97c2 pattrhub_resolve_object_impl + 146 4 com.cycling74.pattrhub 0x0000000126dd7ab2 pattrhub_anything + 194 5 com.cycling74.Max 0x000000010187e8e3 typedmess_fun + 371 6 com.cycling74.Max 0x0000000101869bb2 outlet_anything + 1426 7 com.cycling74.Max 0x000000010187e8e3 typedmess_fun + 371 8 com.cycling74.Max 0x0000000101848f9a aeval + 2314 9 com.cycling74.Max 0x000000010184863e atombuf_eval + 142 10 com.cycling74.message 0x0000000107741a17 jmessage_atombuf_eval + 567 11 com.cycling74.message 0x000000010773f68f jmessage_int + 175 12 com.cycling74.Max 0x000000010187c878 outlet_int + 1560 13 com.cycling74.number 0x00000001276dc029 jnumber_mousedragdelta + 409