OSCdevice: int and float in the same message


#6

NB: I’ve been doing some editing, improving the layout, after first publishing my reply, so if you received the last message by email, I’d advice that you read it online


#7

Yes, some kind of addresses converters/pattern editors would be great.

As an example to fill the survey, worst case I’ve seen has been LiveOSC2. (I started sketching a Max-based addresses converter at some point but gave up…).

An address example would be:

/live/track/device/param 1 2 34 0.163435 2 Frequency A

Making this user/Ossia-friendly would be:

/live/track.($1+1)/device.($2+1)/$3 $4

Or better:

/live/track.($1+1)/device.($2+1)/$6$7.$5 $4

yikes


#8

thanks @jln , that’s a very good (meaning really really ugly ! ) use case
I don’t think we can find something more convoluted than this ! :smiley:


#9

Well, I hope we cant…


#10

hmmm… for something like this, what I (as an user) would like is for instance to specify this mapping when creating the device, and then have the input addresses / messages automatically map to relevant parts when doing an OSC learn. Would it make sense ?


#11

sure!

though, I guess that it might be good to also have the possibility manually specify ranges for variables for cases when “OSC learning” is not possible and/or desirable


#12

This is all very interesting and I’m not sure I can’t add much to the discussion. Although, I might be able to share my experience with Csound and OSC, where talking to Carla would involve passing:

“/Carla/0/set_parameter_value”, “if”, 1, kValue

The int and the float there can both be expressions that are being evaluated at each control cycle. I know a text-based audio design language is a completely different thing from a sequencer with a GUI, but it would be great to have that kind of flexibility.

@bltzr, for me both the int and the float are part of the message and should be treated equally, so I’m not sure I would go for that thing with the instances.

I guess as a user I would like to have a tabs system in the devices node editor for adding parameters to the right side of each final child, or maybe even change the “philosophy” so that parameters become visible children in the device panel. Then each of those parameters could be the destination for a process’ output (and possibly a nightmare to sync those signals at each control period?)

@jln, I was thinking that a solution for me with Carla could be to code an OSC router in JUCE, so that I could compile it as a VST and then actually load it inside the host. But I’ll stick to writing my scores with Csound for now.


#13

Well, unless I completely misunderstand what you’re expressing here, that is more or less what I was proposing

In other words, what we are both saying is that we want to be able (in the described case) to have one node for each int in the device explorer, in order to easily create processes for just the float part of the message.
Do we agree on this?

Also, about instances (which is maybe not the best possible denomination for the concept), there is a little explanation with an illustration here :
https://ossia.github.io/#creating-nodes


#14

I’m probably mistaken, but aren’t you implying that the ints of my example will become -in practical terms- treated as part of the address and therefore will contain fixed values within a range?

What I was saying was: If the parameters become visible children in the device panel then at the end of the hierarchy I should see a parent called “set_parameter_value” and then its two children: param1(int) and param2(float). Then both could be subjected to automation and whenever there’s a change in any of the those a new message is sent by the OSCdevice. Was that what you were saying?


#15

I’m probably mistaken, but aren’t you implying that the ints of my example will become -in practical terms- treated as part of the address and therefore will contain fixed values within a range?

you aren’t mistaken :stuck_out_tongue:

What I was saying was: If the parameters become visible children in the device panel then at the end of the hierarchy I should see a parent called “set_parameter_value” and then its two children: param1(int) and param2(float). Then both could be subjected to automation and whenever there’s a change in any of the those a new message is sent by the OSCdevice. Was that what you were saying?

Wouldn’t it create some additional complexities if you are sending two automations to two different parameters ?


#16

OK, thanks for explaining, @gsenna I think I see what you mean, now

OK, so probably we should make sure that the previously proposed syntax allows to do that, because I think that what you’re asking for could be done by something like adding two “alias” nodes

  • param1 $1
  • param2 $2

so then, two children would be created, in the way you requested (right ?)

anyway, what you could do, for now, would be to use the @[n] syntax in the automations address field in the inspector :

  • set the value of the int ie @[0] with a state
  • create an automation for the float with @[1]

Here’s a link to a score demonstrating this (open the messages window and look at the output), and also showing the limits of it: just overlay both boxes, and you will see that only the lowest messages are sent.

I won’t go into details on the why of this, but, in short, it allows to combine components of a complex dataspace across concurrent processes (like using one automation to set the luminance of a color in the hsl colorspace, while an other, parallel and independent automation, sets the red value)

Well, as I demonstrated it in the score above, with this logic, it’s very hard (at least with score’s current design) to have automations to different parameters (described by different int values) of your VST player or whatever.
Which is, I guess, what @jcelerier was saying:

While creating several “alias” nodes, one for each of the int values would allow to have concurrent and simultaneous automations to several parameters of the remote VST plugin.

But, anyway, as I said before, I think it’s good that we give a way to give the possibility to users to create the kind of things that you asked for, while also giving the possibility for other cases.

Is that any clearer ?


#17

Yes, I think we are starting to understand each other!

Yes, but not right now because Carla will still complain about receiving two floats instead of an int and a float.

I don’t know about the internals, but from the UI perspective I think this syntax could be a solution to the problem. Still you would need to use a tabs system in the device node editor or the alias nodes you mentioned in order to control the type of each parameter. If you go for the tabs system, states would need to directly allow writing them an address (i.e., like the automation does) in order to add the @[n]. With the alias nodes you could just drag-and-drop the alias node inside a state.


#18

That sounds reasonable!
BTW how would you imagine those tabs to be working ?


#19

Internals-wise this is doable with the ‘list’ type, although the node editor doesn’t allow for a very advanced management of the list members yet.

Please feel free to create an issue for that on github, and to propose ui ideas to deal with types, ranges, etc of list members : collectively and individually


#20

I haven’t done much with Qt, but after selecting “list”, I imagine you could see a QTabWidget and a “+” sign at the end in the node editor. Maybe with a single default one (a float?).


#21

Thanks, that’s an interesting proposal, although I’d leave arbitrary lists as the default.
Then we could add definitions for members, while allowing the number of accepted members to “overflow” the number of those that have been already defined.
Would that make sense? Or should we restrict lists to only defined members once one or more member have been defined? Opinions @jcelerier? (Or others ? @jln?)


#22

Maybe here ? https://github.com/OSSIA/score/issues/356

I remember pretty clearly us discuting this at length once and concluding that there were often cases where lists would be changing at runtime though (e.g. first [float, int], then [int, float, string] or stuff like this).


#23

Yes, sure we want to keep an arbitrary format (just a list of things) while it’s also useful to have some more structured lists / tuples

Maybe that should be split in two different types?
Like lists and tuples?
(Maybe there are better names to find to differentiate them, though)


#24

Tuple would be fairly well understood by computer scientists as something with fixed size and types.


#25

Is there another name for that?

If not, then I guess the ordinary Joe will be happy to learn a new name for a new thing, as long as he really needs it.


Relationship between pattern-matching and other features