Layers module: Allow connections into a layer

It is possible to connect the inputs of modules inside a layer to different outputs outside and to the left of the layers module.

I don’t understand why this is not possible to outputs as well: Allow a module that is located to the right side of the layers module to pick up a signal directly from an individual module inside a specific layer. Without the restriction to the single output per layer in the standard Layers module.

Comments

  • edited May 30

    You have the rack module for that. You just have to create the I/O you need

  • edited May 30

    This doesn’t work. I basically want the switching of layers for UI layout reasons, but the I/O flexibility of the standard rack module. Sections would work technically, but I’d prefer a solution with buttons and different layers that appear in exactly the same place of the UI.

  • +1

    @pedro

    It’s a different requirement. You usually reach for layers (at least I do) when you want to save horizontal space, stack up stuff… it’s purely cosmetic to avoid constant scrolling left-right… imo if current layer versions can’t allow this for technical reasons, there should be one available to address this need as well. I know I’m running into this limitation almost every time I want to build something, and I have been scratching my head why is it in place - signal flows left - right, top - bottom… in a rack layers can receive all signals from the left, inside layers it’s top - bottom, but imo none of this explains the limitation.

  • recrec
    edited May 30

    My limited solution is to ‘pack’ up to 16 values with many to poly module into a poly signal, send it through the single port and ‘unpack’ it with voice selector module. Not exactly an immediate solution, nor particularly saving space on the first look, but works ok if all setup beforehand and the unnecessary parts are hidden away.

    You can basically extract 16 x number of layers individual signals from layers module.

  • edited May 30

    Good idea @rec!

    IIRC, racks are like encapsulated containers doing the processing inside their own realm. Whatever output @giku had defined when building them will set the limits of what you can do with them.

    If there are good use cases for certain enhancements then chances are that they'll be added sooner or later, but because of the encapsulation limit, this won't be a direct connection between a module inside Layers but rather additional Layer module outputs available for such cases. I'm not sure how to do this in a clean way though.

  • By the way, have you tried adding empty layers just for the purpose of adding more outputs?

    Connections between higher number layers and any module in previous layers are possible.

  • recrec
    edited May 30

    @rs2000

    It would defeat the purpose (at least for me). My goal is to be able to create tools that others can use without first figuring out all the details. A no nonsense UI instead of another convoluted workaround.

    Imagine my above example where this would be the front for a Rene type seq. Pitch, vel, gate length, probability pages to hold 4 x 16 params. My workaround will allow exactly that amount, but it’s a limitation I keep working around, and running into its limit pretty much every single time.

    I believe the restriction was due to ‘no custom i/o’ at the time, but we moved past that. IMO on strictly technical grounds it could work while abiding all existing routing rules even in existing layers.

    Or another layers module could be introduced for purely UI purposes.

    TBH, other than few very specific cases, I don’t even know how to utilise existing layers in general, because this would be my only real use case - splitting long racks into sections, but here we loose core functionality when doing so.

  • edited May 30

    Cool solution 😎. Reminds me of so called “daxed” phone lines. Only without the onehundredandsomething volts phantom power that can get really nasty when you don’t know the line is “daxed”.

Sign In or Register to comment.