Saved ASD file via GUI is invalid

[HaHeho]

I am using the ssr-brs mode. I have loaded a valid scene file and saved a new ASD file via the GUI.

Original:

<source id="NAME" name="NAME" properties_file="BRIR.wav" volume="0" mute="true">
  <position x="-2" y="1" fixed="true"/>
  <port>1</port>
</source>

Saved:

<source name="NAME" model="point" mute="true" volume="0" properties-file="BRIR.wav">
  <port>1</port>
  <position x="-2" y="1"/>
  <orientation azimuth="0"/>
</source>

Three issues occur:

1. The tag properties_file is now called properties-file, which renders the file unusable. When trying to load this file, the SSR does not start due to the invalid syntax.
2. The tag id is lost. I use it to remote control different source properties via FUDI messages, which is not possible with the new scene anymore.
3. The tag orientation azimuth is inserted. But I believe this has no relevance for the ssr-brs rendering?

[mgeier]

Thanks for reporting this!

(1) will hopefully be fixed with #346.

(2) seems to be intentional, I found this:

ssr/src/controller.h

Lines 2293 to 2300 in f1d2dcb

	if (scene_file_name != "")
	{
	// ignore "id" -> ugly quick hack!
	}
	else
	{
	source_node.new_attribute("id", apf::str::A2S(id));
	}

I don't remember why we have done this, though. This is already in the initial Git commit from 10 years ago.

Maybe we didn't want to save the internally generated IDs?
It would be easy to filter those out (since #127 all internal IDs start with a dot).

But maybe there was another reason ... @JensAhrens do you remember?

(3) is just a cosmetic thing, right? I'd rather not invest any energy into fixing this.

[JensAhrens]

Ad (2): Sorry, I don't remember what we were thinking there. HaHeHo has a point in that it can be useful to store the IDs. We should add that.

Ad (3): I think that it is better to keep this redundant tag there because it will matter for other renderers. The scene description should be independent of the renderer, and I don't want to differentiate cases when storing the scene. (The idea was that a renderer takes into account all the information that it is able to take into account and disregards everything else.)

[mgeier]

OK, I've looked into (2) and it isn't that simple. Saving an XML scene still uses a LegacyScene which doesn't have string IDs.

I'm not going to fix that, but if somebody else want's to fix it, please go ahead!

2. The tag id is lost. I use it to remote control different source properties via FUDI messages, which is not possible with the new scene anymore.

What about using numeric IDs in your FUDI messages?

[HaHeho]

What about using numeric IDs in your FUDI messages?

For a user study, I am triggering to play different BRIR configurations. Using numeric IDs (from how I understand, an incremental range of integers generated when loading the scene) seems very prone to mistakes, e.g. when changing the composition (or even order) of loaded BRIRs and therefore having to adjust all FUDI indices.

Ideally, one would also be able to use the name to address a source via FUDI. The name has to be unique as well, doesn't it? So this could be viable? (This is my intended use case and why I place the same string into name and id when generating the original scene file.)

[mgeier]

seems very prone to mistakes

Sure. If you change the scene, the IDs might change.
But if not, it should work fine.

It's error prone, but at least it works!

The name has to be unique as well, doesn't it?

Not that I'm aware of.
The name should only be used for display to humans, not for programmatically identifying sources.

Ideally, IDs should simply work as you want them to, but that's currently not implemented.

[HaHeho]

The name has to be unique as well, doesn't it?

Not that I'm aware of. The name should only be used for display to humans, not for programmatically identifying sources.

Right. I got confused due to using the same string as the id, which has to be unique.

Ideally, IDs should simply work as you want them to, but that's currently not implemented.

Its fine. It wasn't too difficult to detect or fix. In the worst case a regex search and replace could restore my missing IDs.

[HaHeho]

This can be closed when #346 is merged.

[mgeier]

For future reference: part (1) has been fixed in #346; part (2) is still missing, contributions are appreciated; part (3) is just a minor cosmetic flaw when using the BRS renderer, but it will not be fixed because it does make sense in the other renderers.

I'm closing this issue now, but any further improvements are of course welcome.