Currently, assigning conductance instances to particular channel combinations, particularly in the case of model prototype channels, is handled during clamp setup by implementation-specific ConductanceProxy::instantiate(). As a result, the UI is blind to multiplexing and can't present multiplexed conductances e.g. for plotting. Furthermore, while multiplexed conductances can be data-saved and are indexed with unique multiplex_ids, no information is exposed about the relationship between multiplex_id and model instances.
It would be preferable for multiplexing to be a function of AssignmentData and its descendants. While this admittedly muddles the separation of data and functionality, it would open multiplexing to UI access, as well as provide a convenient and logical place to add information about instantiated (multiplexed) assignments. Besides, this facility could be used to provide finer-grained control over multiplexing without overburdening implementations of ConductanceProxy::instantiate.
Currently, assigning conductance instances to particular channel combinations, particularly in the case of model prototype channels, is handled during clamp setup by implementation-specific ConductanceProxy::instantiate(). As a result, the UI is blind to multiplexing and can't present multiplexed conductances e.g. for plotting. Furthermore, while multiplexed conductances can be data-saved and are indexed with unique
multiplex_ids, no information is exposed about the relationship between multiplex_id and model instances.It would be preferable for multiplexing to be a function of AssignmentData and its descendants. While this admittedly muddles the separation of data and functionality, it would open multiplexing to UI access, as well as provide a convenient and logical place to add information about instantiated (multiplexed) assignments. Besides, this facility could be used to provide finer-grained control over multiplexing without overburdening implementations of ConductanceProxy::instantiate.