TWO 4 Win V0.12.5 Behaviour different for sorting, naming space node creation and playback

[jon121]

Minor topic

I added a name space value 0 as a final node. The idea was to map the levels of a building;

Before

L0 = position/N/1
L1 = position/N/2
L2 = position/N/3
L3 = position/N/4
L4 = position/N/5

After

L0 = position/N/0
L1 = position/N/1
L2 = position/N/2
L3 = position/N/3
L4 = position/N/4

I have since decided against this but thought I would log this behaviour, although I won’t be using 0 value now.

1. Sorting order namespaces
   As a result I created

/layer/1/position/N/0

I then copied and pasted this to create further nodes

/layer/1/position/N/1
/layer/1/position/N/2
/layer/1/position/N/3 and so on.

The actual result pasted the value creating 2 and skipping 1

/0
/2

The expected result was;

/0
/1
/2

2. Sorting order Timeline source list
   I then when to add the source land for editing as I was prepping a recording.

You can see the list of the source is not in A-Z order

/0
/2
/3
/4
/1

Then I checked the Scene output as my application values seemed to be jumping/jittering which was more an issue.

Here’s a sample video

When I returned to;

1
2
3
4

etc

The jittering stopped

The sorting on these forms;

Timeline Pick Source for Editing, scene didn’t seem to be sorted in any order.

[iliasb]

Thank you for this, your bug reports are the best!

I’ll look into it with first priority.

I suspect that the jumpiness that you see is the result of multiple messages being sent to the same target from several sources - in this case internal in TWO. Maybe a router that’s sending to the same target as an Address, and so the “offsets” are ignored, and there’s a jump?

If you could share your .two project file I’ll check to make sure and reproduce - you can send it to me privately.

Best,
Ilias B.

[jon121]

Hey IIias,

Thanks, re-creating the same scenario, data, conditions can be a challenge.

I’ve not been able to re-create it myself, I need to re-create the source and destination, but I didn’t think that would impact things. Usually I just stop the source from playing and then play back on the recording.

I’ll send a link via email.

I’ve looked through the previous 10 versions in my cloud backup and found the file that I think I came across the issue.

Regards

Jon

[iliasb]

Thank you for the file!

I’ve tested to recreate the jittering you mentioned but haven’t been able to.

Regarding the sorting order - the nodes are sorted based on the time they were created - not the actual string in the address part.

So, if you send 5 messages “instantaneously”, it is not guaranteed that they will be received in numerical order over a network. (In quotes because they are still serialized also when sent).

With that said, you’ve seen that the Namespaces view supports drag-and-drop I presume? If you drag a node into a different place in the list, it will stay there.

If you see the jittering again let me know!

Best,
Ilias B.

[jon121]

Hi IIias,

Thanks for the update, I could not re-create it myself either, but will keep an eye out.

I didn’t release you can move the name spaces in the Controller Editor, that’s handy thank you. I did move them in the namespace hierarchy.

In the Namespace Controller Editor, I’ve been letting TWO build the Namespace automatically.

I noticed it stacks the Type Tag values on top of each other. Not seen a pattern as to how this is done.

However I noticed clicking Rearrange resolves this or move them yourself and they are saved if you save the file.

Which is really handy in the scene view and using the recording of a timeline to play back the clip.

I have allot of name spaces which I span over multiple ports, 1 for each layer like 6 mixing decks, handling different types of DMX fixtures.

I imagine the screen will get quite busy as I go through the layers currently 6, could we add some paging and labelling please, this could be handy view when debugging/testing etc ?

I’m thinking a page/tab per layer as in my use case.

[iliasb]

Thank you very much Jon, as always very appreciated!

A:
Re: Stacked Type Tag String - that is indeed a bug. It should be easy to fix, I’ll do it ASAP. It’s unusual that there’s more than one one TTS for an address, so it’s evaded me. I’ve always been conflicted about the right way to support multiple TTS’s, because while a source/destination might support many different ones, only one is ever really used in any given context. Maybe an option to select the “Active” TTS? I’ll fix the arranging in any case, and think about this further.

B:
Regarding deep / complex namespaces, I have actually thought a lot about that, and implemented a different solution, which however is not at namespace level, but “Address”.

Because I realized that really it is not usually very many actually very different namespaces. Rather, it is repetitions of the same namespace “pattern” in a tree, with differing address patterns leading to them.
So e.g.

/scene/fixtures/1/first_type/…
/scene/fixtures/2/first_type/…
/scene/fixtures/3/second_type/…
/scene/fixtures/4/second_type/…

Really only contains 2 namespaces: first_type, and second_type.

This is demonstrated in the “AudioVisualBach” example - if you look at the Address hierarchy there, and how it uses namespaces.

I also did an extensive test and post about this when I was experimenting with Resolume integration - the point translates directly to what you are doing even if you’re using a different app:

The intro video on that is the following:

Record, edit and play back OSC from/to Resolume with TWO (WIP)

And the detailed instructions are in this post:

https://controlmedia.art/2020/07/25/two-resolume-integration/

The point relevant to you is about Address hierarchies, a bit further down.

There’s a file linked there to download, which demonstrates the combined Address hierarchy with namespaces separated by type.
The file is from before editors were implemented, with the current build you’ll need to click “Rearrange” for each, I should really make it so that legacy files are auto-arranged on load while I’m at it.

Note that any recording you have for a namespace will not auto-translate to an address hierarchy, you’ll either need to throw it away, or copy-paste the keys lane per lane, having kept a copy of the old namespace. I’ll give it a good think, if I could automate that transition.

I hope it makes sense, if not, don’t hesitate to ask!

Best,
Ilias B.

[iliasb]

The only “side effect”, I should add, is that while namespaces are automatically populated for new messages, that doesn’t currently extend to Address hierarchies.

So, in the above example, if you send a message:

/scene/fixtures/5/second_type/…

It will not currently know to create the Address named 5, with the correct namespace for the fixture type.

[jon121]

@iliasb

I’ve always been conflicted about the right way to support multiple TTS’s

Thanks for the detailed reply, I’ll try to reply above the specific topics.

A:
The stacked string, no problem, there’s 2 x workarounds, manual move or use re-arrange.

Multiple TTS, in the example above there’s showing two but that’s because there’s a Left and Right name space and each one has 8 channels, not sure if that’s what you meant?

However I have seen multiple TTS but it looks like below.

I manually created this by selecting the node and clicking Create Type Tag string and then clicked Create Type Tag.

The latest namespace above was created automatically. I’m guessing I only need to click Create Type Tag String?

B: I need to digest this info thank you.

Regards

Jon

[iliasb]

Actually, on A, my assumptions above was wrong. I opened your file to double check instead of looking at the screenshots, and I see that I misdiagnosed the issue: It’s NOT multiple TypeTagStrings’s. Each Node in fact has a single TTS, just that each has two TypeTags. It’s the “auto-arrangement on creation” algorithm that needs further tweaking, and is definitely a bug, you’re not doing anything wrong.

OSC supports messages where the Address Pattern is the same, and the TTS differs. So, e.g.

/thing/colour, ffff (for a payload of 4 float values)
/thing/colour, iiii (for a payload of 4 int values)

To get the above, you’re have more than one TypeTagString for the single node, with different TypeTags inside.

But in your example I didn’t see that - my mistake.

[iliasb]

As for part B:
In your setup, assuming L and R are otherwise identical, you would only need one “namespace” for them - instantiated twice.

You’ll see what I mean when you’ve seen the example I think, if not let me know and I’ll show you!

[jon121]

@iliasb

stantiat

I’m assuming then where I clicked the extra type tag and you already have a float value this is not necessary?

i.e. in this case its not valid?

[jon121]

Yes L and R are usually/so far identical, usually results in two starting positions for a given namespace in a sequence.

[iliasb]

Actually, in that case, it’s worse - the message will not be matched to that node at all when received.

Because the “signature” / “footprint” of the message, is the Address Part, and the TTS, together.

(This is not specific to TWO at all, but a fundamental part of OSC’s design)

If the message is

/scene/fixtures/fixture1, f

But you have a TTS with two f’s:

/scene/fixtures/fixture1, ff

It will be interpreted as a different message and not be matched.

So be careful to have TTS’s which match the value expected.

[jon121]

@iliasb

udioVisualBac

B I’ve created a new names space and I will email you the project file.

As the labels in the control editor work from the ID address part I combined the alpha A,B,C with the number so I can see the set of controls per layer.

Not sure if there would be a way to change the value or easily combine two node values like A/1 rather than creating a node value as A1.

As I added to a given name space the address screen values automatically updated for each address, in my case each layer.

I need to now test this updated configuration and also try to record the data. But for each layer I have all the controls on one page.

[jon121]

When I looked at the Messages the Incoming/Outgoing messages for a manual change in slider A1, it didn’t contain address namespace values within the structure, so I could have multiple values for each address pattern, /Position/A1, one per Layer.

Would I need a separation of ports per Layer which is what I normally do anyway.

If so, would I need to create a OSC Root address per layer set of name spaces or is there another way to achieve this please?

[jon121]

Got it you complete the value in the OSC Address Address Part but how would you handle the ports please, one per OSC root?

[iliasb]

Would I need a separation of ports per Layer which is what I normally do anyway.

If so, would I need to create a OSC Root address per layer set of name spaces or is there another way to > achieve this please?

I’m not sure I follow, but if I understand correctly, it boils down to your preference and goals - do you need that level of granularity in the timelines, and would it help you from avoiding unnecessary repetition?

[iliasb]

Got it you complete the value in the OSC Address Address Part but how would you handle the ports > please, one per OSC root?

Assuming you’re referring to OSC ports, then yes, to use a different port, you need a separate “Location”, and to reference that, you need a dedicated “OSC Root Address” that references each distinct “Location”.

But with that said, there’s no performance benefit for doing this, quite the contrary it could cause a small decline due to more resources being used.

Best,
Ilias B.