Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

osc: allow re-sending of same values #105

Open
OddBloke opened this issue Dec 19, 2021 · 1 comment
Open

osc: allow re-sending of same values #105

OddBloke opened this issue Dec 19, 2021 · 1 comment
Assignees
Labels
backend Backend issues enhancement Improvements on existing features

Comments

@OddBloke
Copy link

osc_set in osc.c doesn't send output on a channel if the value is unchanged:

midimonster/backends/osc.c

Lines 735 to 746 in 1f31bc7

//only output on change
current = osc_parameter_denormalise(data->channel[ident.fields.channel].type[ident.fields.parameter],
data->channel[ident.fields.channel].min[ident.fields.parameter],
data->channel[ident.fields.channel].max[ident.fields.parameter],
v[evt]);
if(memcmp(&current, &data->channel[ident.fields.channel].out[ident.fields.parameter], sizeof(current))){
//update current value
data->channel[ident.fields.channel].out[ident.fields.parameter] = current;
//mark channel
data->channel[ident.fields.channel].mark = 1;
mark = 1;
}

This is a problem when integrating with REAPER's OSC implementation: they define a t trigger type (from this mirror of their default config):

# t: trigger or toggle message. The device triggers the action, or toggles the
# state, when the pattern is sent with no arguments, or with an argument of 1.
# The feedback values REAPER sends are identical to those sent for binary 
# arguments.

So: I can send the first trigger with no problem, but any subsequent triggering "1" values are never sent by osc.c.

(The workaround, at least for REAPER, is to send a 0 value before sending the trigger value: REAPER ignores any value but "1", but doing so invalidates the "cached" value in osc.c. It would be good to be able to avoid the extra messages over the wire.)

@cbdevnet
Copy link
Owner

cbdevnet commented Dec 20, 2021

Hi @OddBloke, thanks for this well-researched issue! Unfortunately it seems like Reaper is re-using the t OSC tag here, which is already defined by the OSC specification as time-tag - otherwise a solution might have been to simply implement these additional tags.

I'll need to think about a way to indicate that the event-deduplication should be disabled for specific OSC paths. I would not like to disable the deduplication globally, as that would cause a lot of events to be output when translating from backends that might not do their own event deduplication.

@cbdevnet cbdevnet added backend Backend issues enhancement Improvements on existing features labels Dec 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend Backend issues enhancement Improvements on existing features
Projects
None yet
Development

No branches or pull requests

2 participants