Default values for mapper objects upon initialisation

[d.andrew STEWART]

Hello , Was there any discussion about adding a default value for mapper objects upon initialisation?

Example

[map.in /drwhosc/pitch f @unit na @min 0 @max 1 @def 0.5]

Thoughts?

D. An

[Joseph Malloch]

Hi Andrew,

We discussed this around 10 years ago when Marlon requested the feature, and we even had a development branch with the feature implemented. I’m definitely open to adding this, but there are some details that would need to be worked out first.

For your use case:

– when a new map is created from a source signal with default value, are you expecting the default value to cause an update at the destination?

– if a map has been updating a destination signal that was instantiated with a default value, and the map is then destroyed, are you expecting the signal to “revert” to the default value?

Cheers,

Joe

On May 26, 2022, at 18:45, d.andrew STEWART <dandrew...@gmail.com> wrote:

Hello , Was there any discussion about adding a default value for mapper objects upon initialisation?

--
You received this message because you are subscribed to the Google Groups "dot_mapper" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dot_mapper+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dot_mapper/c318ca0e-35aa-4319-a581-9bd4618fb7abn%40googlegroups.com.

[d.andrew STEWART]

Hi there.

Thanks, Joe, for these questions. After considering your questions, I now think it is best to maintain my current method - sending default values `after` mappings have been established. The defaults are sent externally – from messaging inside my Max patches.  This seems the best way to maintain a sort of modular-programming philosophy. In addition, one might argue that only mappings, for which a live signal is being used, are necessary; in other words, a default value is not really necessary because if a mapping connection is created, this means data is being sent. For parameters that are static, then we don't really need any mappings.  So, I withdraw my request.

On another topic: our SAT performance went well.  

Now that it's concluded, I'll update libmapper and webmapper.  I want to retype all of my [map.......]  to [mpr.....]  so that I'm using the most up-to-date naming/syntax.  Plus, I had some odd behaviour in Webmapper so I should update;  for instance, while setting ranges and , say, muting range boundaries, the number in the range field remains red (as if the field does not accept the input [after hitting return]).  The solution is to reselect the mapping connection and then , the range field accurately shows any changes.  In addition, `source` range modifications aren't saving correctly to the JSON mappings file. 

.....but, let me update everything and then, we'll see

My best

AAA