Midi Message -> Value Fade Time

[tuxmos]

Thank you, but I am already using it that way. Now I want to be able to set fixed fades or control another program (arkaos Media Master Pro) via midi. In the absence of a DMX interface, I wanted to regulate this internally with midi, but that doesn't work without a fade, just on and off. Not nice. Unless someone knows a software for a virtual DMX interface, which I can use between SCS and Arkaos? Then I can use the lighting control from SCS. I have found nothing. Always just hardware.

[Mike Daniell]

If I could specify the start/end/duration of a fader move that would be fantastic.

I'll see if I can get this ready for you next week.

Hi mike. Is there any news about it, or a preliminary version? I could use the function urgently.

Will the above-mentioned change to specify the start/end/duration meet your needs?

[Boswell]

Many thanks Mike, look forward to trying it, It will give me something to do during lockdown!!

[Mike Daniell]

I've done some preliminary research into this feature and it's more complicated than I previously thought. So I can't promise a quick solution, especially as I'm currently working on another enhancement. However, I'm considering a better solution that I'm sure will be easier to use.

If you have used SCS Network Control Send cues with an X32 then you will be aware of the X32-specific features included in SCS - see Control Send - Network in the Help. Currently, this feature supports commands such as 'mute channel ...', 'go snippet ...', etc, but does not support fader levels. To enable these commands, the 'Remote Device' in Production Properties will have been set to 'Behringer X32...'.

I'm considering the following enhancements:

• For MIDI Out Control Send devices under Production Properties, adding an optional 'Remote Device' property that will include 'A&H Qu-32' etc
• In Control Send cues in the Editor, display the 'Remote Device' field (disabled) if applicable, eg for 'A&H Qu-32' devices, as it currently is for X32 devices.
• For X32 devices, add an entry to the 'OSC Command Type' for 'Channel Fader', and add fields for 'Channel Level (dB)' and 'Fade Time'.
• For Qu-32 devices, display a similar control for 'Command Type', initially set with various 'Mute...' controls, and also 'Channel Fader'. However, since the Qu-32 control is via MIDI, not Network OSC, SCS cannot read the current channel levels so we need fields for 'Channel Level (dB)', 'Fade Time', and (if Fade Time is greater than zero) 'Fade From Level (dB)'.

NB: 'Qu-32' includes other A&H mixers that use the same protocol. The 'Remote Type' in Production Properties will include separate entries for A&H Qu-16, Qu-24 and Qu-32,as these can be used to validate the maximum channel numbers used.

[Boswell]

That sounds like a plan Mike, should keep you occupied for a while, keep up the good work

[allcomp]

Hi

I don´t think that the ability to fade OSC messages on other OSC devices have been mentioned? That could be very cool as well. I could very much use this feature to fade the value 0 to 1 in other video mapping software, lighting software and vst host software. Now I am doing this manually from TouchOSC faders on an Ipad, so it would be very nice to automate this from SCS instead.

/Brian

[Mike Daniell]

Brian,

Maybe this could be provided with an enhancement to the OSC Free Format option in Control Send Cues, by adding an optional 'Fade Time' field. The example currently shown in that Help topic shows the OSC message "/ch/08/mix/fader ,f 0.7". Although this example is for setting an X32 channel fader, the proposed modification could be used for other OSC devices and software. By adding a 'Fade Time' field in which the user enters, say, 2.5, SCS would perform the following when the cue is played:

• Initially SCS would send the 'OSC address pattern' only, ie "/ch/08/mix/fader" in this example.
• This command should immediately return the current value for that OSC command request, which for a fader would be the current fader setting.
• SCS would then progressively issue "/ch/08/mix/fader ,f n.n" commands over a period of 2.5 seconds, where "n.n" would be values between the current setting and the target setting of 0.7.

[allcomp]

Yes. Your description sounds exactly what I was hoping for. Thank you!

/Brian

[sergioherculanomusic]

Brian,

Maybe this could be provided with an enhancement to the OSC Free Format option in Control Send Cues, by adding an optional 'Fade Time' field. The example currently shown in that Help topic shows the OSC message "/ch/08/mix/fader ,f 0.7". Although this example is for setting an X32 channel fader, the proposed modification could be used for other OSC devices and software. By adding a 'Fade Time' field in which the user enters, say, 2.5, SCS would perform the following when the cue is played:

• Initially SCS would send the 'OSC address pattern' only, ie "/ch/08/mix/fader" in this example.
• This command should immediately return the current value for that OSC command request, which for a fader would be the current fader setting.
• SCS would then progressively issue "/ch/08/mix/fader ,f n.n" commands over a period of 2.5 seconds, where "n.n" would be values between the current setting and the target setting of 0.7.

HI Mike,

I made a post in facebook exactly about that, is this feature already available ?

https://www.facebook.com/groups/1047597 ... 183791153/

[Mike Daniell]

Not yet. I'll bump up the priority.

[sergioherculanomusic]

Not yet. I'll bump up the priority.

Thanks for the feedback.

[Calysto]

Thanks for the additional suggestions, Calysto. I'll have a think about having two values (before and after) entered by the user. The 'before' value, however, should ideally be pre-populated by scanning earlier Control Send cues, although the use of hotkeys can mess up this logic, so the ability to manually set or override the pre-populated 'before' value would help.

I haven't previously considered NRPN.

I was thinking about this... what if you make some kind of software midi controller (it can be just an array of data and/or a visual component) between the cues and the actual midi output. Then you are able to track that software part (because you can write it yourself).
If soft or hardware is able to send midi back it will be tracked by the software midi layer, cue's can read that. If not, cues will still read the current possition given by the software mdi layer.
Hope you understand what I mean and that it fits your architecture.