MixControl Pro (Group Buy Started)

[Bronto Scorpio]

The GUI looks awesome

Cheers
Dennis

[GeorgeZ]

Or maybe perhaps instead of two version make both interface accessible from the same plugin (a switch)? Kinna like what EQuality does

Ye, but the reason I used small for tracks was because it was (and don't get me wrong, large was stupidly light on CPU already) unimaginably low on CPU, so I could run 10 or 15 or how many ever instances I needed without even thinking about it.

2 interfaces in one will be just that, 2 interfaces with the same engine in the back, unless if it switches some parts of the code "off" to conserve CPU when switched to small... then it might work.

[3ee]

I like the small GUI idea, but I don't like it to have less features. (or is it me not finding the limiter and the stereo tool for exemple?)

I guess I would be happy to use the small version if all the features are there.
The large version seems to large for me. ...maybe a "normal" version will solve some problems.

[GeorgeZ]

That kinda negates the point of what small was intended for. It was intended as a track tool, not a complete mix tool. That's wy soem of the features were left out. If the small version has the exact same feature set of large, what's the point of having small apart from "because the GUI is smaller"...

[3ee]

That kinda negates the point of what small was intended for. It was intended as a track tool, not a complete mix tool. That's wy soem of the features were left out. If the small version has the exact same feature set of large, what's the point of having small apart from "because the GUI is smaller"...

Well.. I didn't knew what it was intended for.. I thought it was simply a smaller version with less features.

[GeorgeZ]

Originally there wasn't even a "small" version written, but it was suggested during the very early beta (original beta or one of the point betas, I can't remember) iirc as we commented that MC was nice and could be used as a channel strip as well, but needed to be even more light weight than what it already was to accommodate at least 10 or so instances. Small was born out of necessity

[softska]

Ye, but the reason I used small for tracks was because it was (and don't get me wrong, large was stupidly light on CPU already) unimaginably low on CPU, so I could run 10 or 15 or how many ever instances I needed without even thinking about it.

2 interfaces in one will be just that, 2 interfaces with the same engine in the back, unless if it switches some parts of the code "off" to conserve CPU when switched to small... then it might work.

Never realized small version use less cpu, but how much less? Honestly with how little it eats I've trouble believing it matters.

[geroyannis]

Ye, but the reason I used small for tracks was because it was (and don't get me wrong, large was stupidly light on CPU already) unimaginably low on CPU, so I could run 10 or 15 or how many ever instances I needed without even thinking about it.

2 interfaces in one will be just that, 2 interfaces with the same engine in the back, unless if it switches some parts of the code "off" to conserve CPU when switched to small... then it might work.

Never realized small version use less cpu, but how much less? Honestly with how little it eats I've trouble believing it matters.

On my old AMD dual-core the small version consumes 0.6% of the CPU with 2 bands of EQ and compressor enabled. The same settings on the large version eat 0.7% of the CPU, and if you turn off the FFT display it also uses 0.6%. So, the only difference between the two is that the large uses 0.1% more CPU for the FFT display. That's not a big difference, is it?

[GeorgeZ]

Yup, fair enough. Now, how bout you fire up 10 of each in two separate sessions with the same 10 audio files running through each session with appropriate processing applied in each instance. I'm sure Reason didn't pull and extra one out of his ass for nothing I will say this though, as far as PC specs and SW development is concerned, the time all this happened, would today be considered "ages ago". As such it may be of less concern these days. Truth be told, being on a i2600 system, I couldn't really care less about CPU consumption, cause you really need to pound it to even have all the cores fire up. On my 6000+ though, this was a different story, and every 0.1% of CPU I could save I would take...
or is everyone running a i2600 now?

PS: I did make particular mention of the fact the Large was stupidly low on CPU as well... didn't think it was a difference of only 0.1%, and find that a bit hard to believe, but then again, Reason's main concern in the end, after the features were developed was to keep the CPU consumption VERY low. Mission accomplished, but are you automatically expecting the same result in this current / new incarnation? i wouldn't be so hasty with a decision just yet

[geroyannis]

OK, I did this test in Reaper. There's a project loaded with 12 different audio tracks. On each track I load a small and a large version with 2 bands of EQ and compressor loaded. After that I bypass all the small versions and check CPU consumption, then bypass the large versions and check CPU. These were my findings on an AMD dualcore 3800+:

12 small versions enabled: 5.20% CPU
12 large versions enabled: 4.98% CPU
12 large versions enabled with FFT display off: 4.95% CPU

Much to my surprise, the large versions consumed less CPU!!!

I hope someone else can do a similar test and share his/her findings.

[3ee]

feature request: perhaps a reset button for the eq.

[MaxSynths]

yeah never used the small one either

The small version was for people who just wanted to do quick tweaks

Right...

I'm not 100% sure if that is serious or sarcastic, but if you are a fan if the small version, please let us know.

No no I was serious I would keep the small version, is very useful when you want to use MixControl only as an EQ for every track for example. Above all I really like the EQ section and I would like to see an EQ only version of it, so from my point of view it's not a good choice to eliminate the small version

[DNR Collaborative]

No no I was serious I would keep the small version, is very useful when you want to use MixControl only as an EQ for every track for example. Above all I really like the EQ section and I would like to see an EQ only version of it, so from my point of view it's not a good choice to eliminate the small version

Points noted, we're looking into a number of solutions for this Thank you for the feedback.


Steven

[musikmachine]

Yeah please keep a small version around. I use the small version on individual tracks and the main one on the master. I'd hate to lose that. Cheers.

[softska]

Yup, fair enough. Now, how bout you fire up 10 of each in two separate sessions with the same 10 audio files running through each session with appropriate processing applied in each instance. I'm sure Reason didn't pull and extra one out of his ass for nothing I will say this though, as far as PC specs and SW development is concerned, the time all this happened, would today be considered "ages ago". As such it may be of less concern these days. Truth be told, being on a i2600 system, I couldn't really care less about CPU consumption, cause you really need to pound it to even have all the cores fire up. On my 6000+ though, this was a different story, and every 0.1% of CPU I could save I would take...
or is everyone running a i2600 now?

PS: I did make particular mention of the fact the Large was stupidly low on CPU as well... didn't think it was a difference of only 0.1%, and find that a bit hard to believe, but then again, Reason's main concern in the end, after the features were developed was to keep the CPU consumption VERY low. Mission accomplished, but are you automatically expecting the same result in this current / new incarnation? i wouldn't be so hasty with a decision just yet

True, even if I disagree, backward compatibility between versions still important (as long as it's still called MixControl anyway).