SQ5 scenes and fader resistance

Forums Forums SQ Forums SQ troubleshooting SQ5 scenes and fader resistance

This topic contains 5 replies, has 3 voices, and was last updated by Profile photo of volounteer volounteer 1 month ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #93284
    Profile photo of dylanmaudio
    dylanmaudio
    Participant

    Posted this on Facebook, but thought I’d post here.

    Anyone else ever noticed this.. when firing scenes with DCA fader movements only – I get resistance when fingers are on channel faders that aren’t assigned to any DCA – or set to be recalled.

    For example – I have setup a soft key to fire a scene that moves a (drum) DCA to -5, and if I try to move a (guitar) channel fader at the same time, the channel fader has resistance and won’t move.

    I’m guessing this is just a limitation with SQ5 handling of scenes and recall scope? I was previously using D-Live for the same scenario and never experienced this issue.

    On the scenes themselves, the only thing that is set to Allow in the scene recall filter is ‘DCA Fader’.
    I’ve safed the specific channels.
    I’ve even blocked input channel fader from global recall filter.
    The same thing occurs. Fader resistance lasts about 1 second before it lets allows the fader to move again.

    #93297
    Profile photo of KeithJ A&H
    KeithJ A&H
    Moderator

    @dylanmaudio ,

    This is expected and normal behaviour due to the way the SQ control ‘loop’ works.
    The following is from another thread on the same subject:

    “… when you block anything using recall filters (Global/Scene) you’re blocking changes to the core rather than the faders. The physical controls are separate from the values in the core e.g. you can make changes to channel levels on a layer you’re not viewing with scene changes without any change to a physical fader.
    The distinction is important because of the way the control (and feedback) of fader levels works.
    So when you change layer, or mix, or change send levels for a channel you have on the current layer in any other way except by touching a fader – the level in the core changes, and also sends out a message to the fader to change position. The fader then moves to that position, and the reading from the fader is sent back to check it’s in the correct position.
    If you then move the fader, it updates the value in the core, and again, sends out that message to everywhere else displaying that value (fader, screen, Soft Rotary etc…).

    A good experiment to show how long this takes (not very long obviously) is to assign the same channel to two channel strips on the same layer and move just one of the faders. You’ll notice if you move very quickly, the fader that’s trying to follow will be just behind the one you’re moving.

    The other part of this is that the SQ is constantly storing the current state of the desk. When you make a scene change with any filter in place, it must refer to this stored data to know the state it is currently in and then apply the scene change information (non-blocked) over the top.

    So what you are doing in the video is moving the faders quickly and exactly at the point of changing scene. This means you’ve pulled the faders down part of the way when the core takes the reading of what the level is, and when it sends back out the message to tell the faders where to be, it’s sending out the level it stored from part way through your fade to -inf.

    Best practice would be to either move the faders and then make a scene change, or make a scene change and move the faders, but not both at the same time.
    You could also keep your fingers on the faders and they would take a split second to update to the new reading (-inf) but this would put strain on the motors as they would be trying to get back to that stored point for the split second they ‘think’ that’s the current state.”

    So the limitation you mention is that the SQ is not designed to change scenes whilst simultaneously making adjustments.

    Thanks,
    Keith.

    #93305
    Profile photo of volounteer
    volounteer
    Participant

    @KeithJ A&H

    Is there any documentation that explains how these devices are actually built and their architecture?
    EG something that would explain how the block diagram actually works and how things get routed/connected?

    Or is that some sort of trade secret info that you do not release?

    #93312
    Profile photo of dylanmaudio
    dylanmaudio
    Participant

    Thanks for the detail Keith, appreciated.

    So I’m assuming that the D-Live handles this differently, yes?

    #93324
    Profile photo of KeithJ A&H
    KeithJ A&H
    Moderator

    @volounteer – It’s all digital, so I’m not quite sure what you mean, but you’re correct that with SQ being a completely bespoke embedded device – all layout, technology and operating firmware is designed and developed in-house, and is all top secret.

    @dylanmaudio – Yes, although both use XCVI cores and so the audio processing and mixing use the same algorithms, the control ‘layer’ (operating system if you like) is completely different. So as you say, on dLive, faders which are not being altered by the scene can be excluded from the loop and not checked/positioned in the same way. End result being that you will not feel the split-second of resistance when trying to adjust them through a scene change.

    Cheers,
    Keith.

    #93339
    Profile photo of volounteer
    volounteer
    Participant

    @KeithJ A&H

    I understand the code would be secret but how about a block diagram of the hardware things running the software.
    You all mention them here but what types and how many and where plus their interconnections with the rest of the hardware would be useful to us.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.