Good point.

hey

so... is this a bug, .. or a feature ?

The patch I just posted here : https://cycling74.com/forums/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

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...

Stefan