I encounter a weird behaviour which seems to be a bug to my opinion:
Let's consider a basic button in toggle mode, On = 1, Off = 0, receiving OSC at its value property: OSC{value, 0}. Indeed the button is supposed to be used either by pressing on it, but it can also be activated / deactivated by an external action sending an OSC value.
Let's say the button is ON, the external action sends 0 as an OSC value to set the button Off. Everything works as expected : The button seems to be Off due to its appearance.
However when I want to put it On again with the external action, sending this time 1 as an OSC value instead of 0, nothing happens. After many tests I understand that the inner value of the button has never been set to 0 with the previous action. As a result, sending 1 to a button with a value of 1 has no effect.
I found the following workaround : To put the button On I first send 0, then 1. Or to put it Off, I first send 1, and then 0. This is working out good, but as you understand I have to multiply by 2 the amount of OSC messages for this particular case, which is not optimal : 16 messages instead of 8 to bulk update the 8 buttons.
Have heard about a similar issue? I am happy to provide you more information if needed. I run the latest version 18.3
Let's consider a basic button in toggle mode, On = 1, Off = 0, receiving OSC at its value property: OSC{value, 0} . Indeed the button is supposed to be used either by pressing on it, but it can also be activated / deactivated by an external action sending an OSC value.
First of all, I don't recommend doing that, all widgets can have their value controlled simply by sending messages that match their address (and preArgs if any). Adding an OSC{} block in the value property looks overkill and error prone.
Now in this case, OSC{value, 0} first evaluates to 0 and it will not update the property that holds it unless its value change (ie: receiving 0 won't have any effect unless 1 was received before) , that may exaplain you issue (try with OSC{value, ""} instead).
Yes, I do not usually add optional OSC{} blocks whenever possible and with your remark I could remove 4 useless OSC blocks. Thanks for that.
Now, I tried many scenarios to solve my issue, but none of them including your suggestion adding the block OSC{value, ""} worked out properly. While I understand the root cause for a while, I cannot find a solution.
Can you have a look at the video below?
I am sure I missed a detail, maybe you can identify it.
Could you instead upload a minimal session file and step by step instructions to reproduce the issue that does not require using clyphx nor live (I'll be sending messages to o-s-c directly from a terminal and monitoring i/o from o-s-c's logs).
1- Hit the green button (Off) - It becomes yellow (On)
2- Hit the "Click to unmute" button below, which will send your OSC message to the yellow button (id: slave_button) to set it back Off, meaning green again.
3- Repeat
4- Repeat
None of the buttons are configured to send messages, looks like the session in incomplete.
Indeed none of the buttons are configured to send messages, as you requested. In my main o-s-c file, button targets are set to local ip 127.0.0.1, then routes to ClyphX. (Which for sure does not make sense for you)
If I manually send /slave_button 0 to o-s-c the button goes off as expected and I can toggle it back on without trouble.
In my video I show the following scenario : OFF - ON - OFF - ON then nothing happens anymore when sending OSC messages from the master to the slave buttton.
Did you repeat the process several times?
Did it work? If so, I am in trouble...
There are thousands of "ClyphX" OSC messages sent within a single live music session. I blind tested my last "release" yesterday night: 2 hours long at clicking, touching, turning, tweaking, muting and soloing etc... : ZERO issue. Therefore I understand that ClyphX knows how to send a simple OSC message.
Also for some weeks I had to convert all my "toggle" knobs into "tap" or "push" or "momentary" just because of the issue I just reported to you. It required to send the right color(s), label, on/off, value, or whatever parameter just to emulate the behaviour of a native toggle button. This multiplied extremely the amount of OSC messages, so I came back into that critical subject. As you know, when you hit a button, you expect an immediate response. Which is of course not the case when a button or any other widget requires an OSC answer from a remote server, before doing what it needs to do.
No worries, I found a (dirty) solution. Not that dirty, it works, and it is instant. All I wanted you to know is that there is most probably a problem with o-s-c buttons in toggle mode, remotely controlled by OSC messages. Up to you to investigate, or leave it as is.
Benoît Henriot
Lead Dev Architect and Senior Systems Engineer
I'm sorry but there's nothing I can investigate without a proper reproduction case, what could help are the log from osc's server during the last video you sent, so that I can figure out what messages where sent/received exactly.
On a side note, you might be interested in the decoupled mode for buttons that landed in v1.18.
Button decoupling is a great feature, but unfortunately not applicable to my current use case.
I've created a video where I deep dive into the issue. Hopefully this is helpful for you to investigate further. Should you need more details just let me know. Put the sound on, thanks.
Thanks for the video. It is however a perfect demonstration that the problem (at least for this particular setup) doesn't lie in open stage control : the debug logs in the console show that /slave_button is not sent back by clyphx when it receives /master_button with the same value it received the time before (which actually makes sense as this feedback could be considered useless depending on how that state is handled on clyphx' side). It has nothing to do with how the toggle's state is managed, the "(DEBUG, OSC) In" messages show what's received by osc, no matter if there's a widget to consume the message or not.
Not related: there is a well spread confusion about how osc ports work in general and how they should be configured. In your video I see that clyphx is listening on port 8000, and it appears you've set open stage control's port option to 8000 and osc-port to 7005 (clyphx default listening port if I'm not mistaken), it does seem like some relation between these options is expected so I feel I must clarify what these actually do :
port defines open stage control's http port (not related to osc messages, it just affects how you access the app from a remote browser)
osc-port defines open stage control's listening port for osc messages (if not set the osc-port options would simply take the same value as the port option)
In most case, setting only the port option is fine as will define both http and osc ports, in any case it doesn't make much sense to set any of these options to the listening port value of of another application.
Button : That makes sense. I was far from figuring out that ClyphX does OSC message filtering. When a message is supposed to be sent, I need it to be actually sent regardless of previous message address and values.
which actually makes sense as this feedback could be considered useless
I agree but in this case, all values supposed to be sent are useful. I will need to get a clear picture of ClyphX behaviour in terms of OSC messages optimisation or filtering. For now I'll stick to my workaround which appears to be the right way to handle that problem.
Ports : Good to know. In my configuration ClyphX listens on port 8000 (same as o-s-c default destination port) and replies to port 7005, from a dynamic port.
I removed the osc-port option as I'm fine with http and osc trafic on the same port. Then I just updated port to 7005 and good is.
Thanks for your time. I'll let you know if the ClyphX OSC message "filtering" mechanism is either a bug, or a feature..
ClyphX Pro is a virtual control surface for Ableton Live, allowing you to control, automate, orchestrate the DAW via a bunch of built-in or self made actions, including OSC capabilities.
I develop my own looper using 4 MIDI keyboards with 2 virtual instruments on each, plus 4 tracks piano and microphone tracks. For 2 months I started to extend the project with OSC to get pristine visual feedbacks and add useful features - It is getting really cool ! I'll create a video presentation of the system in a couple of weeks, hopefully before Christmas
No OSC involved here yet, but still :
The link you sent is based on the free ClyphX Version, prior ClyphX Pro and apparently made compatible with Live 10 and even 11. If I were you I would not even try to download it... feedbacks are terrible. If you're interested in the long-awaited official Live 11 compatibility, note that it will be out very soon.
@jean-emmanuel Back to the initial topic, I got a clarification from ClyphX.
As you understood, an OSC message supposed to be sent again will be ignored. Indeed, ClyphX will already send the same message again at a pre-defined refresh rate (default = 500 ms), to overcome dropped packages. No wonder that all future identical messages will not be sent.
As OSC is not yet a standard feature in ClyphX, just an experimental one, there are still no options to force OSC messages to be sent. So the workaround I found is the only valid one, and I apologize for the wrong analysis, and for the time wasted.
