Russ

First you tell it to use the Standard Windows Libraries instead of MFC.

Then remove the MFC headers (usually the header files begin with AFX* (replace with Windows.h)).

Then remove any MFC classes that you are using (this is a little more complicated, but if you look up info on the class in MSDN, you should be able to determine if it is a MFC class). You would not have to worry about this so much, as you probably do not use any MFC classes on your own, so it would just be a matter of not using kx GUI.

BTW: If you think you are lost now using kX GUI, I think you are going to be lost even more trying to use the generic plugin GUI class (at least without some skeleton code that shows the basic stuff to use for reference (no examples in the SDK)).

Max M.

>I think that FxBus and epiloglt are special cases, and they do use resources when we use them in our code.

no, no - they both never use resources (connected or not - all they use is hardware i/o registers - they are always there - you cannot "allocate" them you cannot "free" them so in that context they are not "resources" at all)

>do outputs use a GPR?

yes, 'outputs' are 'gprs'. ('inputs' are those variable that are not registers - but a sort of 'placeholders')

>For example, the compressor plugin ... total = 13 GPRs ... counter shows ... 11

Yes, kX does not count 'inputs' in its "GPR" meter (sorry, i misinformed you in prev. thread - i forgot this was a sort of fixed at v36, but note: inputs are still counted in plugin 'info') - more over it actually also counts hw i/o correctly (e.g. does they are not counted in 'GPRs meter' - another misinfo from me) - except fxbuses.
[color=gray]
Hmm, this makes me to concern that FXBus implementation is dirty - i start to think that it does allocate gprs when loading and only after that replaces allocated gprs by fxbus registers (without freeing 'replaced and unused gprs')
- hmm, this is the thing to think of (if so then we have been wasting 16/32 registers for 5 years ) - i need to consult with E. on this...
(looks like i just could not believe it can be done so wrong... doh!)

edit: although see: http://kxdev.narod.ru/fxbuses.png - definitely - we need to ask E. what the heck is this (screenshot shows that my concerns are unfounded - and it just counts fxbuses because they are declared as outputs but it did not really allocate any dummy gprs - e.g. it's all ok)[/color]

edit2: grayed out 'fxbus panic' info to avoid confusing

Russ

I knew it was either inputs or outputs...

Just for clarification:
Inputs do not count as a GPR? (i.e. they do not use a GPR resource?)

I understand that the plugin 'info' is a register counter and not a GPR counter (i.e. TRAM addresses (read, write, and the address pointers are all counted as a register in the plugin 'info')).

Thanks for the info.

Maddogg6

hehe - You're most likely right - Im just asking the Q's as they come to me.
Unfortunately the become my 'blinders' - when I don't understand concepts.

It just seems like there sooo much going on 'behind' the scenes.
I mean I understand headers are used to reveal functions contained in libs in a way that keeps the libs 'private' - this is kinda a new concept for me.

the last thing I want to do is get on yur nerves. . I'll let you all get some much deserved peace... lolz

Thanks again for all the help

Max M.

>Inputs do not count as a GPR? (i.e. they do not use a GPR resource?)

Yes. 'input' is an abstract concept.

Russ

Well much of the Windows API is C code or C/C++ mix.
MFC wraps this stuff up into C++ classes (it is the C++ classes that makes things easier). You can do this yourself and make your own GUI lib (wrapper classes), but it is not something that is easy to do for a beginner, and some of the WinAPI is undocumented.

Maddogg6

So - is the the 'supposed to be' - but.....


this is the reality (for FXBuss anyway)..
??

too late

phwew - so... its not just me thats defective *small sigh of relief*

Russ

Thanks again
So, I guess it is just FxBus that throws off the GPR counter.

No, I think it is just mis-counted by the GPR counter, but the plugin loader knows the true count (otherwise it would not load when you do not have enough free GPRs).

Lex Nahumury

Yep of course,.. not using KXGUI is the whole point!
(That's what i have been yelling all along as you may know)

I just wanted to make sure that using (free) >VC6 suites (.NET/PSDK etc.etc.)
to produce a .kxl while NOT using KXGUI is 'trouble free'.

'Trouble free' in the sense that one;
- can write .kxl plugins with a Free MS compiler/IDE
- doesn't need to supply any additional M$xxx DLLs,
- can produce Debug as well as Release builds,
- doesn't has to update his/her plugins (all the time) with every new kX driver release
.[COLOR="Gray"].. and whatever I forgot[/COLOR]

Do you agree that these statements are correct?

Russ

Yes, I would agree with that (and yes, I know what you meant).

Lex Nahumury

'fxbus panic'
Man,.. how do you come up with such phrases?

Lex Nahumury

Ok and thanks for the testing.

Btw; there's no need to write a GUI lib from scratch.
Depending on license issues there are enough free opensource alternatives to MFC.
Even VSTGUI (which is all about skinned controls) is opensource now.
FLTK is also a nice one IMO. (I have used it alot for quick VST dev/testing)
Anyway, shouldn't be to hard to adapt something for kX plugins.

Russ

Do those GUI libs add any dependencies of there own?

(i.e. do they add any dependencies to an exe/dll that uses them?)

<edit>
Nevermind, I'll look up the info.
</edit>

Lex Nahumury

nope. btw they are even cross platform.

Russ

Ok, thanks for the info, I will check them out.