<div dir="ltr"><p dir="ltr"></p>
<div class="gmail_quote">On Jun 19, 2015 2:33 PM, "Hanspeter Portner" <<a href="mailto:ventosus@airpost.net" target="_blank">ventosus@airpost.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi<br>
<br>
So, I'm in need of an atomified representation of OSC [1] to route it:<br>
* from plugin to UI and back<br>
* from plugin to plugin<br>
* from plugin to host and back<br></blockquote><div><br>Coincidentally I was thinking about an application on this just this 
afternoon. Great that you've already gone this far with it.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Potential Issues<br>
================<br>
<br>
* The four exotic OSC types 'T'rue, 'F'alse, 'N'il, 'I'nfinitum have<br>
  no associated data in OSC. Should they be mapped to atoms and<br>
  packed into the arguments tuple or only show up in the message<br>
  format string like in OSC?<br></blockquote><div><br>I  think it would be best to match the osc method of having 
no data (and no atoms) for the T F I N types. It is not a lot of 
overhead to have a couple extra atom headers but why add it when the original spec doesn't have it?  Any existing code made to handle OSC messages would need extra modification to handle this difference.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* Even more exotic types 'c'har, 'S'ymbol and 'm'idi are seldom<br>
  used. 'm' type is special as it's four bytes only and first<br>
  byte represents a port number. So it's not fully up to the<br>
  definition of MIDI__MidiEvent.<br></blockquote><div><br>Just FYI In my OSC2MIDI utility we just ignore that first bit of a m type. Not sure if thats really the best but it was surely the simplest.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* It seems to be possible to send arrayed values with '['<br>
  ']', but I've never seen it used anywhere and can't figure<br>
  out how it's supposed to work. I guess it could be mapped<br>
  to a LV2_Atom_Vector, though.<br></blockquote><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Questions<br>
=========<br>
* Is the mapping that I've come up with sensible, stupid, ...?<br></blockquote><div><br></div><div>Looks good to me.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* Anybody else interested in OSC <-> Atom mapping?<br></blockquote><div><br>I've been thinking about it. I'd like to use OSC for microtonal control of synths. I'm curious if you have a plan for Chimera's note event message structure. I didn't notice any mention on your site. I read your postfix documentation. That is good, but it would be nice to come up with a default that could at hopefully be semi-standard for some interoperability between products.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  If so:<br>
  * Are the exotic types needed?<br></blockquote><div><br>I don't think I'll use the exotic types at all, but, as you said, its good to include them for completeness. <br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  * Something else missing?<br></blockquote><div><br>not that I can think of right now.<br><br><br></div><div>Those are just my initial thoughts. As I get deeper into an actual implementation I might have some other insights. Others hopefully can chime in with some more experience.<br><br></div><div>_Spencer<br></div></div>
</div>