8 Jul
2014
8 Jul
'14
6:48 p.m.
Hi,
i would like to announce some tools around OSC.
oschema: a format definition to describe OSC units
https://github.com/7890/oschema
oscdoc: create HTML documentation from oschema instances
https://github.com/7890/oscdoc
txl: a simplified text format that can be translated to XML (and vice versa)
https://github.com/7890/txl
Basic idea:
-Having a standardized, machine-readable format to describe an OSC API
-Derive "stuff" from description, like documentation, code skeletons etc.
-Let programs use OSC API dynamically by looking at definition
Proposed workflow:
-Write OSC API definition using txl (optional)
-Convert txl to XML (optional)
cat my.txl | txl2xml > my.xml
-Use post-processing chain for desired output (i.e. oscdoc)
oscdoc my.xml /tmp/mydoc
If i got your attention, please get a quick overview before cloning here:
http://lowres.ch/oschema/oschema.html (oschema documentation)
http://lowres.ch/oschema/oschema.svg (interactive structure)
http://lowres.ch/oscdoc/unit.txl (an example txl file describing an OSC unit)
http://lowres.ch/oscdoc/unit.xml (corresponding XML file, oschema instance
document)
http://lowres.ch/oscdoc/index.html (output of oscdoc)
Please let me know when you find anything unclear or missing.
Have nice day
Tom
9 Jul
9 Jul
4:41 a.m.
On Tue, Jul 08, 2014 at 06:48:33PM +0200, tom(a)trellis.ch wrote:
i would like to announce some tools around OSC.
oschema: a format definition to describe OSC units
https://github.com/7890/oschema
oscdoc: create HTML documentation from oschema instances
https://github.com/7890/oscdoc
Basic idea:
-Having a standardized, machine-readable format to describe an OSC API
-Derive "stuff" from description, like documentation, code skeletons etc.
-Let programs use OSC API dynamically by looking at definition
I would certainly have to make use of the toolset in order to really gauge how
well it accomplishes the goal, but IMHO that's a rather basic idea.
Most of the OSC tools that have come up on my radar have run on the assumption
that the API is known a priori or that it is established through some means of
runtime communication.
Providing a nicely serialized API specification would certainly seem to help
with one of OSC's major flaws.
Right now the example seems to be pretty small and it would be nicer to judge it
based on a larger API.
Depending on how well this system can handle enumerated paths, it might be
interesting to see what an exported version of zynaddsubfx's librtosc based API
might look like as interactions via a debugging curses tool have been making
dynamic API queries so far (this would be a much more sizable test/stress case).
(enumerated paths being /foo/bar1/ /foo/bar2/ /foo/bar100/)
There was some reference to patterns, but at first glance they didn't quite look
applicable.
--Mark
3:22 p.m.
Hi Mark
On Wed, July 9, 2014 04:40, Mark D. McCurry wrote:
On Tue, Jul 08, 2014 at 06:48:33PM +0200,
tom(a)trellis.ch wrote:
i would like to announce some tools around OSC.
oschema: a format definition to describe OSC units
https://github.com/7890/oschema
oscdoc: create HTML documentation from oschema instances
https://github.com/7890/oscdoc
Basic idea:
-Having a standardized, machine-readable format to describe an OSC API
-Derive "stuff" from description, like documentation, code skeletons
etc. -Let programs use OSC API dynamically by looking at definition
Right now the example seems to be pretty small and it
would be nicer to
judge it based on a larger API.
true.. we have to start somewhere. It takes some time to have a couple of
good example definitions, and i'm sure it will reveal missing bits. I'm
interested to hear your experience.
(enumerated paths being /foo/bar1/ /foo/bar2/
/foo/bar100/)
There was some reference to patterns, but at first glance they didn't
quite look applicable.
There is currently nothing foreseen to handle that kind of redundancy.
Still it's possible to describe such messages. To me it looks like a
/foo/bar i would be easier to handle. I wouldn't go so far and say that
kind of API (enumerated path') is just not well designed.
Cheers
Tom
14 Jul
14 Jul
12:41 a.m.
On Wed, 2014-07-09 at 15:22 +0200, tom(a)trellis.ch wrote:
[...]
To account for things like this, a good schema would need to detach the
paths from the "support", then provide a mechanism to match the two
based on path patters.
So, you could say things like:
control_support = "<path> supports '<path>/control f'
messages"
then "any path that matches '/knobby_bits/*' supports control_support"
or something along those lines. Then apps with a bunch of dynamic paths
that all follow a common control scheme are fine.
Disclaimer: Knee-jerk response, I haven't read the schema
--
dr
(enumerated
paths being /foo/bar1/ /foo/bar2/ /foo/bar100/)
There was some reference to patterns, but at first glance they didn't
quite look applicable.
There is currently nothing foreseen to handle that kind of redundancy.
Still it's possible to describe such messages. To me it looks like a
/foo/bar i would be easier to handle. I wouldn't go so far and say that
kind of API (enumerated path') is just not well designed.
7:14 p.m.
On Mon, July 14, 2014 00:41, David Robillard wrote:
On Wed, 2014-07-09 at 15:22 +0200, tom(a)trellis.ch
wrote:
[...]
To account for things like this, a good schema would need to detach the
paths from the "support", then provide a mechanism to match the two based
on path patters.
So, you could say things like:
control_support = "<path> supports '<path>/control f'
messages"
then "any path that matches '/knobby_bits/*' supports control_support"
or something along those lines. Then apps with a bunch of dynamic paths
that all follow a common control scheme are fine.
David, that's an interesting idea!
If there is an existing definition say for 'OSC Transport Control' that
provides semantics for the topic it could be re-used by other OSC units
that share this aspect. Definitions of such units could reference existing
definitions and sort them in at any path (preferably as a non-mixed
subtree).
Example:
/my/path/logic
/osct/<all appearing below is following 'OSC Transport Control' semantics,
defined <here>>
This would allow to re-use commonly used aspects. It's to some degree
comparable to XML namespaces.
oschema is ready to describe re-usable aspects. Missing is a way to
reference existing such definitions within others and pin to a place in
the tree. (notated)
Another thing brought up was discovery. It would be thinkable that one
defines this as an aspect of an OSC unit. Units referencing that aspect
would for instance send back the definition as a serialized blob when
pinged with <possible prefix>/describe. This is just an example not fully
thought trough.
Little focus was given to dynamic APIs which might be wrong.
A classical API of a compiled program / library is quite static.
Interpreted programs can have dynamic APIs, i.e. methods added or removed
at runtime. So both are possible and have their merit.
An example to mention is when the path of the messages reflect a
dynamically built hierarchy of things. If the API is dynamic (where the
variable parts are not limited to the "args" of pre-defined static
messages) so could be the definition. If we have rule-based APIs with
either many similar or infinite possible forms a message can take, we
loose the benefit of a concrete lookup set of messages. On the other hand
there should be a way to express a catch-all handler similar to /* etc.
This needs more thinking, input is welcome.
--
Thomas
(enumerated paths being /foo/bar1/ /foo/bar2/ /foo/bar100/)
There was some reference to patterns, but at first glance they didn't
quite look applicable.
There is currently nothing foreseen to handle that kind of redundancy.
Still it's possible to describe such messages. To me it looks like a
/foo/bar i would be easier to handle. I wouldn't go so far and say that
kind of API (enumerated path') is just not well designed.
3782
days inactive
3788
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
David Robillard -
Mark D. McCurry -
tom＠trellis.ch