Free C++ Compilers and KX DSP

Discussion in 'Effects and the DSP' started by ROBSCIX, Sep 16, 2005.

  1. Lex Nahumury

    Lex Nahumury DH Senior Member

    Joined:
    Jan 5, 2003
    Messages:
    1,944
    Likes Received:
    6
    Trophy Points:
    0
    FYI: I just DL and installed latest Free VC 2005 + MS platform SDK.
    No MFC included ofcourse, needs SP2 and is alltogether quite a big download.

    Works just fine with kX SDK/API (not a big surprise really).
    So this is currently the only way to write kX stuff for 'free',
    provided that one uses an alternative to kxgui.

    /LeMury
     
  2. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    Yeha, I figured it would work as well, but it is good to know for sure. Thanks for the info.

    -Russ
     
  3. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    I just DL it too - its ISO is462MB - not for the dialups I'm affraid - but theyll send a CD if you pay a few $$.

    Im still looking at the tutorials you pointed out Russ - thanks they're very informative (took me a while to find the ones that arent making an app)

    I just would like to clarify something.

    Please answer with true or false...

    (APPLICATION RELATED)
    1a) I CAN make a 'console' app With MSVC++2005.NET and KX api.

    1b) I can compile console apps With MSVC++2005.NET and NO changes need to be made to any KX API source?

    1c) I can compile GUI apps with MSVC++2005.NET as long as I DONT use kxgui - and use another/make my own GUI.


    (PLUG-IN RELATED)
    2a)I CAN NOT develop KX plugins with tweak windows with MSVC++2005.NET- until I learn to make my own GUI for the plugin and not depend on kxgui ?

    2b) I HAVE to use VC++6 to make plug-ins WITH tweak windows?

    2c) I DO NOT HAVE to use VC++6 to make plug-ins WITH tweak windows when I can change kxgui source to use MSVC++2005.NET (and newer MFC) and recompile kxgui?

    2c) I DO NOT HAVE to use VC++6 to make plug-ins WITH OUT tweak windows.

    Soryy if I; asked this same q's twice or before/am dumb/retarded/cant read/hopeless case/etc.. - but I'm just a bit overwealmed in all this and Im not sure I completely understand. I think Ive been confusing what Ive been reading with application development with plug-in development.

    edit: Im still trying to learn what exactly MFC is - not expecting answer to this directly - but above answers will help me greatly.
     
  4. Lex Nahumury

    Lex Nahumury DH Senior Member

    Joined:
    Jan 5, 2003
    Messages:
    1,944
    Likes Received:
    6
    Trophy Points:
    0
    You need to download the Platform SDK as well and follow it's IDE integration/installation
    instructions to the letter or you won't be able to build 32-bit native code applications.

    You can do about anything with [VC2005 Express + MS platform SDk] as long as it doesn't need MFC.
    Why? Because it is not included, is not free so you don't have it.

    MFC is a commercial library that conveniantly wraps some win32 api functionality in
    easy to use classes. Still, underneath it uses plain win32api ofcourse.

    Most novice windows programmers start out with MSVC+MFC because 'it's so easy'
    and as a result know nothing about underlying win32api.
    This will 'bite them in the back' sooner or later simply because MFC isn't perfect
    and one needs to deal with the gory details of win32api afterall.

    Now what about kX GUI?
    kX GUI itself is one big wrapper that conveniantly wraps some MFC classes into kXgui classes! (still with me?)
    Why? Well, partialy to get uniform plugins but also to make it very easy to write a kX Plugin.
    With almost zero C++ knowledge one can write kX Plugins simply by copy&paste in the demo.
    Alot of kX plugins have been made that way.

    Well, since kxgui is 'build' around MFC it's obvious that you can't use kxgui if you don't have MFC.
    No harm done. Just create your own dialog and add the controls you need.
    This can all be done with plain win32api/windows common controls.
    Examples, win32api tutorials can be found all over the net, MSDN online,
    Mingw has one big [win32api Help] free for download.

    I admit, it's not as easy as ['no-brainer'MSVC6+MFC+KXGUI] but at least you'll have the feeling you actualy programmed something yourself rather then copy&paste.
    Another advantage is that one isn't dependant on kxgui nor by it's limitations.
    Resulting code is very 'mean and lean', no MFC overhead, no KXGUI overhead
    allthough no one will probably notice with mainstream (Ghz)PCs.

    I'd say; "Time to get your hands dirty Maddogg6"

    HTH,

    /LeMury

    [EDIT]
    PS: Note that I fully agree on the disision to use MFC for kXGUI at that time.
    As Max.M already mentioned; why spend another year to develop a custom kX GUI framework
    for the remote change that some (serious)programmer comes along that doesn't have MFC
    at his dispossal.
    And time has proven him right.
    Point is, 'wannnabees' come and go here all the time but rarely one of them actualy
    goes the 'extra mile' if you know what I mean.
     
    Last edited: Dec 31, 2005
  5. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    I do have this already (the only one I could find is 'Server 2003' tho.??).. but i'll prolly need to re-install - as I am having problems with some examples - Im starting to consider an OS re-install as well because of my drive space allocations (my strategy has changed a little, I try to keep OS partition to a minimum to keep defragging time a minimum for boot-time swapfile) so I Installed the WINPLATFORM SDK on another partition - thinking environemt variable would take care of its location - but not knowing I should store my projects relative/within it also - as Russ recommended.

    I do have what is supposed to be 'a full' (labled 'Not For Resale') version of MSVC2003.NET - but included no help (were probably discarded without out knowing what it was.) , just online - I find this cumbersome - as contectual help would make things way easier.

    AHHHH! No wonder - Ive been looking at/for winapi stuff (tutorials) all along - and never seen references to MFC besause of this. - I agree, knowing WinAPI will be MUCH more flexible - but is also contributing to my learning curve. I'll NEED a winAPI book also - knowing this now. I will get one - Can you recommend a good one?

    Ok - makes sense now - The MFC/KXGUI made it easy for those with DSP knowledge to jump right and not HAVE to learn C++.

    Ok - Im getting the MingW WinAPI help - but please do recommend a good book I can read in my - um, 'Library' or at the park.. etc.. lol

    Hehe - My hands are ALWAYS dirty - lol
    And yes it DID help very much -

    Ok - Choosing to use MFC actually equated to KX's maturity - indirectly, more time spent with GUI = less time for ASIO perfecting etc..... gotchya- makes perfect sense now.

    I CAN relate with other noobs 'frustration' as it is VERY confusing - even if you know other languages and understand what winAPI is for.
    - so It seems Im learning C/++ AND WinAPI AND KXAPI - all at once. Which I need to acheive my goal. Which right now - is to use KX DSP to decode DTMF (Based on Trills generous plugin he programmed JUST for me - Thanks again Trill) and cause action on my PC.

    And for those like me - its difficult to spend hundreds of $$ on VC (stores here only carry studio for $800 - or Borlands) - just to make a plugin that some one could already be working on and beat you to the punch/make better than you etc..

    Its a double edged sword... how many potential programmers were turned to wannabes because of the MFC?? - I can EASILY see that happening to - but YES I DO understand why MFC was used now. M$ *could* have an express version of MFC - one that operates on PC that has VCexpress installed on only - I think would have been a good comprimise - 'gotta pay if your gonna sell - but free if its just for me' seems like a logical way for M$ to go and entice new programmers and still stay in business.. ?? But Im a noob too.

    I am trying very hard NOT to be one who needs 'spoon feeding' - but C/++ is BY FAR the hardest language I've looked at to learn. - Even 65XX/68XX Assembly (because of my HW training) made more sense - as I understood (and could relate to) EXACTLY what the processor was doing at each opcode - I tend to revert to needing that level of 'comfort' that I know I'll never get with ANYTHING M$ - or any PC based C/++ I suspect. But of course Assembly is very difficult to manage large (or even small, by todays standards) projects. I only had made small test/demo programs and (lack of) technique is what kills me there.

    I still need to get familiar with VC's IDE too. Theres sooo much in there alone, and I havnet done much with PC based debugging - I was never sure if SW monitoring SW on same machine was ever a great idea (trustworthy?) to begin with. But its necessary - I will learn to love it Im sure.

    So thank you all; Russ, Trill and LeMury. I do hope to make something that ALL could use - but I have to say, AFAIK - KX is already covering all the bases I could think of for music production - the DTMF thing is something that scratches my 'Automation' itch - which stems from my hardware-itus training.

    Thanks again for your patients with me guys.

    One day - well have processors with flashable interpiters built in
    Need a new language - pop in another processor - theres room for like 20 more... lol - I dream, I know.

     
  6. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    'Programming Windows 5th Edition' by Charles Petzold is a pretty good book for someone starting out (as far as Windows programming goes).

    BTW: It is a little dated these days, so you may have to make some small modifications to some of the code used in the book to compile it.
     
    Last edited: Dec 30, 2005
  7. Tril

    Tril Triple screen racing ftw

    Joined:
    Sep 26, 2004
    Messages:
    1,665
    Likes Received:
    19
    Trophy Points:
    48
    For C++, I use "C++ how tro program fourth edition" by Deitel and Deitel ISBN 0-13-038474-7. It's the book I had to buy for an introduction to C++ class. I learned C++ with this book so I would say that it's good for a beginner. There is a lot of examples with the full code.

    Apart from that book, I use the internet to find information. I find the microsoft information found on MSDN a little hard to use because they don't provide examples for everything but it's still a very good ressource. There are often many different ways to achieve the same thing but MSDN does not provide examples for all of them. Sometimes, they give examples of code that are very complicated and that use a lot of code when only a few lines are enough if you understand what you are doing.

    MFC is supposed to be easier (I think) to use than the win32 api but from my very limited experience, I prefer the win32 api because I find it easier to understand. It's close to the basics (pointers, variables, etc). I still don't understand well the more complicated stuff like inheritance, pointer to classes or functions, derived classes, base classes, message handler, virtual functions, templates...

    I had trouble to get DirectSound to work in redocneXk and I'm still unsure if I'm doing it the best way. There are many examples of code for many of the features of DirectSound but they don't show the playback code. There are two pointers. One where the audio buffer is read and another where you write to the buffer. They tell you that you should program a way of keeping trace of where you can place the write pointer but they don't explain how it should be done and they give no code example. The explanations are probably very good but a less experimented programmer (like me or Maddogg6) can have trouble understanding. There's also the barrier of language (MSDN is in english).

    What I did is :
    Code:
    [size=2]
    ppDsb8G->GetCurrentPosition(NULL, &dwOffsetG);
    [/size][size=2]AppWriteDataToBuffer(ppDsb8G, dwOffsetG, ([/size][size=2][color=#0000ff]unsigned[/color][/size][size=2][color=#0000ff]char[/color][/size][size=2]*)ptrbuf1, BLOCK_SIZE);
    [/size]
    I get the position of the write pointer and I write there. It would be better if I did not have to use GetCurrentPosition for every block of data.

    I drifted a little offtopic.

    I don't know how the book I use is rated compared to other books as it's the only one I have.
     
  8. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Are you using the DirectX SDK?? - maybe this is an obvious question - but I assume those functions are; part of/explained in, the DX SDK??
    I did find an SDK (or API?? - not absolutly sure of the difference yet) for Sonar DX/i Plug-ins - which sounds VERY interesting to me.

    But I also have great interest in make use of some of the opensource stuff like with Csound - theres interesting stuff for that too with an API available. But I decided to first start with M$ compiler until I get a better understanding of the basics at least - and able to understand each of their caveates.
     
  9. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    @Tril, I cannot really comment about the DirectSound functions as I have not used them, and thus I do not know the specifics, but a pointer is really just a memory address. If you get the starting address once, you should be able to just increment the pointer's address by the size of the block of data (times the number of blocks) that you are writing to determine the next write address.

    <edit>
    After taking a very quick look at those DirectSound functions (and your MSDN quote), it ls more complicated with those functions than it would be with simple pointers, because the write cursor moves with the play cursor rather than the amount of data written. I am not sure if there is a better method than the one you are using as I do not know enough about the DirectSound buffers.

    <edit 2>
    Ater a little more reading: Although the address of the write buffer moves with the playback buffer, it looks like the value that you need is really just the offset and not the actual address, thus you should still be able to calculate this based on the size of, and amount of data written. In any case, it does appear to be more complicated with these functions, so without a solid understanding of this I will not try and offer any suggestions (additionally it looks like it might be a circular buffer (kind of like our TRAM), which could further complicate things). I have probably only confused you more at this point :(, but this is more complicated than the typical use of pointers, and I have not seen a detailed explanation of these buffers as of yet (the documentation I have found thus far is not great, to say the least).

    <edit 3>
    I think I should of just stuck with my original statment: "I cannot really comment about the DirectSound functions as I have not used them"... lol
     
    Last edited: Dec 31, 2005
  10. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    @Tril,
    I did find some info that might be useful to you.
    In your 'AppWriteDataToBuffer' function you are locking the buffer, right?
    If you set dwFlags to DSBLOCK_FROMWRITECURSOR in the 'Lock' function, the buffer will be locked from the current write position/cursor of the buffer, making the call to GetCurrentPosition unnecessary, thus you should be able to pass in NULL for the position of the write cursor, as that parameter is ignored when used with the DSBLOCK_FROMWRITECURSOR flag.
     
  11. Tril

    Tril Triple screen racing ftw

    Joined:
    Sep 26, 2004
    Messages:
    1,665
    Likes Received:
    19
    Trophy Points:
    48
    Thank you Russ. I'll look into it. If it works, it may help a little to reduce the latency when using DirectSound.
     
  12. Lex Nahumury

    Lex Nahumury DH Senior Member

    Joined:
    Jan 5, 2003
    Messages:
    1,944
    Likes Received:
    6
    Trophy Points:
    0
  13. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    I was looking at this and wondered how would one know what function alias to use for each of those functions?
    Are there patterns of charactors that can be recognized and converted with some automation? - or do you have to look up each func and try to match them and whittle the list down through with process of eliminations?
     
  14. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    Every compiler has it's own specific way in which they do name decorations. i.e. Each of the non-sensical looking characters has a specific meaning (i.e. number of parameters and type that the functions takes, as well as the return type, etc), so if you look up the info for the specific compiler you can figure out the original function, etc. Addtionally, much of it is plain text (i.e. the function name/class name), so you can generally figure out which function is which. As for what alias to use, it is just an alias, so I don't think it should matter what name you give it.
     
  15. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    BTW: Here is a pic of a working plugin GUI (made with Win32 SDK code only) that I am playing around with. I have not added many details to it, because I have just been playing around with it and debugging, etc, but it should give you an idea what you can do.

    http://tinypic.com/jjsh37.gif

    If you look closely, you will see that it is partially transparent, as well as non rectangular. I put the microcode dump in the background so that you can see that the sliders are functional.
    i.e.
    sliders:
    vol1 is at 50% (range is 0 to 100)
    vol2 (slider) is at 25%
    registers:
    vol1=0x40000000; ( 1073741824 / (2^31) = 0.5 )
    vol2=0x20000000; ( 536870912 / (2^31) = 0.25 )
     
  16. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    I guess I assumed those alias' would need to equate to 'something' for other references - so example code is as similar as possible..?? Im still learnin hehe.
     
  17. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    Well, since it doesn't work across different compilers anyway, you probably will not have to deal with it (if you could get it to work with different compilers than it you should probably use the name that the other compiler would use/is expecting). I think it is more useful if you are tying to use a VC++ dll with VB or something like that. I am not an expert on it or anything as I have never really had to deal with it myself.
     
  18. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    I forgot to mention that I did get the positioning to work.

    The only issue I have now (with using a custom iKXPluginGUI gui) is that occasionally the plugin window fails to be created. It seems to only happen under certain kX conditions. i.e. If I load the plugin and try to open the tweak window, after changing the DSP in such a way that the my plugin is assigned a different pgm_id than what it was assigned previously (if my plugin was loaded previously and the tweak window had been opened previously). The only indicator I get is a kx debug message "kX Mixer: an exception on creating plugin window.". This happens during the call to CreateWindowEx for my window, but when it fails, it seems to also exit out of my code completely, so I cannot even check the error code, nor can I do any cleanup.

    Have you (LeMury) noticed anything similar? This would seem to be a kX bug, but I would like to be sure that it is not something that I am doing in my code.

    Some notes:
    If I change the DSP while the plugin is loaded there is no problem (until I unload/reload the plugin, while receiveing a new pgm_id).
    If I unload the plugin, and change the DSP around is such a way that it is different, but my plugin receives the same pgm_id as before, there is no problem.
    If I have mutiple instances of my plugin loaded, and I leave at least one of them loaded when I make the DSP changes, there is no problem (even if I get new pgm_id's, and even if I never even opened the tweak window for the plugin that remained) until I again unload all instances of the plugin and then try to load one while receiving a new pgm_id.

    To recreate the problem:
    Load the plugin and open the tweak window at least once.
    Unload the plugin (it does not matter if you manually close the tweak window or not).
    Change the DSP in such a way the the next time the plugin is loaded, it will receive a new pgm_id.
    Re-load the plugin and try to open the tweak window.
    Quit kxmixer and then restart kxmixer to get it working again.

    BTW: I am using 3538i.

    -Russ
     
  19. Lex Nahumury

    Lex Nahumury DH Senior Member

    Joined:
    Jan 5, 2003
    Messages:
    1,944
    Likes Received:
    6
    Trophy Points:
    0
    No I don't have this problem, can't recreate it, and I don't think it's a kx bug.
    This is usualy a matter of (im)proper window class registration/unregistration
    but without seeing the code I can't tell for sure ofcourse

    /LeMury
     
  20. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    Thanks again LeMury,

    I got it working. I was not manually unregistering the class as it is usually automatic, and I had a check in there to not try to register the class if it was allready registered, and this worked without problems, except under those circumstances (I am still not sure exaclty why it was a problem under those circumstances, but I guess it does not matter). I remembered that I had added a class style that I usually do not use, when I was testing something out. I removed the class style, and that fixed the problem, and I added a call to UnregisterClass in the dtor of the window just to make sure it gets unregistered, and all is good now.
     

Share This Page

visited