Register signal ops for op set 17.

[garymm]

Stack from ghstack:

• Register signal ops for op set 17. #11733 Register signal ops for op set 17.
• clang-format signal_defs.cc #11734 clang-format signal_defs.cc

Also:

• de-duplicate get_scalar_value_from_tensor
• fix some bugs that caused compilation errors with the experimental
  ops. Tested with build.sh --ms_experimental

[snnn]

@smk2007 we have a special build arg, "--ms_experimental", for enabling the audio ops. Does it mean that after this change we can remove the build arg from build.py?

[lgtm-com]

This pull request introduces 5 alerts and fixes 6 when merging 74dffcd into 0b7557f - view on LGTM.com

new alerts:

• 4 for Multiplication result converted to larger type
• 1 for Missing header guard

fixed alerts:

• 3 for Uncontrolled data used in path expression
• 2 for Uncontrolled process operation
• 1 for Unbounded write

[smk2007]

I think we should keep it for when microsoft needs to make experimental contrib op additions that are specific to the winml package. After this change i think it should persist until we are certain that we can deprecate, and customers have moved to onnx 1.12 audio ops.

---

In reply to: 1146453095

[smk2007]

public:

These need to be ported over as well, like the dft and other ops. They have been added to 1.12.

---

Refers to: onnxruntime/contrib_ops/cpu/signal/window_functions.h:26 in 74dffcd. [](commit_id = 74dffcd, deletion_comment = False)

[smk2007]

public:

Or is the intention to keep them as functions? Seems like these implementations would be faster..

---

In reply to: 1146478057

---

Refers to: onnxruntime/contrib_ops/cpu/signal/window_functions.h:26 in 74dffcd. [](commit_id = 74dffcd, deletion_comment = False)

[snnn]

I think we should keep it for when microsoft needs to make experimental contrib op additions that are specific to the winml package. After this change i think it should persist until we are certain that we can deprecate, and customers have moved to onnx 1.12 audio ops.

Then forever we would have the needs that someone wants an op that is in WindowsAI package but not in the macOS packages we provide. When the customer comes to us, then what should we do?

[smk2007]

I think we should keep it for when microsoft needs to make experimental contrib op additions that are specific to the winml package. After this change i think it should persist until we are certain that we can deprecate, and customers have moved to onnx 1.12 audio ops.

Then forever we would have the needs that someone wants an op that is in WindowsAI package but not in the macOS packages we provide. When the customer comes to us, then what should we do?

I believe that this namespace will be useful for platform specific (and or dependent) efforts, and will allow us to react to windows customers quickly. For cases where operators should truly be x-plat, i believe we would then begin the process to upstream them to onnx like we did with these audio ops.

[snnn]

I believe that this namespace will be useful for platform specific (and or dependent) efforts, and will allow us to react to windows customers quickly. For cases where operators should truly be x-plat, i believe we would then begin the process to upstream them to onnx like we did with these audio ops.

As they are not directly related to this PR, I will ping you next week and discuss it with you offline.

[smk2007]

IIRC we dont want to add contrib ops widely, so wouldnt x-plat folks have to go through that pain anyway right?

---

In reply to: 1146482654

[garymm]

Switching to #11778, sorry for the noise.