QL1 testing of Yamaha-SCP module v1.3.5c

Hi Andy
I’ve been playing with your new version 1.3.5 - good job, v.impressed. :slight_smile:

Few things to report:
InCh/Label/Icon - The icon field needs a dropdown list of available icons to use.

OmniOutPort/Patch, InCh/Patch, DanteOutPort/Patch and DigitalOutPort/Patch - All Patch fields either need a dropdown list of available patch options - or - checkboxes maybe (Checkboxes allow for multiple choice), because patching/routing is not always exclusive to a single physical connection, you can have a mix goto more than one physical output be it Omni and/or Dante.

InCh/ToMix and ToMtrx/PrePost - Whats the meaning of the “On” option? Is it Pre On or Post On? Could you maybe change this “On” option to a couple of Radio buttons labeled Pre and Post. (Radio buttons only allow for an either/or option)

And now for a few requests… :slight_smile:

Can you add more than one “MyChannel” - ie. I’d use a min of two, one for my Mons Mic “MyChA”, and one for the FOH TTS mic “MyChB”.
But then I got to thinking about the shout system, and how it would be nice to get rid of two Mics at FOH too? So I simply get a single mic signal from FOH - (either through DANTE of an analogue patch - either way it ends up down in MONs world) which I then either route to My little shout speaker or my cue wedge using button x.24 in my attached config file. So this would utilise the second “MyChB” for an input, now if only I could set a DIRECT output via SCP then I could eliminate having to use Mixes/Mtrx for the shout outputs.

“Conditional Options”. So rather than using companions “Latch/Toggle” feature, is there a way of actually using the feedback system to control the options of a function based on what the current state of a particular button is on the desk. i.e. If Mix1 is already ON, then my TTS MIX 1 button needs to turn Mix1 OFF when I first press it. With the current settings, you’d need to press it twice!

As I don’t actually have a desk sat next to me at the moment for real time testing - How would the feedbacks that I’ve set on my Mons and FOH TTS On/Off buttons work (x.23 & x.31) - which one would have preference - the last I presume?

Lastly - how’s it going getting companion to talk with CL/QL editors? I saw you were having a little chat about it in Slack.

v1.3.5c? That was quick! I just put it up last night.
Thank you for your kind words. I think what you’re doing with it is a really cool use-case. I can imagine a scenario where each player has their own SD and can use it to talk to specific players or all or mute their instruments, all kinds of cool stuff. Now, likely, it could be done easier using Yamaha’s Visionaire, but that’s not nearly as cool. :wink:

Few things to report:
InCh/Label/Icon - The icon field needs a dropdown list of available icons to use.
So YOU’RE the guy that actually changes the Icons on the channels? I’ve never bothered!
So, I could do that dropdown, but know that I’m not about to implement something that draws the icons on the keys. If someone is super keen on that, they can come up with the appropriate png files and maybe then I’ll look into it. :wink:

OmniOutPort/Patch, InCh/Patch, DanteOutPort/Patch and DigitalOutPort/Patch - All Patch fields either need a dropdown list of available patch options - or - checkboxes maybe (Checkboxes allow for multiple choice), because patching/routing is not always exclusive to a single physical connection, you can have a mix goto more than one physical output be it Omni and/or Dante.
I’ll have a look. Wasn’t thinking that folks would really do that much patching using the SD, but I guess if the command is there it should at least be useful!

InCh/ToMix and ToMtrx/PrePost - Whats the meaning of the “On” option? Is it Pre On or Post On? Could you maybe change this “On” option to a couple of Radio buttons labeled Pre and Post. (Radio buttons only allow for an either/or option)
The action choices are created programmatically. If the command has a toggle, it becomes On/Off in the action. That means the wording may not always match. It does for things like channel on/off, others aren’t so clear.
InCh/ToMix: ON means that channel’s send to that mix is ON. OFF Means not. It looks like you’re using that option on your TTS buttons. Not sure why you also have the InCh/ToMix/Level adjusted as well?
ToMtrx/PrePost: Likely ON means Post, but it would need to be checked on the console. Like you, I don’t have a console to test.

And now for a few requests… :slight_smile:

Can you add more than one “MyChannel” - ie. I’d use a min of two, one for my Mons Mic “MyChA”, and one for the FOH TTS mic “MyChB”.
I’ll look into that.

But then I got to thinking about the shout system, and how it would be nice to get rid of two Mics at FOH too? So I simply get a single mic signal from FOH - (either through DANTE of an analogue patch - either way it ends up down in MONs world) which I then either route to My little shout speaker or my cue wedge using button x.24 in my attached config file. So this would utilise the second “MyChB” for an input, now if only I could set a DIRECT output via SCP then I could eliminate having to use Mixes/Mtrx for the shout outputs.
Don’t see an SCP command for DirectOut Patch. There are commands for outputport patching, but that’s not likely what you need. Possibly my MIDI module can help in that case.

“Conditional Options”. So rather than using companions “Latch/Toggle” feature, is there a way of actually using the feedback system to control the options of a function based on what the current state of a particular button is on the desk. i.e. If Mix1 is already ON, then my TTS MIX 1 button needs to turn Mix1 OFF when I first press it. With the current settings, you’d need to press it twice!
Had a discussion with the companion folks about that a while ago. Not sure if you’re on Slack, but here’s the link. What they suggest would require me to make some major changes to the code. Not saying it shouldn’t or won’t be done, as I get what you’re saying and it should be fixed, but it’s not a showstopper ATM so it might be a bit before I get to it.

As I don’t actually have a desk sat next to me at the moment for real time testing - How would the feedbacks that I’ve set on my Mons and FOH TTS On/Off buttons work (x.23 & x.31) - which one would have preference - the last I presume?
Not sure what you mean. Both feedbacks seem to work. (I’ll post a clip below)

Lastly - how’s it going getting companion to talk with CL/QL editors? I saw you were having a little chat about it in Slack.
It’s in the works. Basically it’s communicating, and the nice thing is that I can use the editor to test it, even though I had to do some more hacking of companion to get it to talk… We’ll see how the companion folks feel about that. Regardless, the functionality should be available in my private builds even if they don’t support it in their builds. I should have something to test in a few days hopefully.

Thanks again for your testing and feedback!

Here’s 10 characters!

[Quote]
“Conditional Options”. So rather than using companions “Latch/Toggle” feature, is there a way of actually using the feedback system to control the options of a function based on what the current state of a particular button is on the desk. i.e. If Mix1 is already ON, then my TTS MIX 1 button needs to turn Mix1 OFF when I first press it. With the current settings, you’d need to press it twice!

Had a discussion with the companion folks about that a while ago. Not sure if you’re on Slack, but here’s the link. What they suggest would require me to make some major changes to the code. Not saying it shouldn’t or won’t be done, as I get what you’re saying and it should be fixed, but it’s not a showstopper ATM so it might be a bit before I get to it.[/quote]

Re-reading that discussion, I see the real issue if all buttons are non-latching as they suggest. What if you’d like something else to happen on the 2nd press. A number of scenarios come to mind:
Button currently set to “Toggle”:
Press once to send a mix to 0db (“ON” action)
Press again to lower that mix to -10db (“OFF” action)

If I MAKE each button toggle within the module, you’d lose the ability to do something like the above. What should the module’s “toggle” do? It only makes sense for actions that have a specific on/off function.
Furthermore, what if I DON’T want a 2nd press to turn something off? A “PLAY” button for example, you might want to only have an “ON” action, and don’t want it to stop when pressed a 2nd time. Besides, what’s the command for the 2nd press? Stop? Pause?

I can see a lot of issues. If you have ideas, let me know as I’d like to bring this up with them again for improvements in the next version of companion.

1.3.6 is up with 4 “My Channel” selections, with custom names.

“ON” means PRE on the PRE/POST selection, btw. :slight_smile:

1.3.6 is up with 4 “My Channel” selections, with custom names.
Brilliant - just downloaded and adjusted the new ‘My Channels’ - exactly what’s needed. Only caveat I would mention is, are you appending a unique ID (under the hood) to the Custom My Channel names, to avoid errors just in case a user was to inadvertently make two custom names the same? It might look like the same name to the user, but the module wouldn’t break because it would see them as two (or more) different names.

The action choices are created programmatically. If the command has a toggle, it becomes On/Off in the action. That means the wording may not always match. It does for things like channel on/off, others aren’t so clear.
InCh/ToMix: ON means that channel’s send to that mix is ON. OFF Means not.

So the OnOff option is part of the Companion Core - not something you can change on a ‘per command’ basis. Shame.

It looks like you’re using that option on your TTS buttons. Not sure why you also have the InCh/ToMix/Level adjusted as well?
The InCh/ToMix/Level to 0db is there - just incase I forget to turn it up for each mix (stabbing at the SD wondering why people can’t hear me!), the same is true for the main OnOff of each Talk Mic. (x.23 and x.31) - Obviously if OVERALL talk level needs adjusting - per gig - you can either adjust the HA gain or make just one adjustment to the main fader (assuming you’re in post fade mode, as you would normally be for mons.)

Don’t see an SCP command for DirectOut Patch. There are commands for outputport patching, but that’s not likely what you need. Possibly my MIDI module can help in that case.
Yeah this was because I was thinking about simply direct out patching for the Shout routing as and when the PTT button for that was hit. (x.24 and x.32) - Just so you didn’t use up a Mix/Mtrx bus. Looking forward to playing with your MIDI module when you’re ready.

I have actually just found the DirectOut SCP command. Take a look at the Attachment Parameter List #04 and #06 - the lists show you can select not just Mixes but also DIR CHxx along with a whole host of other options (Like CUE L and R). I guess this is why you need the drop down options for the Patch Commands. Not sure how ‘quick’ an on the fly dante patch would be in the real world - and Omni patch would probably be quicker. I know when I’m hitting those green dots in Dante controller, it takes a second or so!
So my second thought on this, is to DE-Patch to NONE on my wedge mix as and when I hit an IEM CUE mix - stopping any Click tracks blaring out of my wedge!
So maybe think about adding some custom “My Output” channels too.
Uses would be, Cue Wedges, IEM Mixes, various talkbacks.
You can tell I’m thinking about this as I type - so I suppose if you’re on a CL5 you could simply use CUE B (Mtrx 7&8) for your IEMs, and turn off the CUE A bus with SCP command “Cue/Output”…as that command ONLY affects CUE A. When you hit an IEM SD CueMix button?

Had a discussion with the companion folks about that a while ago. Not sure if you’re on Slack, but here’s the link. What they suggest would require me to make some major changes to the code. Not saying it shouldn’t or won’t be done, as I get what you’re saying and it should be fixed, but it’s not a showstopper ATM so it might be a bit before I get to it.
I’m thinking - in the first instance… say you had LAST Cue set to ON, on the desk (Rather than MIX Cue), with the current settings for my Cue buttons, the Yellow bar at the top of the button would remain when a second cue button was pressed. Furthermore, during a gig, I might quickly press cue on the desk itself - meaning the Yellow Bar would NOT be on the SD button - although I presume the FEEDBACK indication for the rest of the button would still illuminate? Then if I pressed that same cue on the SD - I guess I have to hit it twice atm, to get it in the same state to turn it off?

As I don’t actually have a desk sat next to me at the moment for real time testing - How would the feedbacks that I’ve set on my Mons and FOH TTS On/Off buttons work (x.23 & x.31) - which one would have preference - the last I presume?
Not sure what you mean. Both feedbacks seem to work. (I’ll post a clip below)

My Bad on this one - I’d actually had the WRONG command in the feedbacks on the TTS buttons. They should have been InCh/Fader/On NOT InCh/ToMix/On. The idea being that you press the TTS button(s) to select which mix you want to talk to, then either hit Mons or FOH TTS On/Off to actually talk to those mixes. Then each TTS button will light with the colour of whoever was talking to them - Green for Mons, Red for FOH. But I might be just over complicating things here. I guess you could just have an ON colour for each TTS mix button, and then the same for each TalkMic On/Off. Lol.

If I MAKE each button toggle within the module, you’d lose the ability to do something like the above. What should the module’s “toggle” do? It only makes sense for actions that have a specific on/off function.
Furthermore, what if I DON’T want a 2nd press to turn something off? A “PLAY” button for example, you might want to only have an “ON” action, and don’t want it to stop when pressed a 2nd time. Besides, what’s the command for the 2nd press? Stop? Pause?

The modules toggle would simply need to be an If This Then That scenario. With a caveat that users use the Companion Toggle at their own risk! :slight_smile:
Short press PAUSE - Long press STOP?

“ON” means PRE on the PRE/POST selection, btw. :slight_smile:
Cool. Ta.

It’s in the works. Basically it’s communicating, and the nice thing is that I can use the editor to test it, even though I had to do some more hacking of companion to get it to talk… We’ll see how the companion folks feel about that. Regardless, the functionality should be available in my private builds even if they don’t support it in their builds. I should have something to test in a few days hopefully.
When you have this in your own builds (can’t wait BTW!), do you still leave the IP addr in the editor set to the desk it would normally be connecting to? or would you set that to localhost - 127.0.0.1? In other words - when we’re back in the real world on a gig - will an editor be controllable from BOTH companion AND the desk itself? How’s that setup?

On another note - I’m considering building all this into a Raspberry PI at some point - (I have a spare Pi4 here). I know atm I’d still need to configure it from a GUI on my laptop (which kinda defeats the point) - BUT - interestingly, have you come across Uffe Lund-Hansen over at FrostBox Labs in Copenhagen?
https://labs.frostbox.net/products/macro-stream-sd/
The Digico uses OSC (unlike Yamaha) - I was talking with Tom Rundle from Yamaha UK a couple of days ago about this, and he said that their CL/QL firmware was developed before OSC became a ‘thing’, hence why they developed SCP, which is a shame. That said - with SCP and your MIDI implementation, I think you’ll be onto a winner. And if you could just add the GUI interface to the RaspPi version that be good too. While your at it, could you also just chuck in the cure for COVID-19 as an after thought! You know - that FIX THE WORLD button.

:slight_smile:

Thank you!
Ya, the titles you give are not the variables. Feel free to confuse yourself by naming all of them “SUCK” if you like… :glasses10:

The action choices are created programmatically. If the command has a toggle, it becomes On/Off in the action. That means the wording may not always match. It does for things like channel on/off, others aren’t so clear.
InCh/ToMix: ON means that channel’s send to that mix is ON. OFF Means not.

So the OnOff option is part of the Companion Core - not something you can change on a ‘per command’ basis. Shame.

Naw. My choice. On/Off is correct for everything but PRE/POST I think, not worth it for one set of commands. Besides, that’s what the macro function is for, so you DON’T have to memorize command names and parameters. Just make the changes on the console, add your feedback and you’re done!
:headbang:

Don’t see an SCP command for DirectOut Patch. There are commands for outputport patching, but that’s not likely what you need. Possibly my MIDI module can help in that case.

Yeah this was because I was thinking about simply direct out patching for the Shout routing as and when the PTT button for that was hit. (x.24 and x.32) - Just so you didn’t use up a Mix/Mtrx bus. Looking forward to playing with your MIDI module when you’re ready.

I have actually just found the DirectOut SCP command. Take a look at the Attachment Parameter List #04 and #06 - the lists show you can select not just Mixes but also DIR CHxx along with a whole host of other options (Like CUE L and R). I guess this is why you need the drop down options for the Patch Commands. Not sure how ‘quick’ an on the fly dante patch would be in the real world - and Omni patch would probably be quicker. I know when I’m hitting those green dots in Dante controller, it takes a second or so!
So my second thought on this, is to DE-Patch to NONE on my wedge mix as and when I hit an IEM CUE mix - stopping any Click tracks blaring out of my wedge!
So maybe think about adding some custom “My Output” channels too.
Uses would be, Cue Wedges, IEM Mixes, various talkbacks.

Ok, thanks. I’ll have a peek.

Had a discussion with the companion folks about that a while ago. Not sure if you’re on Slack, but here’s the link. What they suggest would require me to make some major changes to the code. Not saying it shouldn’t or won’t be done, as I get what you’re saying and it should be fixed, but it’s not a showstopper ATM so it might be a bit before I get to it.

I’m thinking - in the first instance… say you had LAST Cue set to ON, on the desk (Rather than MIX Cue), with the current settings for my Cue buttons, the Yellow bar at the top of the button would remain when a second cue button was pressed. Furthermore, during a gig, I might quickly press cue on the desk itself - meaning the Yellow Bar would NOT be on the SD button - although I presume the FEEDBACK indication for the rest of the button would still illuminate? Then if I pressed that same cue on the SD - I guess I have to hit it twice atm, to get it in the same state to turn it off?

If I MAKE each button toggle within the module, you’d lose the ability to do something like the above. What should the module’s “toggle” do? It only makes sense for actions that have a specific on/off function.
Furthermore, what if I DON’T want a 2nd press to turn something off? A “PLAY” button for example, you might want to only have an “ON” action, and don’t want it to stop when pressed a 2nd time. Besides, what’s the command for the 2nd press? Stop? Pause?

The modules toggle would simply need to be an If This Then That scenario. With a caveat that users use the Companion Toggle at their own risk! :slight_smile:

Short press PAUSE - Long press STOP?

I’m going to start a new thread on this topic.

As I don’t actually have a desk sat next to me at the moment for real time testing - How would the feedbacks that I’ve set on my Mons and FOH TTS On/Off buttons work (x.23 & x.31) - which one would have preference - the last I presume?
Not sure what you mean. Both feedbacks seem to work. (I’ll post a clip below)

My Bad on this one - I’d actually had the WRONG command in the feedbacks on the TTS buttons. They should have been InCh/Fader/On NOT InCh/ToMix/On. The idea being that you press the TTS button(s) to select which mix you want to talk to, then either hit Mons or FOH TTS On/Off to actually talk to those mixes. Then each TTS button will light with the colour of whoever was talking to them - Green for Mons, Red for FOH. But I might be just over complicating things here. I guess you could just have an ON colour for each TTS mix button, and then the same for each TalkMic On/Off. Lol.

Change it the way you’d like to see it work and I can test it here with my “CL emulator”…

It’s in the works. Basically it’s communicating, and the nice thing is that I can use the editor to test it, even though I had to do some more hacking of companion to get it to talk… We’ll see how the companion folks feel about that. Regardless, the functionality should be available in my private builds even if they don’t support it in their builds. I should have something to test in a few days hopefully.

When you have this in your own builds (can’t wait BTW!), do you still leave the IP addr in the editor set to the desk it would normally be connecting to? or would you set that to localhost - 127.0.0.1? In other words - when we’re back in the real world on a gig - will an editor be controllable from BOTH companion AND the desk itself? How’s that setup?
You’d connect the console to the editor as normal, and Companion to the console. It SHOULD be able to allow multiple connections. If it does, then you’d have 3-way communication…

On another note - I’m considering building all this into a Raspberry PI at some point - (I have a spare Pi4 here). I know atm I’d still need to configure it from a GUI on my laptop (which kinda defeats the point) - BUT - interestingly, have you come across Uffe Lund-Hansen over at FrostBox Labs in Copenhagen?
https://labs.frostbox.net/products/macro-stream-sd/
The Digico uses OSC (unlike Yamaha) - I was talking with Tom Rundle from Yamaha UK a couple of days ago about this, and he said that their CL/QL firmware was developed before OSC became a ‘thing’, hence why they developed SCP, which is a shame. That said - with SCP and your MIDI implementation, I think you’ll be onto a winner. And if you could just add the GUI interface to the RaspPi version that be good too. While your at it, could you also just chuck in the cure for COVID-19 as an after thought! You know - that FIX THE WORLD button.

:slight_smile:
Yeah, saw that a while ago. Interesting, but can’t create macros on it’s own, the way mine can.
RPI - New topic. :slight_smile:

1.4.0 is up with some of the changes you requested…

Feedback when using multiple feedbacks on one button is wonky (I think because of the way companion is written), gonna start a new thread on that.