allow different HRTFs for each instance of earplug~

[umlaeute]

currently, loading a set of HRTFs affects all [earplug~] instances.

the typical example used to be:

• a project misses an earplug_data.txt file and doesn't explicitely load another data set
• starting the project, spatialization doesn't work well
• the user opens the help-patch
• this triggers a re-search for the default data-file and eventually finds it
• now the project's spatialization works nicely

[umlaeute]

sidenote: this is a bug report against "an older version" of earplug~ (as distributed via deken in summer 2020).
i only have done very casual checks in the commit logs, but i don't think it has been fixed in the meantime.

[danomatika]

Yeah, good point. It may be as simple as creating the mem dynamically, loading from the file, then using that. If there is no file, then it uses the static default set pointer.

[danomatika]

There could also be an additional object to manage this, similar to how the bap object works. I think it's useful to have a shared impulse set and the ability to load a specific set for a specific object. Default behavior should stay as is.

[danomatika]

Actually, re-reading this:

a project misses an earplug_data.txt file and doesn't explicitely load another data set

This is no longer a problem as

1. Hans added the default data set into the header which is compiled into the project and
2. I changed the default dataset filename so it doesn't try to overwrite the same data each time the object is loaded. The file is no longer required.

[danomatika]

I think I will tag current commit as 0.2.2 and expanding the data set loading can be for 0.3.0.

[umlaeute]

i'm personally not a heavy user of [earplug~], so I can't really tell.

however:

• i don't like a two-object approach
• i don't think there's a real use-case for updating the global HRIR-set via explicit [load( commands to multiple objects

but yes, i'm mainly concerned about backward compatibility too.
e.g. what if somebody expects, that they only need to load the HRTFs onc and all the instances "just work"?

how about this:

• we have a global HRIR-set, and an object-local one
• per default the object-local HRIR-set is set to NULL
• if the object-local HRIR-set is NULL it uses the the global HRIR-set
• the first object to explicitly load an HRIR-set, updates the global set (and becomes the "global-set updater")
• if other objects then explicitly load HRIR-sets, they will create their local sets (and use them)

[umlaeute]

This is no longer a problem as [...]

ah well; this is the issue that triggered my curiosity.
i still think it is a problem in its own right.

[danomatika]

how about this:

• we have a global HRIR-set, and an object-local one
• per default the object-local HRIR-set is set to NULL
• if the object-local HRIR-set is NULL it uses the the global HRIR-set
• the first object to explicitly load an HRIR-set, updates the global set (and becomes the "global-set updater")
• if other objects then explicitly load HRIR-sets, they will create their local sets (and use them)

That sounds fine. I don't think there needs to be a load message or anything truly dynamic. At the most, I might suggest a creation arg to ignore user-provided data sets and always use the default one, in case you want the default after another has been loaded.

[umlaeute]

I just noticed that there actually is not explicit [load( msg at all (i was just assuming).

i think this makes it a lot easier to provide a backward-compatible solution:

• whatever gets [load(ed, is only ever object-local.

automatic loading of earplug_data.txt could probably just keep updating the global HRIR.

[umlaeute]

I don't think there needs to be a load message or anything truly dynamic

ah well.
i'm thinking in terms of listening experiments, were I do want to be able to change the HRIRs dynamically, so i can compare them.
(i have to admin, that i don't currently plan to do such an experiment in the very near future; otherwise I would have hacked [earplug~] already)

[danomatika]

Ah well, I would also use the functionality of changing the HRIRs but in our case, we can simply close and reopen the whole server instance.

[danomatika]

I think this is more of a feature than a bug.