Converting a design from 1.14 to 2. and logic % went way up

Hannalee

I had a design file with less than 100% logic utilization, now that I have upgraded to 2.00, the logic percentage is 174%. the indicator is yellow and not red.

I have not attempted to install this on the clients blu-80. Is this a known bug?

Dan Lynch

It's not a bug, you're just running a lot more logic than London Architect believes is possible in real time.

London Architect has no way of knowing how your logic will actually be used. Unlike audio, logic doesn't all happen all of the time. Even in a design file with a huge logic section, most the time there's nothing happening. The 174% is telling you when you change a logic state, the result of that change may not happen in \"real time\". It may happen immediately or it may happen a split second later. Logic is based on 100ms cycles. If your design is really huge and you try to do everything all at once, you could find that some things which are theoretically supposed to happen at the same time will actually happen a 100ms apart. Or 1 second apart. Or 3 seconds apart. It all depends on how huge it is.

So, ask yourself two questions:
1) How much of this logic will ever actually try to trigger all at once?
2) Does it matter if not everything happens in real time?

For most designs, it's no big deal. The reason you saw a change when you updated is because the meter in v2 is a little more accurate. Just remember, this is NOT audio. Running over 100% usually isn't the end of the world. We do it to our PCs all the time.

Dan

Hannalee

Thanks.

BTW, is there any scalabilty on the logic side like there is on the audio side?

We have a tendency of using the blu-80s as automation controllers as well as audio dsp boxes. Not a really good idea I guess, but the LA control panels makes nice displays for triggering lights, effects, and video routing. To that end, and to make my life MUCH easier, might it be possible to add real scripting to the logic section in a future release. Being able to insert visual basic or for that matter ANY procedural scripting language code would be so much better than drawing out logic.

As it is now, I do everything externally with microcontrollers talking to the blu-80 via the serial port. The logic sends various serial strings, and the microcontroller manages it and figures what the user really wants to have happen. It works, but would be better if it could all be done within one design file.

Dan Lynch

Not sure what you mean by scalability for logic. Maybe I'm being dense.

Dan

Hannalee

What I mean does the logic usage scale in a similar fashion to the audio dsp. 20 compressors do not consume 20 times the system resources that 1 does.

scott180

I'm glad I saw this post, but still want to run this through here and see if I'm on track.

I have a situation where I have a mixer block handling 40 inputs. Basically I'm making a digital mixer without the console. The user can run it via presets or actually get in and use the mixer in a fully manual mode.

Anyway, I wanted to provide mute groups. So I put four buttons on the custom channel strip and four master mute buttons. By linking the fist mute button to the master mute button with an \"AND\" logic block, I could trigger the mute buttons of multiple channels in groups.

The problem is that with 40 channels, the logic tree gets large and the percentages will probably go over 100%. But by reading this post, I really shouldn't worry about it?

Or if someone else knows a better way to handle mute groups, I would appreciate it.

I thought of just using groups, but in the mixing blocks, the groups are individual outputs that can't be assigned to the master output fader of the mixer.

Scott