Yes 👍 (although you don't have to code it to perform any function relevant to control messages, it could also just handle a signal only)

I'm not sure if you mean whether you want to distinguish from it in your own code, or if you're trying to distinguish objects created by others simply by looking at them or using them. Basically, if creating an object with only control messages, you don't need to distinguish at all in your code since people won't be able to connect signals to an object which accepts only control messages. If you want to distinguish this in your own code for the case of a single-inlet signal object, you can use the 'connection information' to detect whether a signal is connected or not and then create separate functions for the 'scalar' vs. 'signal' values: https://cycling74.com/sdk/max-sdk-8.0.3/html/chapter_msp_advanced.html#chapter_msp_advanced_connections If you are trying to distinguish by the look of objects in general, then there's no guaranteed way, but generally developers will try to give you helper information(for when you mouse over the inlet) which can display a pop-up telling you what's relevant there: https://cycling74.com/sdk/max-sdk-8.0.3/html/chapter_enhancements.html#chapter_enhancements_assistance

Furthermore, it's become an established style that signal objects will always be titled with a tilde: '~' after its name so that's the main way to distinguish whether an object would detect signals or messages(you probably already knew this, i'm just trying to be complete in my description since my comprehension of your question might be vague).

Apologies in advance if i've misunderstood, but a good way to learn writing externals is to create a non-signal object first then move on to creating signal objects and the ways to distinguish in code will become more and more apparent. A good thing to do is to start at the beginning of the index(see the left panel) here in the Max8.0.3(most current) SDK: https://cycling74.com/sdk/max-sdk-8.0.3/html/index.html and go down the list through each page/article in order from top to bottom. (If on the other hand, you're using C++ in the newer min-devkit, it might still be good practice to go through the C version(as this is how the original SDK and practices surrounding development in general formed), and then once getting down the basics(up just passed the Jitter chapters if you're also interested in Jitter, otherwise, stop right before them), and then study the min-devkit documentation here: http://cycling74.github.io/min-devkit/)

Also, you can often get more focused help on developing externals by posting under the 'Dev' category here on the forums(instead of the general, 'Max/MSP' one). Hope that helps.

I'm actually looking at the maxpatch JSON format, containing for instance a simple noise~ object.

noise~ documention says that if has "no argument", but the object has a single input (which can actually be connected with a signal or control input), and the JSON code is:

{ "box" : { "id" : "obj-1", "maxclass" : "newobj", "numinlets" : 1, "numoutlets" : 1, "outlettype" : [ "signal" ], "patching_rect" : [ 102.0, 89.0, 46.0, 22.0 ], "style" : "", "text" : "noise~" } } For what I see I can not distinguish this noise~ JSON code from an object that would process a single audio signal input and also have some control message (so using the same single input).

from outside it is always the same. and as you might know, for most objects which do not take float/int for something else at a signal inlet, sending a number into a signal inlet of an external usually multiplies the signal if a signal is present. but i would guess you can define it somewhere manually when developing externals, similar to "hot or cold".

Loogking at the JSON format again: there is this "outlettype" : [ "signal" ], line that does give a type to each outlet, but there is no equivalent fo inputs, why that?