Mira triggers UI objects in High priority
Jul 16, 2013 at 4:55am
Mira triggers UI objects in High priority
Mira triggers UI objects in High priority :
– Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
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 ?
“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..
Jul 16, 2013 at 5:20am
Jul 22, 2013 at 7:52am
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/
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 ?
Jul 22, 2013 at 11:15am
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.
Jul 23, 2013 at 4:00am
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, …)
Now with Mira, it’s a really different approach, all these options are unnecessary / unavailable, and it’s advertised this way :
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.
trick question : what exactly happens when you double-deferlow a message ?
Jul 23, 2013 at 8:39am
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…).
Jul 23, 2013 at 10:18am
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”.
Jul 23, 2013 at 10:58am
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.
Sep 11, 2013 at 2:57am
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.
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.
You must be logged in to reply to this topic.