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

There should be a way to have "fixed" tuples #356

Open
jcelerier opened this Issue Jan 31, 2017 · 7 comments

Comments

Projects
3 participants
@jcelerier
Copy link
Member

jcelerier commented Jan 31, 2017

e.g. always [int, float] or [int, int, int]

@bltzr

This comment has been minimized.

Copy link
Member

bltzr commented May 15, 2017

is that fixed with Vec2f or so ? @jcelerier

@jcelerier

This comment has been minimized.

Copy link
Member Author

jcelerier commented May 15, 2017

mhh, not really. The problem is fitting with the osc & oscquery specification where for instance a node is said to have type [int float int float string string] (for instance) and cannot deviate for it. while the tuples in libossia / i-score can add / remove elements and have their elements change type.

@bltzr

This comment has been minimized.

Copy link
Member

bltzr commented May 15, 2017

@jcelerier jcelerier added this to the release/2.0 milestone Jun 1, 2017

@gsenna

This comment has been minimized.

Copy link

gsenna commented Jun 8, 2018

Just to say that for my use case I'm fine with some way of creating list nodes with a fixed number of parameters whose types are set at the beginning.

@bltzr

This comment has been minimized.

Copy link
Member

bltzr commented Jun 20, 2018

so, doing that would imply separating the list type into 2 different types, right ?

  • list : would stay the same, i.e. just a bucket for putting whatever one likes into it (just like the generic type in Jamoma - there would be no way in score (as is currently the case) to set domains or range (BTW, then the clipmode could be just removed)

  • tuple : would be a new type, with a fixed number of members, each of them being of a fixed (and unmutable) type - then we could make a dedicated parameter editor window, possibly with tabs for each member, as @gsenna suggested, where we would basically have all attributes (or just some ? at least range... what else ?) that we can find for a mono-dimensional parameter

I've added an issue for that in libossia, as I guess that would be the first step towards this: OSSIA/libossia#403

@jcelerier

This comment has been minimized.

Copy link
Member Author

jcelerier commented Jun 20, 2018

list : would stay the same, i.e. just a bucket for putting whatever one likes into it (just like the generic type in Jamoma - there would be no way in score (as is currently the case) to set domains or range (BTW, then the clipmode could be just removed)

actually there is a domain / range, it's just that it isn't shown in the UI...

Also this would be nice since it would map more closely to the OSC and OSCQuery semantics

@jcelerier

This comment has been minimized.

Copy link
Member Author

jcelerier commented Aug 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.