LeMury's new DSP mixer (was "KX plugins in SX")

Gonzo

LeMury:

Hello!...
I'm really sorry for the delay in checking your mixer but I've had a really busy week, far from home.
But all I can say now is THANKS A LOT!
It works wonderfully in my system and it perfectly suits my needs. :-)
I could only suggest some things from my humble point of view.

1) another send bus with return (with maybe a crossfade between ret1 and ret2) to be able to use two lines of FX in a setup without the need to repatch.

2) Another thing that would be cool would be to be able to record just a return bus, without hearing the clean signal. It would allow to record insert FX's without hearing the clean signal.

One thing I've noticed is that even when there is no other rec switch active, as soon as you engage the rec-monitor the signal present at the inputs appears at the recording outputs, regardless of the send's fader positions.
Please feel free to tell me if I'm being idiot as it is a very common daily activity for me...but I don't think this was intended to happen.
I would tend to think that only if there is a rec switch active, should be a signal there, but then again...I might be wrong.

3) It could be useful to have a kind of "tape monitor" (in a real console) input line, that goes straight to the main output without any send/rec switch, but a fader, mute and insert point to use a compressor or eq, sort of the MainBUS in my own mixer (it doesn't have an insert...I know). This way you could assign all output channels of the multitrack program there to monitor, while recording with the other inputs with their respective sends.

4) I'd only need just one more input channel in addition to what there is already (and the "tape monitor" input, if implemented). But as this would hopefully turn into a very useful and popular mixer, maybe the rest of the people needs more, how knows...

5) Then...while were dreaming, what about to fill all the empty space in the mixer window with a lovely recording VU meter?...He..he...I know it must be a tad difficult...sorry...I didn't say anything...

Thanks again for the time and dedication you've put into this project. Be sure that we really appreciate it!

Gonzo

Lex Nahumury

Hello Gonzo,

>I'm really sorry for the delay in checking your mixer but I've had a really busy week, far from home.

No problem, you informed me of your absense. I hope you had a good and productive time.

>I could only suggest some things from my humble point of view.

Sure, feel free to do so.

>1) another send bus with return (with maybe a crossfade between ret1 and ret2) to be able to use two >lines of FX in a setup without the need to repatch.

Ok, let me summerize/confirm to see if I understand correctly:
- 4 'real' Inputs + 2 Sends per Input
- 2 Returns ( do you want a crossfader or switch between Ret1/Ret2..?)


>2) Another thing that would be cool would be to be able to record just a return bus, without hearing the >clean signal. It would allow to record insert FX's without hearing the clean signal.

But that is already possible in the current approach.
Just check the Rec box on the Ret channel and un-check the others.
The Rec 'R' switches decide per channel if it's gonna be recorded or not.

>One thing I've noticed is that even when there is no other rec switch active, as soon as you engage
>the rec-monitor the signal present at the inputs appears at the recording outputs, regardless of the >send's fader positions.

Yes, thats's correct. As soon as you engage the RECMON, the MainOutBus and the RecOutBus are
literly Swapped..!! Give it some thought and tryout. You will see it makes sense.
Btw; the Sends only affect the FXoutBus and has nothing to do with the RecordingBus

>I would tend to think that only if there is a rec switch active, should be a signal there,
>but then again...I might be wrong.

Just keep in mind that you SWAP the MainOutBus with the RecOutBus when engaging the RECMON!
So, if RECMON is checked, the InputMix appears at the RecOutBus, and all Rec-selected inputs apear at the MainOutBus for monitoring.

>3) It could be useful to have a kind of "tape monitor" (in a real console) input line, that goes straight
>to the main output without any send/rec switch, but a fader, mute and insert point to use a compressor
>or eq, sort of the MainBUS in my own mixer (it doesn't have an insert...I know). This way you could
>assign all output channels of the multitrack program there to monitor, while recording with
>the other inputs with their respective sends.

Yep, Ok. in essence that would be just an extra (Playback) Input+mute but without send/rec.
Hmm..dunno about an 'Insert I/O' on the mixer for this Input since you can easily insert an EQ/Comp
between the KX-FXBUS output and our mixer to accomplish this.
Of course I could make a 'insert' I/O for this on our mixer, but I'm afraid it would be messy and an unjustified waiste of resources (GPRs).

>4) I'd only need just one more input channel in addition to what there is already (and the "tape monitor"
>input, if implemented). But as this would hopefully turn into a very useful and popular mixer, maybe the
>rest of the people needs more, how knows...

Well, I had planned 4 'real' inputs, so that's ok, and I will add the TapeMonitor Input.
As for other ppl; Besides you and me I haven't heard anyone else in this matter, so we just do our thing.
(if all works out, it wouldn't surprise me seeing you ending up making screenies and posting 'helps' again for this project...)

>5) Then...while were dreaming, what about to fill all the empty space in the mixer window with a lovely
>recording VU meter?...He..he...I know it must be a tad difficult...sorry...I didn't say anything...

Can you read my mind or something?.. It was one of the first things that came into my mind too..hehe.
Allready took a look at the peak code. Could be done, but I want a vertical VU...so I have to do some
more digging in the SDK. (btw, that empty space was for the rest of the faders..hehehe)

>Thanks again for the time and dedication you've put into this project. Be sure that we really appreciate it!

Thank you, that really helps me to stay motivated on this one.
I have a lot of other Kx-projects to work/study on, some smal, some big.
It's just my way of doing something in return to Kx, Eugene&Friends.
It may be small, but I have come to learn that every contribution to Kx-project is so valuable.
So it's really no problem Gonzo.

Ok,..Plz, give that RECMON SWAP a deeper look and comment back.
(I was quite pleased with that 'feature'....)

Cheers,

/LeMury

Eugene Gavrilov

vertical sliders aren't fully supported at the moment
you'll find an example of them in the latest sources (3534f) -- peak.cpp/peak.h

there's a flag:
int mode; // 0 - horizontal; 1 - vertical
which is '0' by default

I admit: not the best part of my code
but, anyway, as far as I remember, it worked (more or less )

/Eugene

Lex Nahumury

Yep, found it.
It looks quite..ahumm..impressive..
No serious, I'm glad you put that flag there. Could save me a lot of work..(if it works... )

Thanks Eugene,

/LeMury

Lex Nahumury

Mixer dev. progress

- Vertical Peak VU Recording meter added..! (duh..Eugene)

- 6 st.Channel inputs
- 2 st.Sends per input
- 4 Busses:
MainBus
RecBus
FxBus 1
Fxbus 2

- Every Input can be routed to Any, All or NO Busses..!
R=route to RecBus
M=route to MainBus
X=Mute input channel
Fx1=route to FxBus1
Fx2=route to FxBus1
RECMON=Swap MainOut with RecOut..!

Gonzo, would you plz beta test this version?
http://members.home.nl/nahutec/kxplugins/mx6.jpg
http://members.home.nl/nahutec/kxplugins/mx6.kxl

I have re-designed the whole thing to make it a General Purpose Mixer for
playback as well as recording, taking your setups as the design criterium.
E.g. you can use one channel as a "TapeMonitor" simply by routing only
that channel to the 'M' (main) Bus, and the rest to the 'R'(rec) Bus, or the Sends.
Oh well, you can record, route and send everything to everywhere.
feel free to comment/error report etc.

Two issues;
1.It's kinda huge on resources.
Such Mixers usual are, but if we run out of GPRs we have to cut somewere,
or I have to dynamically apply microcode changes in dll to save DSP GPRs.

2.The 'peak hold' text field gets garbled sometimes.
Mini/maxi-mizing the window fixes it (redraw).

Hmm...Eugene, cant we just have a 'Kprint' box or something in the SDK?
(Instead of having to mess directly with the 'ExtTextOut' function........)

Regards,

/LeMury

Eugene Gavrilov

>> ExtTextOut

please give a more detailed description of the function you would like to have
and, btw, any suggestions on the kX FX GUI stuff are always welcome
(probably, you will finally write the long-awaited E-mu APS-like mixer, since I simply don't have enought time for that )

>> Vertical Peak VU Recording meter added

I've already updated the kX-based peak meter to support both representations (vertical/horizontal)
there were very few modifications -- make sure to update your code when 3535 is finally out
(the kPeak interface was slightly modified)

also, one more thing: there's a possibility to create a per-plugin skin file
(that is, you can create a skin file that will be used for your kXL-based effect only)
if you are interested (for instance, in order to create a smaller peak meter...) -- let me know

/Eugene

Lex Nahumury

Eugene,

>>please give a more detailed description of the function you would like to have

Sorry. Well, I was looking for an alternative way to display the 'Peak Hold' Data since it got garbled.
(You used 'ExtTextOut' in peak.cpp source to display it. Probably for background color etc.)
Turns out I simply could use 'KStatic' like this:
// name.h
kStatic l_vu; // peak hold label
kStatic r_vu; // peak hold label

//name.cpp
l_vu.SetWindowText(tmp1);
r_vu.SetWindowText(tmp2);

Now it doesn't get garbled and can look like this:
http://members.home.nl/nahutec/kxplugins/mx6a.jpg

>>and, btw, any suggestions on the kX FX GUI stuff are always welcome

Ok, that's good to know.
I will let you know when I really need additional pre-defined Kx GUI Elements.

>>(probably, you will finally write the long-awaited E-mu APS-like mixer,
>>since I simply don't have enought time for that )

Quite possible. I know many (mostly new) Kx users would welcome this
because it would 'simplify' the DSP window usage.
One challenge however is to keep the same degree of flexability.

>>I've already updated the kX-based peak meter to support both representations (vertical/horizontal)
>>there were very few modifications -- make sure to update your code when 3535 is finally out
>>(the kPeak interface was slightly modified)

Roger,.. I'll keep an eye on that.

>>also, one more thing: there's a possibility to create a per-plugin skin file
>>(that is, you can create a skin file that will be used for your kXL-based effect only)
>>if you are interested (for instance, in order to create a smaller peak meter...) -- let me know

Yes I'm interested in this. If you have an example source or whatever please let me know.
(No need to re-invent the wheel)

Regards,

/LeMury

Lex Nahumury

Mixer dev. progress v1.07

Gonzo, ...(or other users),

Please test the next Mixer version for functionality:
unzipped:
http://members.home.nl/nahutec/kxplugins/mx6v107.kxl
zipped:
http://members.home.nl/nahutec/kxplugins/mx6v107.zip

Changes:
- Dynamic Microcode Change applied.
(Saves quite some GPRs)

- 'Peak Hold' text fixed.
No more text garble ( I left out the 'dB' sign for now)

Issues:
- VU meter is slightly 'Off" ( peak hold gives correct value)
I'll fix this later probably with new peak VU GUI.

Come on guys,... I need feedback on it's functionality...!!!
Comments, suggestions, questions, bugs whatever...
or am I waisting my time here?

/LeMury

Eugene Gavrilov

I currently have two ideas promoting the custom mixers:
- write a detailed guide (similar to Gonzo's guide, but related to the new custom kXL)
- include the kXL with the next driver distribution

of course, as soon as the guide is written, I will either link to it or publish it on our main site

/E

Lex Nahumury

Mixer dev. progress v1.08

http://members.home.nl/nahutec/kxplugins/mx6v108.kxl

http://members.home.nl/nahutec/kxplugins/mx6v108.zip

- Bugfix:
Channel 3 Rec Switch didnt' work.

/LeMury

Lex Nahumury

Good ideas..!
I think Gonzo is 'the right man' to help make such a 'Guide'.
His screenies are great and he really knows his stuff.

So,..Gonzo,..We need you!...Were are you?

/LeMury

Gonzo

Thanks LeMury for these kind words!
You amaze me...I'm absent for a few days and you've already made a brand new, full featured mixer...
First of all...sorry...I'm really sorry... but I haven't got time these days to be here as often as I would love to.
I have to finish two separate recording projects in the next couple of weeks for which we've already rented some mixing time at specific dates in a big studio...so I'm getting a little bit nervous, you know..he he...
So you might notice some delays in answering.
I'll promise that as soon as I'll be free, I can happily take the task of writing some tutorials for the new mixer. (If someone corrects my english).
In the meantime, all I can say away from my home PC :-( is that by reading your description about the features that are already there, I think it's almost complete.
I'll still have to wait some time to properly test it but it looks very promising!

Cheers
Gonzo

Lex Nahumury

Hi Gonzo,

Thanks for your reply.
I understand your situation of course.
Ok, here's the deal;

When you are ready for it, I would like you to test the Mixer in your 'real life' setups,
with Cubase and the whole 'shabang'.
I really need your feedback and input on it's functionality and usability to develop it any further.
After we finished all that, it would be great if you did the 'Help" Guide.

So, take your time, I will wait for you.

Good luck with the recording sessions.

Regards,

/LeMury

Eugene Gavrilov

>> Good ideas..!

so, guys, let me know when you are ready with the kxl and the docs
(LeMury, I will need the source code of the kXL)

/E

p.s.
btw, the vertical/horizontal peakmeter will be included in 3535 -- to be released very soon

Lex Nahumury

Yep, when 'da Gonz' and me are done I'll send the source code.
Eehhh,...you probably mean after 3535 release. Right?
(How else can I implement the new 3535 peak source.. )

One more thing:
How about that possibility to create a per-plugin skin file?
If you have time send me some info/example source or whatever.

/LeMury

admk

Hi guys,

Just thought i'd add my two cents worth....

This is a great mixer, I've been using it instead of the routing plugin, and for my purpose it is ideal.

I've tried these drivers a few times since the first release but always found the DSP a bit too confusing to work out and consequently switched back to the OEM drivers. But i 've found LeMury's Mixer is more muso friendly, being laid out like a normal mixing console with FX sends makes understanding the whole DSP and "virtual" cables things so much easier.

Once you include this mixer in your next release, along with the tutorial, i'm sure alot of new users will find the learning curve alot less steep, as I have, and you're sure to halve the number of "How do i?" Posts!!!!

I've got a couple of suggestions, not being the programming type I don't really know if its possible but I'd like to see an option to label each channel like a scribble strip on a console, also since i use this as the primary mixer in my default setup, would it be possible to include a switch to send either the recording signal or the main signal to the peak meter, or ideally include a second peak meter?

Anyway, thanks alot to everyone that makes these drivers possible, and a big thanks to LeMury and Gonzo for their work on this mixer!

Lex Nahumury

Hi,

>>I'd like to see an option to label each channel like a scribble strip on a console

Yep, that would be a nice feature.
But this would require a 'user text input function/element' for the DSP GUI,
wich, to my knowledge, is not (yet) available in the current SDK.

This part is up to Eugene...


>>would it be possible to include a switch to send either the recording signal or the main signal to the
>>peak meter, or ideally include a second peak meter?

Yes, both options are possible and I will implement one of them.
For now I will add a switch, untill I have made smaller VU peak meters.
(the Vu meters probably with the next SDK release)


Btw;
-You may have noticed that there are no task specific 'Return Inputs'.
I have choosen this topology to keep the mixer 'General Purpose'.
If you need a Return, just use one of the 'Inputs', set it's 'Sends' to '0',
and route to the 'M' or 'R' Bus. ( or both.. )

-I'm curious; How do you like the current RECMON function wich SWAPS the R and M Bus
for Monitoring purposes. Does it work for you?

-I'm thinking of re-labeling the 'FX' sends to 'S1' and 'S2', and the FXOut to Sout or something.
So we would end up with R, M, S1, and S2 Bus.
The reason for this is that the S Busses can also be used for other things than FX only.
Now it looks like it's 'fixed' to use as a FX send.

I want it to be versatile yet understandable.

Thanks for your input/feedback and stay tuned to this thread for Mixer Updates.

Regards,

/LeMury

Eugene Gavrilov

>> Eehhh,...you probably mean after 3535 release. Right?
>>(How else can I implement the new 3535 peak source.. )

I will release 3535 alpha soon (as well as the 3535 SDK), but the '3535 final' will be released later
so, I'm sure you'll have enough time for your modifications

>> 'user text input function/element'

you can use any MFC-based control, such as CEdit
perhaps, I should add a similar kX Gui-based control, too

/E

admk

LeMury,
Thanks for the tip, i already had the fx running into the last 2 inputs, reverbs set to 100% and all that...

I like that RECMON switch, it sorta gives me piece of mind knowing exactly what i'm recording, i like to record clean, but monitor Vocals wet......

Maybe you can label the FX sends as AUX1 and AUX2 as they would be on a console.

thanks again!

Lex Nahumury

Aha,..Ok, and I will mess with Cedit a bit..

/LeMury

Lex Nahumury

Not a bad idea, AUX..yes your right,..hmmm.
I was looking for a 1 letter abbreviation labeling like S1, S2, R, M and X.
I will think about it.

Thanks for the feedback.

/LeMury

Lex Nahumury

Mixer dev. progress v1.12b

Screenshot

Download KXL

Changes:
- Vu meter assignment switch between REC and MAIN bus
- smaller vu meter and smaller control panel
- Clip (hold) indicator
- VU numerical readout
- re-labeled some stuff:
M = MAIN bus -> MAINL/R
R = REC bus -> RECL/R
S1 = SEND1 bus -> SEND1L/R
S2 = SEND2 bus -> SEND2L/R

Issues;
Compiled for 3535 developer release.
Not (yet) tested with 3534.
;------------------------------------


Scribble strip for user labeling inputs:

Eugene,
CEdit worked fine for this, but after closing the CP, labels are erased of course.
So I need some 'char string' storage space for this.
Before I even start; Is this possable in the current plugin implementation?
(or/and like user can save it in a preset)

Regards,

/LeMury

Eugene Gavrilov

>> So I need some 'char string' storage space for this.

perhaps, a place for storing some parameters is required
it is already implemented

you will need to create a kSettings object:

// storing
{
kSettings cfg;
cfg.write("plugin_name","parameter_name","any_text _data");
}

// restoring
{
kSettings cfg;
char string[64];

cfg.read("plugin_name","parameter_name",string,siz eof(string));
}

----- browse settings.h for details -------

note: the settings will be stored in the registry and will be shared between all the plugin instances
(that is, kSettings uses HKEY_CURRENT_USER\Software\kX as a root key
if you specify 'AAA' for 'plugin_name', it will create a HKEY_CURRENT_USER\Software\kX\AAA subkey)

if you wish to create per-card settings, use "kSettings cfg(ikx->get_device_name());" instead
(in this case the root key will be HKEY_CURRENT_USER\Software\kX\Confi