Global EQ Should Use DSP of Rows 3 / 4

If possible, global EQ should be programmed to use the DSP of rows 3/4 (and not 1/2), since most people will first and mainly use rows 1/2 for creating presets.

I agree, it should be possible to flip the UI, and it is much more intuitive, especially when most people likely don’t even know it’s not symmetric, and just wonder why it doesn’t work in seemingly light presets.

2 Likes

Agreed! I think it’s causing more DSP headaches than intended

2 Likes

IF Globeq uses 3&4 and we make chains on 1&2 the 2 cores should be linked in serial therefore latency will be probably worse (I don’t have access to source code but I Deduced this from some test). Anyway IMHO it should switch to 3&4 by itself when needed instead of disabling it. I personally ad 26% cpu with disabled globeq…

This sounds like a “NO CAN DO” according to the info on Discord, unfortunately

1 Like

Visually changing the grid so that rows 1&2 physically put items onto what would have been 3/4 is a viable workaround to achieving this without a significant rework or trying to fight hardware architecture choices made years ago. It achieves the same end-effect. But running the EQ (or the input block gate) on anything besides 1/2 doesn’t seem possible.

@SoundEngine - Bear in mind how the CPU monitor works - you have 4 cores, all of them are aggregated into a simple percentage - if one core is fully pegged at 100% that’s going to show “25%” utilization. If that core is the same one running the input gate and global EQ - then yes, it’s fully utilized and something has to “give” - so the EQ is disabled to make room for blocks. Because of this, and the inability to easily see what’s happening on each individual core saying or using a “low” utilization percentage as a way to describe this as a “problem” is flawed. The visual number you see is aggregate, the physical way processing is used is segregated - you can’t equate one to the other outside the most general sense of saying if you’re beyond 25% utilization, you’re using at least 2 cores to some degree, above 50% - using 3 cores to some degree, above 75% - using 4 cores to some degree. but you cannot infer anything more than that.

25% could be 10% of core 1, 5% of core 2, 10% of core 3 - or 100% of ANY given core or any combination across all cores, it could mean very little utilization (many cores), or quite a lot (1 core)

So it’s somewhat meaningless to use to determine when the global EQ may or may not function due to load.

The benefit in remapping the grid to flip the rows is just that human psychology is going to make people start adding blocks top to bottom, we “like” that aesthetically. We know cores 3/4 are going to be less utilized in general by the system and have more DSP available to the user so mapping the “human-preferred” build int he first 2 rows, to the “most available DSP” of rows 3/4 would likely allow the best user experience of filling those rows without encroaching on the global EQ.

Until then, if you KNOW you want to use global EQ - make yourself ok expending your presets into all of the available rows and try to keep DSP hungry blocks running on rows 3/4. That’s really it. Not the end of the world. Global EQ can’t be “free” the cost must come from somewhere. For now, understand HOW it works, and then adapt.

2 Likes

For whatever reason the architecture of these devices lends itself to global options (as well as perhaps other fundamental elements of the OS) being loaded up on whatever resources are allocated to the first two paths. Have no idea why, but it is not just the QC that operates this way.

Hopefully in future devices they figure out a way to work around this. It is really limiting as to what future features can be added without further impacting those first two paths. It also forces people to juggle the blocks in their presets so that DSP usage is split across paths. It would of course be much better if, as far as the user was concerned, all four paths were just one big “pool” of DSP and DSP management was executed under the covers, invisible to the user. Don’t know which, if any modelers work this way. No more juggling of blocks across path pairs! Hope the major players get there at some point but I don’t think it will happen on the current generation of hardware.

1 Like

Btw, I think they probably could probably add an additional “translation” layer, such that it would appear to the user that they could use any path to add a block. Doing this though, might require a substantial amount of programming time to create the layer, impose additional calisthenics every time the code was modified, e.g. for an update, or perhaps add latency. If there was an easy way to do it, I suspect the folks making modelers would have already.

1 Like

Latency concerns are likely the biggest reason why that hasn’t happened. This isn’t like the general purpose CPU in our desktops and laptops where things can be assigned freely without much concern for impact to the user if a poor scheduling decision or a cache miss means a certain task takes 15ms longer than it could have.

You schedule something on a modeler that has the potential of latency variations of 5-15ms RANDOMLY should a bad choice me made and you’re not going to have a very successful modeler.

Having very tightly controlled signal paths and routing is probably the only way these things work at all as far a satisfactory end-user experience

3 Likes

This! I just questioned myself what the point of a CPU monitor for the end user(!) really is if it is not meaningful. Maybe the load percentage of all four rows/cores should be shown or the percentage relative to single cores should be better accounted for in the total percentage… :thinking:

2 Likes

I like the idea of showing the CPU load per Core. Then we could easier optimize the presets.

1 Like

Settings → device options → diagnostics → DSP Diagnostics

With a pretty heavily loaded row 1 & 2 preset:

3 Likes

Yup, exactly like this but with just a summary percentage for each row-pair or row and placed in the CPU Monitor where it is useful while designing a preset, instead of buried in a menu.

2 Likes

Ah, thanks! Totally missed this option.

I programmed multicore multitask mcu’s. All can be done but is not an easy task (first time I did that I reworked all the code, everything started to crash, a real pain). If you want that block that needs another core imho is totally pointless if you or the qc activates another core. IF it does it by itself would be just better. This could free the routing options, now limited. IMHO the qc should report the latency in ms without the user taking care of core loading. It has AI for capture and cannot understand by itself how to minimize latency and core usage? Why we should care about core loading and measure the effect by ourselves, it makes no sense to me. Its like drivin car for good mileage without knowing the mpg and taking care of how many cylinders are firing while the road change our needs.
I got the QC since 3 weeks and I feel like I paid to be a beta tester. The more time I spend on it the more looks like a rich nerd toy to thinker with, instead of the workhorse I was expecting.

I got the QC since 3 weeks and I feel like I paid to be a beta tester. The more time I spend on it the more looks like a rich nerd toy to thinker with, instead of the workhorse I was expecting.

I think that was much more true with pre-2.0.0 versions. The QC to me now seems much more inspiring and I spent more time with it in the last two weeks than I did with it in the last two months. :wink: Not to say that there are still quite a few things that need to be taking care of. But this is also the beauty of this whole forum (and Discord): With feature requests and discussion, we get to shape the outcome of the product to a certain degree.

I just don’t understand how if I have a patch that uses 23% CPU, the global eq is disabled. Everything else put together is 23% but the EQ alone is over 77%?

This was discussed earlier - was there something that didn’t make sense?

1 Like

Rows 1&2 are supposed to share cores 1&2.

If they’re not sharing the workload evenly enough that it hinders global EQ usage even under minimal CPU usage like 23%, that seems a bug.

For instance, your screenshot shows the workload is pretty evenly distributed between core 1 & core 2. This is what should be happening in bug-free circumstances. I have not observed the supposed case where one core has 100% (or some significantly uneven distribution) of the workload.

If indeed one of the cores is taking on the majority of the workload for some reason and hindering the user from using global EQ even under light loads, that’s a mismanagement of the workload between cores which is a bug that should be fixed.

2 Likes

Imo you have some valid points there. I think NDSP just got started with the Global EQ and there surely will be optimizations in the future.

2 Likes