Support For Other Parameter Types

[fundamental]

The type_osc_param hierarchy appears to be incomplete.
Currently it addresses "ihfdsb" where as the OSC 1.1 standard is composed of type classes "isbfhtdSrmcTFNI" (and the rather useless IMHO "[]").
Could the missing type classes be added to the schema?

[7890]

Adding more OSC types is foreseen, it's a goal to support / cover the full standard.

[fundamental]

Well, when you add param_c here's a sample input file http://fundamental-code.com/tmp/tmp2.xml
I would just submit a patch for some copy/paste to get this support, but I feel like there should be some way to eliminate the duplicate tags in the schema.

This subset of parameters might also start to give you a better idea of the enumerated paths which I mentioned on the ML.
I'm not entirely sure if the aspect tags you just introduced was supposed to help with or not.

[7890]

This is another interesting oschema instance i like to use as a test file. I take one of the messages:

<message_in pattern="/part0/kit0/adpars/voice7/VoiceFilter/Pvowels5/Pformants9/amp" typetag="c">
<desc>Set Value of Strength of formant</desc>
<param_c symbol="x"><range_min_max min="0" lmin="[" lmax="]" max="127"/></param_c>
</message_in>

It is absolutely legitimate to use enumerated paths that reflect the structure of the unit.
Both the unit and the client must be able to parse or construct these paths.
I'm trying to not judge on API design since a) i can not come up with good examples myself and b) there is no single right way. However one alternative would be to have something along:

<message_in pattern="/amp" typetag="is">
<desc>Set amplification</desc>
<param_i symbol="value"><range_min_max min="0" max="127"/></param_i>
<param_s symbol="context">
<desc>Context of /amp. Can contain patterns.</desc>
</param_i>
</message_in>

Your program could then even allow to map a context "/part0/kit0/adpars/voice*/VoiceFilter/Pvowels[4-8]/Pformants9" or similar to the respective components.
Another possible way would be to define such hierarchies using reusable aspects which is a concept not yet fully implemented.

So or so, the missing datatypes will be added..

[fundamental]

Feel free to use any section of any of the test files for your own uses.

As per the API design I grant you full rights to make fun of it if you like.
This is an exercise in retrofitting OSC onto a legacy codebase and as such, some things are going to end up somewhat silly/awkward/hodgepodge-y.

The aliases might make sense, but it does dodge the job of the oschema/oscdoc actually documenting the API in full (at least in my view) because the context is rather important.
This could be a sane workaround, but it does strike me as being a workaround which does leave a bit to be desired, though I will admit that I haven't done too much with API design beforehand.

If somehow the aspects or another bit of information makes defining "/part[0-7]/kit[0-15]/adpars/voice[0-7]/VoiceFilter/Pvowels[0-15]/Pformants[0-9]/amp" practical, it would be great.
While I don't really see this extreme case being too useful for other programs, I could imagine a more lightweight case of "/foo/osc1/" and "/foo/osc2/" occurring in a number of simple synths.

[7890]

If a lot is expressed in the path it would even be thinkable to have an XML dialect that allows any nesting of any elements to represent the structure of the program and then derive the message signatures from that and validate it somehow.

That said the process of creating an oschema document can be generative. If the unit has a large internal structure expressed in the path it could dump that as message_[in|out] rather than doing that by hand.

txl (https://github.com/7890/txl) has some support for templates, execution and include functions that would allow to define repetitive definitions in a more "human" way too.

We could see two sides, the side of defining things and the side of using the definitions.
On the defining side, we can put a whole chain of pre-processing to make it simple to define by hand or generate it somehow. On the reading side it should be easy to read "evaluated", say precise message signatures, that can be filtered by any means compared to evaluate input against a rule-based definition that every client would need doing. Still if rule-based definitions are used for a generative approach they are of interest to keep and include in the oschema instance for better clarity.

Using reusable aspects (mounting a set of messages of another oschema instance) is something that makes most sense for things that are reusable by other units. It can be used also for making the definition of a domain only of interest for one program easier, while i would see the generative approach as more convenient in that scenario.

Reusable aspects create a dependency hell as far as i can tell and break the above "evaluated/precise" rule to some degree. tools like oscdoc need to combine referenced aspects. This can be a timeconsuming task and a lot of things can go wrong.

I think one goal is that program clients can be served with a complete (currently valid) API definition of the described unit in a flat / linear to filesize speedy way while not loosing the abstract rule-based definition.

[7890]

For param_c, it will be an unsigned 8-bit char, decimal 0-255. Does make sense?

[7890]

also available now:
T, F, N, I

[fundamental]

The OSC 1.0 spec only indicates that "c" is an ascii character which only uses 7/8 of the bits, so the standard doesn't indicate if it is signed or not. That said, the code I have to handle it does treat it like a uint8_t.

[7890]

I would like to prevent any ambiguity. Most of the ascii char tables do not show a negative DEC value.
I hope it's right to assume "ascii char" implies it's unsigned, since there are ascii variants that go beyond 127. (this c type is a somewhat superfluous type anyway :)