Mira triggers UI objects in High priority
Mira triggers UI objects in High priority :
----------begin_max5_patcher---------- 640.3ocyV00biBBE8Y8WAiO6lQH9U121eG6zICpDCsJ3.XZ51o+2W9Pahslz zzNYJynBWtB2ygyE3YeufB9dhL.7aveAddO664YMYL3Mz1KnEuurAKstETzq TbVPnqKZk0Hu39ekNZi02RYMDk0e3Ai7d0as5Lodpi3BgfBLqN.b2P2cXU4V JqdsfTpbd.ShWDEBfvTym33w2f6L+xK99lWgWHVT755FxXbuCKX3VxL8bDJi OKJ6vB8HnHh0DFtngbEL.koNOADcJBX3ej3cjp0XkRP0qUjC0jCLw.UX.bSO guYz7n8igQCmUOOoLwM4VtPcA9MhykyzGksiJoijlqe6543mO4haIusknIyA ZQQ1aYvfsz5sfNAkKnpm.sDoDWSjfQ+ZnLRIumYcF8dA.JZzyMb1AL+GAE2b VswFQcgocjdEaNEQzQCqj9OGM.WjrJAlmcF8PZxhzU5RVH.krzHGxLSAXI5J yJNYFNL91jheLhPYFrfhFe+MiHzsAQvruYDwHOpi+2osUaEDb0FZiNgZN3dk R2o7.5T7PPn94UdXhNF8pn+CnGX9pEIgfzruD8bpb+F9iuO0+Ry7SQ+rx7yc RHWNeZ9WJmukJvK1X1JdFYS1rn67Xo.W9PsPylUGyDzZFWCfFZ4CSO1bli4r nCFgz7ftj6pGGoKH8VbnE4lpKmfVq1ytN9lqzXm.i8oTfj2KJGUuC2gAb3jz JhTQYXEUu2wAefS7YKsphvNF4UTo4neKtilco3Ril3eTQC7RhFzMMbfeT3De kgiSHg651QDxgwzFI5rl64BSyzPaSJy0zJkCDDycXb9auiS.VnU1JsrtW31t XedZfuYddw++tu8qWA -----------end_max5_patcher-----------
if we consider that UI object are primary intended to be triggered by mouse clicks, then they should ouput messages in low priority as well when triggered by iPad touchscreen… don’t you think so ?
there are many situation in Max (and especially when working with Jitter…) where you don’t want to trigger patches in high priority…
"if you want to use a patch with Mira and want it to act exactly as when you click on UI objects with a mouse, then you have to add a [deferlow] object at the output of every UI object" doesn’t sound like a very user-friendly solution…
from my experience : when working with network devices, I most of the time start by inserting a deferlow just after udpreceive ; but with Mira, it’s not possible to "globally" defer all messages..
so… is this a bug, .. or a feature ?
The patch I just posted here : http://cycling74.com/forums/topic/sharing-is-surfing-waveform-for-mira-kind-of/
demonstrates this potential problem : if you remove the [deferlow] just bellow the [live.tab] that selects the buffer~ to display in the waveform~, the patch works fine with a mouse, but NOT in Mira …
(in that particular case, it probably has something to do with jit.buffer~ …)
I really don’t think this is the expected behavior ; when a patch works fine with UI objects triggered by mouse clicks, it SHOULD work the same way when triggered by Mira.
Am I wrong ?
This really depends on if one thinks of Mira behaving like the mouse on your computer (low priority) or like a MIDI controller (high priority). I personally think the latter is preferable, though I understand an argument for each. For now I don’t think it will change, though it could be an option in the future.
Thanks for replying, Joshua
sorry for insisting…
until now, when one wanted to control a patch from ‘the real world’, you needed to add some objects to communicate with the physical devices (midiin, udpreceive, hi, wacom, …)
that mean that these inputs can be used to control directly the algorithm, possibly bypassing the Max UI objects.
At this point, the user has a couple of options to deal with, regarding how the flow of messages coming from the controllers will affect the patch : change priority (defer(low)), limit rate (speedlim / qlim ), filter repetitions (change …) , adapt range (scale, ..)…
Now with Mira, it’s a really different approach, all these options are unnecessary / unavailable, and it’s advertised this way :
"how to touch a Max patch"
"Mira directly controls your patch without any additional objects. There are no OSC or MIDI messages to wrangle, no external editor, and no extra patching required."
and that’s true ! It’s so easy to use that you very easily start thinking it as a "window to your patch", or "Max is in my iPad" rather than a new method to receive data in a patch.
As it is actually, I’m pretty sure that very soon, the Mira forum will be full of posts saying "my patch works fine, but not when I play it with Mira", and you’ll have to explain again and again how to deal with messages priority & scheduler thread, and all these kind of things that probably lot of users don’t want to have to deal with…
I really think you’d better take this option : Mira is a way to touch your UI objects just like you would do with a mouse.
don’t miss the opportunity to make something simple and useable by all kinds of Max users !
trick question : what exactly happens when you double-deferlow a message ?
(for ex if you add a deferlow after a max UI object that already sends messages in low priority when clicking on it)
Can’t it lead to inextricable situation when messages coming from UI objects can have different priority depending on how you use it (mouse / Mira) ?
Should I add a [threadfilter] objects after each object I use in a Mira.frame , in order to deferlow only when triggered by Mira ?
On the other hand I think the mira forum would be full already of people trying to trigger drum samples or the like, complaining about low priority.
I think it would really be important to have an attribute to set the behavior(in the long run).
I think it’s quite an understandable design decision doing it that way(you can always defer(low) things but it kind of does not make sense to bump them up into high priority(right?))
But I also had problems with this and do consider it really problematic, or at least cumbersome(adding lots of deferlows here too…).
For me the highpriority is a no brainer. Controllers work that way, and in fact, mouse is not really a tool for interacting with a patch at all for me. It’s more a programming and/or "adjust a parameter for some oddball reason".
Mathieu, thanks for your feedback. I can however only say that it is ambiguous as to what the behavior here should be. From the different positions, it sounds like an option for setting this is appropriate, though configurable options typically cause pain for someone. What is the most common use case, what the default should be if even a configurable option, etc., I’m not sure. However, please keep in mind that Mira is new, we value this feedback, and the robustness of Mira will be evolving over time. For now, being aware of how it works and what workarounds are possible to solve certain issues is probably the most pragmatic position.
One point to clarify, is that we use UI objects as a way of making the connection simple and clear, but that doesn’t mean that we are really interested in just putting a UI on a separate device designed to work the same way as a mouse on a computer works. The most interesting thing in my opinion is making touchable instruments (for which I personally would prefer to be high priority).
Obviously this becomes an issue in situations where something like a file read message is deferred, and triggering both the read and some other importantly synchronous operation at the same time then become decoupled and asynchronous. I assume this is the type of thing you are complaining about. Putting defer in front of that operation, ensures that synchronous low priority behavior.
Keep in mind that all incoming OSC is also high priority, and is often also reflected in the UI of the patch itself, so this is a common thing to workaround in this area.
As for your double deferlow concern, you could instead use defer, which will only defer if sent from high priority. And as of Max 6, defer will never reverse low priority queue order, so if you’ve avoided defer for that reason, it is no longer the case.
I think the high priority is good as it is. Simple reason, if I need high priority, I get it, if I don’t want it, I can still place a defer or deferlow.
If it would be low priority and I want high priority I would have no chance to get it!
Though an attribute to mira.frame could possibly give us both perspectives in the future…;-)
In case it changes later, two defers don’t hurt if you "enhanced" your mira patches with defers already.
I am a musician, ears are way faster than eyes, musicians need high priority for any control always…