DSP reduce idea

[Tassy]

In upgrade versios precalculated DSP need is alvays increasing, so v8 has now a 10-12 % DSP increase compared to v6
I mixed a song in v6 at 90% DSP. great. Now play witht he thought I forgot it and want to mix the same in v8. What will happen?
I reach the final mix about 85-90% ready but DSP goes red and I have to make compromises to finish the song thus never be the same quaity as it was in V6 or as I would like to have it.

What can be done?

My suggestion is that the new features, that are fine to have but push up DSP, should be made either as an option in the install dialogue  (e.g: I never use cue) or even better make it activated or not in the full install in the preferences menu. (if active or not influences DSP)

I also thik that not all of Mixbus users use all the features, but would need more DSP at theit disposal.

I am not programmer so do not know whoch variation is easier or safer to use but I am sure it would do good even for having more Mixbus users if DSP does not run over due to features one does not want at all or just does not need in certain mixes.

An other suggestion by my friend John to make a Mixbus "32C light" version with the bugfixes but no more new features than v6 had

I hope it makes sense

Wonder what you guys think of it, would this be useful for some or more of you?
Thanks
best
Tassy

[johne53]

Early last year there was a sudden interest here in some software called Audio Gridder. If you're lucky to have a 2nd PC networked to your main Mixbus machine it'll allow VST plugins to use the CPU from the networked machine which frees up DSP time for Mixbus. I found it made a huge reduction in Mixbus's DSP figures - BUT - it had quite a serious drawback...

Let's say you've three plugins all with an animated display, Audio Gridder can only animate one display at a time - so if the plugins all show audio meters, only one set of meters can be active at any one time and the others will effectively be frozen. It doesn't affect the audio - just the GUI display. It's a pity though - 'cos the improvement it made in Mixbus's DSP reading was quite impressive.

[Sojuzstudio]

Imagine if Mixbus made it possible to use the Raspberry pi stack as a DSP server. Let's say 5 pcs of Pi connected as dps slave. via Ethernet.

[PBuryk]

@Sojuzstudio -
This is EXACTLY what I've been wondering for the past couple months!!!
+1 !!!!!!
Cheers!
Patrick

[Tassy]

This thread is not about workarounds, and introducig more "outboard" 3rd-party stuff!
It is about Mixbus, how its DSP consumption could be reduced within itself.
Very simple.
Added features require added DSP usage.
Thus the added features should be made active or not in preferences.

A mixer knows what a song he or she is mixing. If midi is not in the song it could be made inactive, If cue is not in the song it could be deactiveted. etc:
It is not very complicated
Tassy

[johne53]

I must admit, it does seem strange that new versions always increase the DSP figure - even if the new features aren't getting used!

I wonder if there's maybe an issue with the session files somehow? i.e. handling all those extra new session objects is what's really pushing up the DSP usage?

[Tassy]

As I remember early Mixbus explanations of Harrison that MB is "precalculating" the DSP expectations for the mixbuses, built in EQ Compr etc. MIDI handling, now cue... and that is the reason an empty project is not started at 10% DSP (no plugs, no sends not even tracks ) but 40, 50. 60 % as the software gives ever more options to be used. Therefore making them a choosable option would help MB to be used more effectively if the mixer decides for a song what he needs and not MB offers everything as default some of which will not be utilized in the certain song at all

The other little increse may be due to, thanks God, the bugfixes if no new feature is added but the software got more stable, just a layman's thoughts

[ROG]

Not a problem, as I see it. Each time you upgrade, you keep the previous version as well - at around 425MB on disk it's not over large to do this. Then you just boot whichever version suits your project, moving up versions if the project develops into needing extra features. It's quick, it's easy and it's so simple it makes me wonder if I've missed the point somewhere.....?

[madmaxmiller]

Imagine if Mixbus made it possible to use the Raspberry pi stack as a DSP server. Let's say 5 pcs of Pi connected as dps slave. via Ethernet.

You can do that. But I have to say the J-word. JACK makes this possible for at least 15 years now.
MMM

[johne53]

It seems like we've two distinct problems here:-

1. Each new MB release increases the DSP usage for no obvious reason - i.e. simply having new features increases the reading - even if they're not getting used.
   
2. Plugin usage then increases it even further.
   

So what's needed is some way to transfer those extra requirements so they could get handled by some external device. AudioGridder does a pretty good job at the moment - it just doesn't do an exceptional job. I wonder if the Jack devs could be persuaded to take a look at AudioGridder and see if they could do something similar - but better?

Or as Tassy suggested, maybe Harrison needs to introduce a"light" version - or some means to enable & disable features in the full version?