Please add output libraries!

[Izzpro]

Output library storage would be great for a local venue with several different combinations of output assigns weekly (Wedges/ IEM,guest recording, etc.) This would be very helpful time wise than re-patching each time.

[Brian]

This is a perfect use of the show/scene files. Personally I would create a “show” file for each different regular group that saved your I/O for that group. You could also do this in a scene, but I feel that would get very confusing if you wanted to create other scenes to use with that group. By having a unique show for each group, you can then save scenes under that show for anything that needs to change during the show.

[Izzpro]

It absolutely could, but having ONE show file with both selectable input and output libraries would be more helpful for our set up. The showfile drive list already gets ridiculously long *not to mention the lack of hierarchy by date option*. We also have multiple operators across a wide spectrum of I/O configs. Having a generic showfile with saved Inout AND Output libraries would be super helpful for us.

[Yann]

+1 for this on Channel direct out for different recording presets. A different library for each output type (Local, Slink, ME, USB, I/O) might be good to each library doesnt affect each other

[KeithJ A&H]

We have looked into this one and unfortunately it is not technically possible to add output libraries:

Input libraries are channel based.
i.e.
Channel 1 source = local socket #1
Channel 2 source = USB socket #24
Channel 3 source = local socket #6
…
Channel 48 source = I/O port #128

So there are 48 ‘parameters’ (when compared to processing libraries for example) and all of these can only be sourced from one place.

With output channel libraries on the other hand, you would either need to look at it from the socket point of view to know what’s going to individual sockets, or a mix/direct output/rack fx/monitor point of view.
Either way, as you can patch any SQ output to multiple sockets, there are hundreds of ‘parameters’ and so the data becomes too much to be stored/moved/used as a library item.

As Brian says, the best way to achieve this is either through use of shows (which are intended to be used per show/event/setup) or with scenes and global and/or scene filters, firstly to recall only the output socket patching and then to protect it from being overwritten on any subsequent scene changes.

Thanks,
Keith.

[lightingman117]

Hi Keith,

Thanks for looking into the output libraries.

I don’t quite follow why the output libraries are not technically possible.
Perhaps within the dedicated IO-Patch library space, but there are alternatives.

Just use scene storage space.
The library button in IO-patch for outputs would simply recall scenes with recall-filters set for everything except the outputs.

I just tested this and it is working. It does tie-lines & output patch.
Am I missing something?

I don’t think I could ever use 500 scenes even if I saved every show of every SQ I have ever used.

I get that messes with the literature of “500 scenes” in the datasheet. But just state that as you create ‘user’ output scenes (including tie-lines) you reduce the max number of scenes from 500. No one is going to have more than 10 output patches lol.

—

As an aside, this does work for everyone as a workaround. But I think it would simply be easier in the library button to have pointers to those scene positions.

[BRS]

+1 for this solution.

[KeithJ A&H]

@lightingman117

I don’t quite follow why the output libraries are not technically possible.

So if we say each patch point is equal to 1, then:
For input channel patch libraries, because each channel can only be sourced from one socket at a time -> 48 (channels) x 1 (source) = 48
For output patching (on an SQ-7 which has the most local output sockets), where each output socket can be sourced from one ‘thing’ (direct/mix/FX/monitor/tie line) -> (20 (local) + 128 (SLink) + 40 (ME) + 32 (USB) + 128 (I/O Port)) x 1 = 348

It’s possible to store all patching in scenes as you say, because the size of a scene is much bigger than a library. So scenes are the way to achieve this as mentioned.
We wouldn’t use scene storage for library storage as there are users with 300 scenes, and changing things would break compatibility.
We also wouldn’t call something a library or be able to treat it as a library if it was actually a scene, because it would definitely cause confusion and the library functions don’t work with scene files anyway.

By using scene recall filters, all you need to do is store ‘patch’ scenes (maybe towards the end of the scene list?) and apply filters such that only patching is allowed.
Note that it would make sense to include input patching as well as output patching, so your scene includes all the patching for a particular system setup.
On your ‘mix’ scenes, you then need to do the inverse and block the patching so it doesn’t change. Even easier would be to toggle global filters during setup, so allow patch changes during setup when you select your patching scene, then block them before recalling any ‘mix’ scenes. You can use a combination of scene and global filters to only allow changes to the input patch on a scene by scene basis if required too.

In use, the steps would be:
Recall the scene for the setup (‘2x DX168’)
Block patch changes in global filters
Recall mix scenes and carry on as usual

As opposed to your suggestion:
Block all patch changes in global filters (otherwise scene recalls will overwrite your library recall)
Recall an input channel patch library
Recall an output channel patch library

So you’re really not saving any time compared to the potential confusion and problems with trying to treat scenes as libraries.
There are other benefits to using scenes for different setups too, like being able to recall output processing for a particular venue or speaker setup at the same time.

The only way I could see it potentially making sense would be to scrap the input channel patch library (which people are already using a lot!) and replacing it with a ‘recall input patching from scene’ option that could then be implemented in a similar way for outputs as ‘recall output patching from scene’ and for tie lines as ‘recall tie-lines from scene’.
I’d argue this is almost as confusing to infrequent users though as you’d still need to present all scenes.

I do get the thinking of ‘there are input channel patch libraries so why not output channel patch libraries?’, but input channel patch libraries were introduced for things like virtual soundcheck where you need to quickly toggle lots of input patching once everything is setup and also because there are more input sockets than input channels, whereas output patching is much more of a per-setup/per-event thing and therefore show/scene based… isn’t it?

Thanks,
Keith.

[lightingman117]

Hi Keith,

Thank you for your detailed response.

It’s possible to store all patching in scenes as you say, because the size of a scene is much bigger than a library. So scenes are the way to achieve this as mentioned.

I am glad to be confirmed in my understanding of the technical limitation (save location space [patch library]).

We wouldn’t use scene storage for library storage as there are users with 300 scenes, and changing things would break compatibility.

300 scenes is still not 500 😉

We also wouldn’t call something a library or be able to treat it as a library if it was actually a scene, because it would definitely cause confusion and the library functions don’t work with scene files anyway.
I’d argue this is almost as confusing to infrequent users though as you’d still need to present all scenes.

I agree, confusing and infrequent isn’t something that should be changed. My solution definitely isn’t a wholistic solution; just a coding path forward. It definitely flushed out in the same way a dev/eng/pm/you team can.

—

I do find it amusing/impressive how the x32/m32 firmware team can 10 years later figure out how to do crazy stuff like custom patches for their users. I don’t say this to knock the A&H team, simply that they set a high bar for user request fulfillment. Competition is good, for users; hah!

I digress. 🙂

I do get the thinking of ‘there are input channel patch libraries so why not output channel patch libraries?’, but input channel patch libraries were introduced for things like virtual soundcheck where you need to quickly toggle lots of input patching once everything is setup and also because there are more input sockets than input channels, whereas output patching is much more of a per-setup/per-event thing and therefore show/scene based… isn’t it?

Honestly, I’ll sheepishly admit I never considered using scenes for output management. For some reason I always thought it was a show level thing. I also regularly wanted an output library, but I found myself mashing the library button and not understanding why it wouldn’t come up.

I really think this isn’t as complicated as you’re making it out to be.

Output patch library button can simply open a scene save dialog with some notes/warnings/extra buttons

-Press IO
-Press library (be on output page)
-Big notice block: “output patches [including tie-lines] are stored in show files 491-500. block global recall filters? [button to automatically do it for you]”
-Store > scene slot [491-500] – “output patch 2xDX”
-Recall > scene slot [491-500] to output patch? Yes/Cancel

Users already understand library Ip patches can be overridden by scene recalls (hopefully they set global/scene input patch filters).
Users should also understand library scene Op patches can be overridden by scene recalls (hopefully they set global/scene output patch filters).

Idk, just brainstorming. I’m sure there are better approaches. But this gets the gist of things IMO.

While we’re talking patches…why do input patches not change unless the preamp is also selected? I would have thought the preamp stays with the input not the socket and thus changing a patch socket would also update that socket to the channel’s preamp. My recall filter testing makes me question how well I honestly know the SQ series lol, let alone dLive/Avantis… hah

Thanks for Listening 🙂

Nathan R.

[Author]

Posts