Discussion:
unknown
1970-01-01 00:00:00 UTC
Permalink
My impression is that there are a number of "cleanups" that can be made
to clarify the OSC 1 spec that would benefit interoperability of the
existing and future installed base. One example raised in this thread
was clarifying UTF8 as the standard string character format. I imagine
there are others. Presenting this and other previously released
information in a formal specification document is desirable.

I understand and agree that there are certain shortcomings and technical
limitations in the OSC 1 design (4 byte alignment is my pet hate).
However, OSC 1 has proved quite useful and it would be a shame to
abandon it at the height of its popularity.

I understand there are resource issues at CNMAT, and please correct me
if I'm wrong, but observing from the outside you appear to be saying "we
don't care about supporting and nurturing the large installed base of
OSC 1 applications, frameworks and devices, we're just going to get on
with our future looking research agenda and make a
non-backward-compatible OSC 2.0." This does not always end well.

Although I can see that prioritising OSC 2.0 makes sense from a research
perspective, it doesn't make much sense to me as an OSC 1 user. My
impression is that OSC 2.0 is currently at-best a research project, with
no installed base and no obvious leverage to community/market acceptance
(except perhaps for being called OSC). Sometimes near-enough is
good-enough and technical superiority is not sufficient to ensure
success. As a developer I know how easy it is to see the flaws and want
to move on to the next, better, improved implementation. And of course
it is more exciting to work on a new fresh project than the old one.
While I support work towards OSC 2.0, I think it is equally important
that the OSC 1 spec is maintained and nurtured at least until such time
as OSC 2.0 is out in the wild with multiple implementations.

If CNMAT is unable to provide ongoing support for OSC 1 perhaps members
of the community could be authorised to produce a maintenance release of
the OSC 1 spec?

Please let us know what you think.

Thank you

Ross
About a year ago I started drafting an OSC 2.0 document, similar format to 1.0 but not 100% backwards compatible, ABNF grammar-based, and having a type system and type meta-data descriptors based on ISO/IEC 11404:2007.
void (N)
bit int 1 (0)
signed bit S1 (1)
int S7 (c)
int S15 (u)
int S23 (a)
int S31 (i)
int S63 (h)
int S127 (j)
unsigned int 8 (C)
unsigned int 16 (U)
unsigned int 24 (A)
unsigned int 32 (I)
unsigned int 64 (H)
unsigned int 128 (J)
fixed-point S7.8 (p)
fixed-point S15.16 (v)
fixed-point S23.24 (w)
fixed-point S31.32 (x)
fixed-point S63.64 (y)
fixed-point S127.128 (z)
unsigned fixed-point 8.8 (P)
unsigned fixed-point 16.16 (V)
unsigned fixed-point 24.24 (W)
unsigned fixed-point 32.32 (X)
unsigned fixed-point 64.64 (Y)
unsigned fixed-point 128.128 (Z)
float 16 (e)
float 32 (f)
float 64 (d)
float 128 (q)
Fixed-length composite type modifiers
dyad (2)
quad (4)
octet (8)
16-tet (E)
32-tet (F)
64-tet (D)
128-tet (Q)
interval pair (-)
complex pair (+)
complex circular interval (*)
utf-8 string (s)
binary section (b)
dense vector (|)
sparse vector (:)
dense matrix (%)
unlimited unbounded int n (_)
unlimited unbounded fixed-point n.n (.)
list ([])
object ({})
---
Andy W. Schmeder
email: andy [at] cnmat.berkeley.edu
skype: andy.schmeder
Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
Continue reading on narkive:
Loading...