Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Model/View highligh and aliasing does not work (at least not as in Jamoma 0.5.7) #1009

Open
lossius opened this issue Jul 28, 2016 · 12 comments
Assignees
Labels

Comments

@lossius
Copy link
Member

lossius commented Jul 28, 2016

In Jamoma 0.5.7 these two features would work as following:

/my_model/view/highlight green

This would change the colour of the j.ui backgroun panel in the model to the specified colour.

/player.1/alias /anton

This would cause several changes to the behaviour and display of the model:

  1. The model would respond to messages sent to the model /anton in addition to responing to messages sent to the model /player.1.
  2. The name of the model displayed in the top bar of the module would change from /player.1 to /anton
  3. When getting state of all models, the state of the model would be reported as the state of the model /anton rather than /player.1.

In Jamoma 1 none of them work the same way.

highlight does not seem to work at all.

alias kind of work but not quite. The displayed name is not changed in the view, and neither is it used when reporting the state of the model. I guess one question is whether this feature is needed any longer at all, or if one rather is able (and should) dynamicallychange the name of the model and it's view for real, instead of operating with an alias?

On a sidenote, interacting with JamomaMax/Jamoma/examples/model features/alias renaming.maxpatend to result in spinning beach balls.

Any thoughts on this @theod and @bltzr ?

@lossius lossius changed the title Model/View highlugh and aliasing does not work (at least not as in Jamoma 0.5.7) Model/View highligh and aliasing does not work (at least not as in Jamoma 0.5.7) Jul 28, 2016
@bltzr
Copy link
Member

bltzr commented Jul 29, 2016

Concerning the highlighting, it works in 1.0, though with a different syntax, as shown in the "highlighting" example from the Jamoma Overview Extra
Or as discussed on the user list

@bltzr
Copy link
Member

bltzr commented Jul 29, 2016

Concerning the alias, I don't have a strong opinion on the subject, as I never used the feature, or even felt the actual need of it (even I agree it would be an interesting feature if it was completely implemented, which it currently isn't...)

@bltzr
Copy link
Member

bltzr commented Jul 29, 2016

though, I guess it wouldn't be to hard to replace the name for the alias in the get_state part of the cue_script model
(BTW, looking into it, I guess setting j.namespace @update to 0 would help some of your problems... the "pop-up" ones...)

concerning displaying the alias instead of the model name in j.ui: that would obviously need to be implemented in j.ui's code..

and, yes, there seem to be some stability improvements to do in order to actually use aliases...

@lossius
Copy link
Member Author

lossius commented Aug 1, 2016

Is it possible to change the name of a model on the fly? If so the alias feature might be redundant, as one can simply change the name of the model (and its views) instead.

@lossius
Copy link
Member Author

lossius commented Aug 1, 2016

Thanks Pascal, checking your answers now. So it seems like highlight is a property of the view now rather than the model. I am unsure (both ways) if this is the ideal solution. In one way I can understand that highlighting is part of a visual representation (view), but on the other hand I can also easily see that you want to give all views that subscribe to a particular model one and the same highlight. If so, it would be natural to think of highlight as an attribute of the model, not the view.

@tap
Copy link
Member

tap commented Aug 1, 2016

Can that be accomplished (all views of the model) using wildcards?

best,
Tim

On Mon, Aug 1, 2016 at 11:13 AM, Trond Lossuis notifications@github.com
wrote:

Thanks Pascal, checking your answers now. So it seems like highlight is a
property of the view now rather than the model. I am unsure (both ways) if
this is the ideal solution. In one way I can underatand that highlighting
is part of a visual representation (view), but on the other hand I can also
easily see that you want to give all views that subscribe to a particular
model one and the same highlight. If so, it would be natural to think of
highlight as an attribute of the model, not the view.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1009 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGsRey0X0_Y0V3GCTI2-YY_s1Avid4wks5qbik6gaJpZM4JXb_W
.

@bltzr
Copy link
Member

bltzr commented Aug 2, 2016

Is it possible to change the name of a model on the fly?

Nope, I don’t think that’s possible at all
If so the alias feature might be redundant, as one can simply change the name of the model (and its views) instead.

Even if that was (made) possible, the problem would remain for the view to know that the model it binds to has changed its name - that’s maybe not impossible to achieve, though...

@bltzr
Copy link
Member

bltzr commented Aug 2, 2016

Thanks Pascal, checking your answers now. So it seems like highlight is a property of the view now rather than the model. I am unsure (both ways) if this is the ideal solution.

I think it is. And that’s another thing we solved in Montréal: that the view is itself a model, and can have properties...
In one way I can underatand that highlighting is part of a visual representation (view), but on the other hand I can also easily see that you want to give all views that subscribe to a particular model one and the same highlight. If so, it would be natural to think of highlight as an attribute of the model, not the view.

Nope, I don’t think so. Because one could want to have different highlights for different views of the same model.

Though, it’s quite easy to achieve what you want with the current implementation by adding a parameter to the model, e.g. [j.parameter color @type string], and then binding to it in the view, and passing that to the view, such as:
[j. remote color] - a menu could be added
|
[prepend ui:highlight]
|
[j.view]

What do you think ?

@bltzr
Copy link
Member

bltzr commented Aug 2, 2016

Can that be accomplished (all views of the model) using wildcards?

kind of, if views are named in a clever way using their second arguments…
though, I guess that would be a problem when binding a view to another model…

I think the best paths are:

  • either as I proposed in my previous mail
  • or having a centralized system that keeps track of all views and to which models they bind - for more sophisticated view color management...

@lossius
Copy link
Member Author

lossius commented Aug 2, 2016

For my use it is quite clear that I'd like all views for one and the same model to be highlighted the same way. As such I'd like this to be an amenity of the model. The reason why I want to provide the views for different models with different highlight colours is exactly to discriminate between what model they represent. If I change what model a view subscribes to, I would indeed want the view to automatically change to the appropriate highlight colour.

One example of where this is the case is in all DAW programs that I'm aware of. If you set a track to a certain colour, the mixer strip for that track will be given the same colour. This is how highlighting in Jamoma should function as well.

@lossius
Copy link
Member Author

lossius commented Aug 2, 2016

And I don't want to have to do this manually by adapting and customizing each and every model that I choose to use. I want this feature to be available for standard models provided with the Jamoma distro as well.

@bltzr
Copy link
Member

bltzr commented Aug 11, 2016

Well, if that's the way you want it to be, then just do it!
I was just mentioning other potential use cases, to widen the perspective, but sometimes perfect is the enemy of good...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants