OSC mapping switches in VCS

Question

I've got a simple OSC wiring between Max and Kyma.  The event log in Kyma displays my correctly formed OSC messages /left/1 1   /left/1 0. So I know OSC messages make it to Kyma ok. Yesterday, everything was running smoothly. Today, I have made no changes and with no updates, but in the VCS, the OSC is remapped onto another OSC fader.  /left/1 becomes OSC_btn_4.  /left/2 becomes OSC_right_y.  ???  Anyone come across this mis-wiring within the VCS, and anyone recommend a fix?

This happened to me two weeks ago as well in a different patch, but now that this happened a second time, I smell performance trouble. Any help is appreciated.

Event Log: http://kyma.symbolicsound.com/qa/?qa=blob&qa_blobid=9382334849033868100

left/2/ as /right/y:  kyma.symbolicsound.com/qa/?qa=blob&qa_blobid=17598740359414721008

left/1 as btn/4: http://kyma.symbolicsound.com/qa/?qa=blob&qa_blobid=5548074014090672999

Comments

http://kyma.symbolicsound.com/qa/?qa=blob&qa_blobid=9382334849033868100 url went to the wrong image. This is the event log.

---

Restarting Kyma does not resolve. Restarting the computer does not resolve. Creating a new !OSC_left_1 fader inside a SoundToGlobalController correctly displays the mapping, but playing my Sound incorrectly maps the OSC messages. The entire Sound is incorrect. It's as if the Sound incorrectly builds the OSC mapping scheme regardless.  I'm uploading the Sound just in case.  http://kyma.symbolicsound.com/qa/?qa=blob&qa_blobid=16465612954033333279

---

Thanks, Jon.  Puzzling this out... more soon.

Answer 1

Here is a fixed version of your Sound that should have correct OSC mapping.

We have found and fixed the problem and will release an update to Kyma tomorrow after we have had a chance to test the fix.

Comments

Thank you SSC! You rock.