search

pd-externals / earplug

binaural filter based on KEMAR impulse measurement for Pd
GNU General Public License v2.0
14 stars 1 forks source link

allow different HRTFs for each instance of earplug~ #1

Open umlaeute opened 3 years ago

umlaeute commented 3 years ago

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

the typical example used to be:

umlaeute commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

umlaeute commented 3 years ago

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

however:

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:

umlaeute commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

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

umlaeute commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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