1 Topic by David-san (edited by David-san 2023-12-31 13:48:14)

  • Registered: 2014-08-14
  • Posts: 29

Topic: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

Dear RME support,

It was a very nice idea to implement “cue” messages in TM FX OSC Page 1, but there are two situations where TM FX doesn’t answer properly to the OSC controller.

1) When a TM FX output channel “n” (with “n” representing id of this channel) has Cue/PFL assigned to it, it doesn’t make sense to select CUE for this channel. When a user tries to do it in TM FX, Cue is shortly selected and immediately unselected and that’s right. However this is not done properly when controlling TM FX using OSC.
- if “/1/cue/1/n 1.0” is sent to TM FX, it should send back 0.0 to the cue address for ALL channels to keep the sync with TM FX (0.0 is currently not sent for channel “n” which has the Cue/PFL assigned to it such that it appears to be selected for Cue in the OSC controller.

https://i.ibb.co/wNF6Mjx/IMG-8239.png

- if “/1/cue/1/x 1.0” is sent to TM FX (with “x” the id of a different channel than “n”), “/1/cue/1/n 0.0” should be sent back to set the OSC controller interface correctly (it is currently not done such that channel “n” which shouldn’t be selected at all, stays visually selected in the OSC controller even after selecting another Cue)

https://i.ibb.co/D9nHC0c/IMG-8240.png

2) When a TM FX output channel “b” (with “b” representing the channel id) has Main Out B assigned to it, it is not possible to select CUE for this channel, CUE can only be selected for the Main Out. However when controlling TM FX with OSC, selecting CUE for Main Out B works and un select Main Out. If the audio result will be the same, this behavior is confusing. A solution could be to select both Main Out and Main Out B by sending  “/1/cue/1/a 1.0” and “/1/cue/1/b 1.0” to the OSC controller or alternatively “/1/cue/1/a 1.0” and “/1/cue/1/b 0.0” (to keep only Main Out selected for Cue while Main Out B would be unselected (here “a” is the channel if of Main Out and “b” the channel of Main Out B).

Please consider also the situation, where Main Out receives the CUE and Main Out B is assigned…

Could it be possible to modify the current OSC implementation in TM FX such that at least 1) or better 2) could be improved?

Best regards,

David

  • Registered: 2014-08-14
  • Posts: 29

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

Neither an answer, nor a reaction?…

  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 473

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

Maybe i didnt get it…
What do you mean with „slice“?

“Do It For Her”
My Gear: Bontempi Magic light Keyboard
  • Registered: 2014-08-14
  • Posts: 29

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

This is a literal bad translation. I'm not an English native speacker, sorry. Please understand "channel". I just changed that in my post.

5 Reply by MC

  • MC
  • MC
  • Administrator
  • Offline
  • From: Germany/Thailand
  • Registered: 2007-04-06
  • Posts: 25,599

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

We have put this improvement request on our list for TM FX 1.86. Thanks for the detailed explanation.

Regards
Matthias Carstens
RME

MC's Website

  • Registered: 2014-08-14
  • Posts: 29

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

So thank you very much, and I am looking forward to the 1.86 release of TM FX.

  • Registered: 2018-05-01
  • Posts: 76

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

@ David-san: TM 1.86 has been released since a while :-)
Look here.

soundflix's Website

8 Reply by David-san (edited by David-san 2023-12-26 20:02:10)

  • Registered: 2014-08-14
  • Posts: 29

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

@soundflix, I thank you I thought it was only 1.86 beta 1, but you are right it is 1.86. But unfortunately, the OSC issue I described in this topic is not yet fixed in this version.

Perhaps in TM FX 1.87?

  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 473

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

1.90b1 is the most recent beta afaik (but seems to only affect the UFXes):

https://forum.rme-audio.de/viewtopic.ph … 43#p210543

“Do It For Her”
My Gear: Bontempi Magic light Keyboard

10 Reply by MC

  • MC
  • MC
  • Administrator
  • Offline
  • From: Germany/Thailand
  • Registered: 2007-04-06
  • Posts: 25,599

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

Unfortunately we did not find the time yet to take care of this, sorry. It is also not changed in the upcoming 1.92 (soon).

Regards
Matthias Carstens
RME

MC's Website

11 Reply by David-san (edited by David-san 2023-12-28 12:19:38)

  • Registered: 2014-08-14
  • Posts: 29

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

Well, if it is still on the list, I will keep on waiting ;-)

12 Reply by MC

  • MC
  • MC
  • Administrator
  • Offline
  • From: Germany/Thailand
  • Registered: 2007-04-06
  • Posts: 25,599

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

2 has been changed (Cue not sent to Speaker B), but 1 we can not reproduce. Cue selection works perfectly with our template and TouchOSC. There is no hanging or remaining Cue.

Regards
Matthias Carstens
RME

MC's Website

13 Reply by David-san (edited by David-san 2023-12-31 15:51:06)

  • Registered: 2014-08-14
  • Posts: 29

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

MC wrote:

2 has been changed (Cue not sent to Speaker B), but 1 we can not reproduce. Cue selection works perfectly with our template and TouchOSC. There is no hanging or remaining Cue.

I first encountered this OSC issue using the Gig Performer plugin host scripting langage. So, I bought TouchOSC and installed your TM FX template and  I'm afraid I have to disagree with you. I updated my original topic with screenshots which show that it behaves exactly as described.

In particular, if you send /1/cue/1/3 1.0 from TouchOSC (3 is the index of Phone2 which has CUE/PFL assigned to it) TM FX doesn’t send /1/cue/1/3 0.0 back such that this particular cue stays set in TouchOSC (which of course doesn’t make sense).

Then, if you send /1/cue/1/1 1.0 from TouchOSC, TM FX sends /1/cue/1/1 1.0 back, but not /1/cue/1/3 0.0, such that the cue on Phone2 still stays on in TouchOSC.

Could it be that during your test, your didn’t assign the CUE/PFL to the channel on which you selected the cue?

  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 473

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

David-san wrote:

I first encountered this OSC issue using the Gig Performer plugin host scripting langage. So, I bought TouchOSC and installed your TM FX template and  I'm afraid I have to disagree with you. I updated my original topic with screenshots which show that it behaves exactly as described.

In particular, if you send /1/cue/1/3 1.0 from TouchOSC (3 is the index of Phone2 which has CUE/PFL assigned to it) TM FX doesn’t send /1/cue/1/3 0.0 back such that this particular cue stays set in TouchOSC (which of course doesn’t make sense).

Then, if you send /1/cue/1/1 1.0 from TouchOSC, TM FX sends /1/cue/1/1 1.0 back, but not /1/cue/1/3 0.0, such that the cue on Phone2 still stays on in TouchOSC.

Could it be that during your test, your didn’t assign the CUE/PFL to the channel on which you selected the cue?

Regarding to your screenshots, you use the "new" TouchOSC generation on a Mac or PC.
There is also a "TouchOSC MK1" version which is available for iOS/Android only.



As hexler explains https://hexler.net/touchosc-mk1:

PLEASE NOTE: This is the product page for the Mk1 version of TouchOSC. This version is well suited for low-powered and older devices and will be maintained for the foreseeable future, but no new features will be added.

If you look at the extension, the provided template by RME, is ".touchosc". This means, it's a Mk1 file. While the new generation Files always have the ".tosc" extension.

So, although you can open the Mk1 files in the new gen TouchOSC, it automatically adds some stuff/code (which seems not to be documented by hexler). But you cannot open a .tosc file in Mk1. That means, that the two versions are not behaving same.



So... MC is right. The template works without any problems with Mk1 on my iOS clients (current TotalMix FX 1.93, here: https://forum.rme-audio.de/viewtopic.php?id=38691)



And... i think it makes sense to answer your other topic here and link it to this thread
I mean your question in https://forum.rme-audio.de/viewtopic.php?id=38671 relies on the same fact that the newer TouchOSC version adds all the things like visibility, position, size, color, scripting (and more) just by opening the template with standard settings. And acts different then the MK1 Version.

You should uncheck the following before opening the original template:

In Preferences - Import in "Control OSC Messages" section:
Touch /z
Visibility /visible
Position /position/x,y
Size /size/w,h
Color /color

In the Preferences - Editor Tab, uncheck these:
Create default MIDI messages
Create default OSC messages

After opening the Template:
- select the green cue grid in the Editor, and change the button type from "Toggle.." to "Momentary"
- and in the Messages -- OSC /1/cue/1/x  -- in the Trigger Row, let the x highlighted, but change its behaviour from "ANY" to "FALL"

-> This results that all the cue Buttons send a f1 value to TM at the moment you click on them, but only get highlighted if they get a feedback from TM with value f1. Otherwise they stay off...

“Do It For Her”
My Gear: Bontempi Magic light Keyboard
  • Registered: 2014-08-14
  • Posts: 29

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

Indeed, I used TouchOSC mk2 for this test, but on an iPad. And I can confirm that the template modification you suggest as a workaround works well. I don't have TouchOSC mk1 and I trust you if you say that the template for this version prepared in the same way as the one you suggest works.

Your solution works because it's possible to set a cue to "1" by sending it "0".
Clearly for:
/1/cue/1/1 0
TM FC responds:
/1/cue/1/1 1
Honestly, I couldn't find your workaround because I'd never have thought that a cue could be activated by sending it 0.

You also need to configure a controller button in "momentary" mode that sends no information when rising, but only when falling. Unfortunately, most controllers cannot be configured in this way. If you're lucky, you can configure them to momentary or toggle (lock) mode, but they almost always emit a 1 when activated and a 0 when released. Never (or let's say, ultra-rarely, TouchOSC being an exception) can they be configured to emit only a 0 on release.

It would not seem unreasonable to ask that if we send the following OSC command with n receiving the cue/PFL:
/1/cue/1/n 1 or /1/cue/1/n 0
then TM FX would respond
/1/cue/1/n 0
rather than nothing at all.

16 Reply by maggie33 (edited by maggie33 2024-01-15 07:08:31)

  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 473

Re: [Bug Report] TM FX OSC issue regarding the “/1/cue/1/#” messages

David,

I am not an TouchOSC Expert. I only use it from time to time to test some OSC stuff (like your "issue" f. ex)

you say that the template for this version prepared in the same way as the one you suggest works

All I said, is, it works with Mk1 version (i bought a long time ago) on my iOS Devices.
My suggested workaround is just the result of playing with the possibilities in Mk2. More a trial and error... Just because I like to learn more about OSC, in general. It is (and was) never meant to be a 1to1 conversion from MK1 to Mk2.

Unfortunately, most controllers cannot be configured in this way. If you're lucky, you can configure them to momentary or toggle (lock) mode, but they almost always emit a 1 when activated and a 0 when released. Never (or let's say, ultra-rarely, TouchOSC being an exception) can they be configured to emit only a 0 on release.

You deviate from the original topic here. How other controllers behave or what capabilities they have - its up to the individual creators/developers. The OSC specification does not cover the behavior of any controls like buttons grids, etc...

It would not seem unreasonable to ask that if we send the following OSC command with n receiving the cue/PFL:
/1/cue/1/n 1 or /1/cue/1/n 0
then TM FX would respond
/1/cue/1/n 0
rather than nothing at all.


So... to be clear: What you propose is that TM always should feedback an answer, right?...
Sorry, but I do not agree with this. From logic view, Totalmix behaves exactly as it makes sense. Because it only accepts/feedbacks Messages, which are currently accessible/modifiable or lets say "active". Especially if "your" n from your suggestion above is currently affecting MainOut or SpeakerB.

If TM would act straight forward, as you proposed, it would also send feedbacks for every message - lets say channel 18.. Even if you configured 12 channels for the current osc controller slot? Sure - It should not. But how to define global rules?
Just one example...


Example Szenario:

- The OSC Controller is set to 12 Channels in TM
- AN1/2 is assigned to MainOut
- AN3/4 is assigned to SpeakerB

  • SpeakerB disabled

TM whether reacts on nor sends any feedback if you send a "Cue OSC" message  from the controller to it for Channel AN1/2 (because its the MainOut) - as you already told: makes no sense
TM whether reacts on nor sends any feedback if you send a "Cue OSC" message to it  from the controller for Channel AN3/4 (because SpeakerB can only be linked)

  • SpeakerB enabled

TM reacts and sends feedback if you send a "Cue OSC" message  from the controller to it for Channel AN1/2 (because its the MainOut). It also sends a f1 if you click the cue in TM.
TM whether reacts on nor sends any feedback if you send a "Cue OSC" message to it  from the controller for Channel AN3/4 (because SpeakerB can only be linked)

So the basic logic in this "cue"-usecase is quite simple, regardless of any other implementations:
- Send a value from the contoller to TM when a button (or other control) is pushed
- Only enable (or light up) it, if the value f1 is received from TM


David, i just wanted to help, or give you some hints... Just try out yourself and experiment with your controller(s) yourself. Would be nice if you find and share a suitable solution (for Mk2) here!

Sure, TM is not perfect. I agree, it should not react for received f0 values. But that is not really a game changer or a bug. Maybe RME had their reasons to implement this as it is?

“Do It For Her”
My Gear: Bontempi Magic light Keyboard