Forum Replies Created

Viewing 15 posts - 1 through 15 (of 26 total)
  • Author
    Posts
  • #125042
    Profile photo of Simon2Simon2
    Participant

    If you think in terms of ‘busses’, the situation becomes more clear: You can send multiple signals into a bus but you can’t ‘unmix’ them afterwards again. Your FX has only one output signal.
    If that is OK for you (eg. to add the same reverb mix to all your AUXes), you can use FX channels for your AUXes.
    What you suggest wouuld need a very different architecture.

    But i must admit that 8 FX slots are rather limiting when using inserts…..

    #125016
    Profile photo of Simon2Simon2
    Participant

    “Linking” (= parameter changes on one channel are automatically applied to another channel) is called “Ganging” on the SQ and is found under ‘setup / ganging”. There you can ‘add’ and ‘remove’ multiple channels to a gang…

    If you don’t have 2 CHANNELS linked but 2 INPUTS (into one channel), then you propably have switched a channel to stereo mode (Setup / Mixer Config / Input Stereo).

    #124881
    Profile photo of Simon2Simon2
    Participant

    That applies to ALL parameters (being able to define EQing, … independent is most flexible) and that’s why the ganging allows to define, what to synchronize and what not.

    ‘…I would not expect the DCA and mute group assignment covered with ganging…’ -> Why not? Why expecting assignment of mix busses then?

    #124846
    Profile photo of Simon2Simon2
    Participant

    @SteffenR: The same way as a Mix assignment.

    I think the question the other way around: Gangs bundle channels to be ‘treated similarly’ … why should channels that share the same EQ, Compressor, …. parameters and Mix sends NOT be controlled by the same DCA or Mute group?

    Bye

    Simon2

    #124495
    Profile photo of Simon2Simon2
    Participant

    >… assume, however, that there will be no noticeable difference to the old hardware.
    Understood.

    >…In this case, someone might ask where version 1.5.x is available
    Are you kidding?

    #124486
    Profile photo of Simon2Simon2
    Participant

    @KeithJ A&H: Aha!

    So the ‘new channel display hardware’ is just ‘under the hood’ and nothing a normal user could see, right?

    @1.5.2: OK, but why not just write ‘1.5.x’ but that very specific (but non existent) number?
    it’s really confusing.

    #124480
    Profile photo of Simon2Simon2
    Participant

    @Brian: Thanks for your answer.

    My concerns aren’t so much about feedback but about the ‘mixing’ of monitor wedges and the FOH speakers – at least in the first rows of audience (and maybe the band).
    But maybe that’s negligible against the different speaker types and positions of the wedges…
    I DO apply a strong high pass on the monitors anyway – but on the output not the sources.

    #124478
    Profile photo of Simon2Simon2
    Participant

    I AM calm. 😁

    But also curious. So is it just a typo?
    It’s kind of weird to state a compatibility to a version that doesn’t exist…

    Any thoughts on ‘… new channel display hardware…’?

    #124473
    Profile photo of Simon2Simon2
    Participant

    Also there is ‘ …SQ MixPad V1.5.2…’ mentioned.
    Is this a new version that’s to be expected? In the download section there is only a version V1.5.0…

    #124461
    Profile photo of Simon2Simon2
    Participant

    @Andre S: Thank you.
    It is a really obvious idea but (as often) one i didn’t come up with. 😁
    And a really cool one too!!

    We have patched all 48 channels in our standard setting (= easy/patchfree usage for less experienced volunteers). But we practically never use more than 24 channels simultanously at a single event.
    So we can’t use this ‘trick’ in our standard scene but it’s really helpful for advanced users.

    It’s less the monitoring that challenges us than the streaming, that could profit from a different processing than FOH. At least for SOME instruments (drums, bass, vocals, …) – and that’s another beauty of it: You don’t have to double ALL the signal – only the ones that are critical.

    BTW: I’m not sure if different EQing would be a good idea when working with wedges (we don’t use IEM). In a smaller Venue it could lead to a rather inhomogeneous sound…

    Bye

    Simon2

    #124134
    Profile photo of Simon2Simon2
    Participant

    @KeithJ A&H: That’s why those things are usually implemented in the core/kernel and not left for the UI. It opens a can of worms of ‘Don’t do this with your network’, ‘Take care of doing that with your app’, ‘We recommend to users to …’, …
    But OK – that’s the way it’s implemented and it won’t change by me smartassing on the internet. 😉 😉

    Thanks for all your time.


    @SQUser
    : Interesting fact.
    (in contrast, hashing the PW on the client is a good idea securitywise)
    I think, hiding the hash mechanism is one of the above mentioned ‘worm’ and could by a way for us to prevent anyone from using Mixing Station.

    #124097
    Profile photo of Simon2Simon2
    Participant

    Hi Keith,

    thanks for the answer.
    But I honestly do not understand how your definition (“… access to the controls…”) is different from mine or how it justifies that the access (to that special control) is not blocked by the console when connecting via app.

    That’s a design flaw in my eyes (and one that should be cautioned about prominently – inexperienced users could do a lot of damage unnoticed by anybody).

    Our console stands in our church and is used by a lot of people. Limiting access to the network and andling with passwords is rather impractical. Also insisting on using the MixPad-App (which we can’t enforce by techical measures anyway) is an massive burden (some of our technicians use different consoles).

    #124082
    Profile photo of Simon2Simon2
    Participant

    Thanks for the answer.

    But i would expect the console (server) to handle the access permissions and not leave it to the clients.
    It baffles me that it apparently isn’t the case. :-O :-O

    #123133
    Profile photo of Simon2Simon2
    Participant

    > For a stereo input you need about twice the processing power as for a mono one.

    I’m not sure about that because a lot of attributes are simply copied (processing, routing, ….). I don’t say, it doesn’t have any footprint but i doubt it to be the same size as supporting 96 channels.

    > The console was also developed for these 24 AUX/Groups.
    My point was: This is not a completely new concept to the console and A&H obviously knows how to implement it. 😉

    @processing power: Line6 (e.g.) demonstrates on the Helix, how to expand a LOT of functionality, range, features, … on an even older (and probably cheaper) hardware platform – just by clever programming and redesign.
    It’s no witchcraft but a question of willingness and effort.

    Sure – there is no entitlement for customers to this kind of enhancement. But good product management always helps also the supplier.

    #123088
    Profile photo of Simon2Simon2
    Participant

    P.S.: AND the ‘stereo needs just one channel’ approach would be consistent with the AUX/Groups – which also can be stereo without eating up more channels. 😉

Viewing 15 posts - 1 through 15 (of 26 total)