This will be the last from me for a while, I think I’ve annoyed everyone around here to death for the past few days, sorry about that!
However, I’ve a problem where my local widgets, which are linked to global widgets aren’t showing the same values and wondered if there’s a way to fix that. I imagine there’s a number of factors at play here, that I’m missing or misunderstanding.
Please see attached screenshot.
Red circle - volume - this is monitoring levels from a 4 channel mixer and shows a numeric widget value locally and channel 1&2 volume levels (dB) in the global rackspace.
blue circle - BPM - showing numeric widget value locally and global BPM in the global rackspace.
Green rectangle - L&R levels - this is monitoring levels from a 4 channel mixer which I’m seeing green level movement on both in the global rackspace, but the green levels locally aren’t moving at all.
Though I see that 4.0.54 is available so I’ve just downloaded it and looks like issue 1 and 2 are fixed, so that’s perfect, thank you! @djogon and the team
Issue 3 still exists, unless that’s expected behaviour.
I can confirm that in your gigfile, the meters in the global rackspace move, but in the local rackspace the meter widgets assigned to the same audio mixer dont move.
Yes - the global meters will not be mirrored in the local rackspace for some internal reasons.
We understand the need for local widgets to control the global ones. Various midi mappings, using variations etc, but mirroring the global meters is a bit useless as you can always have your global panels visible if you want them.
I have to disagree with you here, @djogon. You’ve instilled a workflow where we must recreate our global rackspace in a local rackspace to make the changes that we need, per variation, negating the need to show the global rackspace at all, until now.
I really don’t enjoy having to recreate global rackspaces locally as it’s a lot of duplication, IMO, and it’s an onerous task. And now, alongside a fully duplicated rack of many widgets, I need to show the global rack, which looks exactly the same, just to show levels working correctly?
I’m doing a lot of heavy lifting in the Global rackspace because of advice I had on here months ago. Now I’m buying into the concept, I’m left a tiny bit short with this levels thing. Seems a shame to show the global rack at all when I have to duplicate everything but the levels locally. (Whilst this isn’t the most complex of rackspaces, it isn’t full or fully duplicated yet…)
I appreciate all the work you guys put into this stuff and am thankful for this amazing piece of software. I’ve had a couple of responses on here where my needs as a user are deemed “useless” or the wrong way of approaching the software, which is disheartening. As a UX Designer, I like to think that my passion for this software translates to me giving you good user feedback, in the hope that one day you may deem it worthy of a change to your technical backlog.
Sorry for the long and somewhat negative post. My point is that you can’t push local duplication of the gobal rackspace features to just 90% of the way and then say that the last 10% is unimportant, if you get what I mean.
@npudar it’s more that I need to change global rackspace settings per variation. So would have more gain on a drive pedal in one variation and less gain in another variation. I’m doing pre and post processing in my global rackspace. So showing the global rackspace is a bit pointless in my case because any changes I make would make the same change in every variation, which is not what I need
I am not sure why are you saying “re-creating rackspaces”. Global widgets are one small part of your global rackspace and even then - you only need to add the widgets that you want to control automatically using variations. You never have to not can you “re-create” the global rackspace locally.
If you simply wish to see your output levels you can just attach it to the local Audio Out block channel level parameters as those will display the total output as well.
@djogon most of my rig is in the global rackspace. I pretty much only have the amp in the local rackspace. So just the core tone changes, and everything else stays the same. I find things easier that way. So in order to have full control over drives, delays, reverbs, BPM, levels, metering…I need to duplicate my global rackspace locally to enable me to control global widgets per variation.
Here’s an example of the types of things I’m doing, all basic, but most of the changes reside in the global rackspace. Often I’ll change BPM for some of these variations too.
I’ll also have about 5 or 6 core amp tones (rackspaces), so I would need to duplicate the global rackspace widgets locally about 5 or 6 times to give me the control I need.
Lastly, while I appreciate your point regarding using the output block, I can’t do that locally as I don’t route anything to the output locally, I route it all to the output in the global rackspace, so that I can do pre and post-processing. So the only option is to set up metering widgets in the global rackspace and bind them to local metering widgets…I don’t have (as you said I could just show the global rackspace) to but would like to.
That shouldn’t matter - the levels in the local rackspace should reflect the global output level even if you are not routing anything into the local audio out block.
I thought that too, but I tried it and I just get static meters that don’t move. Similar to the gig file I posted. I’ll post another gig file showing what I mean when I get back to my computer. Thanks for your time @djogon
The only reason they would move is if you produce a sound on your input channel 3 which you wired to go to the global rackspace and from there back into local and then out.
If you do produce the sound on input CH3 then you’ll see the global meters move, but not the local ones because you didn’t attach the local meter widgets the way I suggested - to your Audio Out Block - Output Level (Channel n) parameter.
Again - you still have to PRODUCE some sound on ch3 to get the meters moving
btw… your routing does not matter… you can route to global rackspace and then out to your interface or route it locally like you did in your example. That does not play a role in what you want to achieve. The local Audio Out block will reflect the global state as far as meters are concerned…
Okay, there’s a slight nuance to this that admittedly, I missed. Your advice was to attach the widgets to the “Output Level” parameter. I hadn’t discerned the slightly nuanced difference between “output volume” which I was using and “output level”, apologies. In the gig file I shared with you, you’ll see that I attached to the local output block volume parameter, so I wasn’t a million miles away. Easy mistake to make, I think.
I’m also very aware that I must make a sound to see the levels move.
The level meters are moving now, as I’ve attached them correctly to the local output block level parameters.
