Wusik 4000 Module SDK Docs Ready

[WilliamK]

For the C++ brave coders out there. Just updated the first draft doc for the Wusik 4000 Module SDK. (Windows/MAC)

Edit: this allows any C++ coder to create custom modules for our Wusik 4000 modular-synth project.

https://github.com/Wusik4000/Wusik_4000 ... aster/Docs

and the first Gain Effect example.

https://github.com/Wusik4000/Wusik_4000 ... n%20Effect

Soon we will work on more examples and update the doc with more information.

Best Regards, WilliamK

[WilliamK]

Just updated both PDF and source files with better examples.

[WilliamK]

Anyone?

[alihu]

Many thanks WilliamK !!!!!

[arakula]

What's that supposed to be, and why is it obviously closely tied to JUCE?

[paulbreeze]

http://en.wikipedia.org/wiki/Software_development_kit
http://en.wikipedia.org/wiki/Juce

[WilliamK]

@Alihu you are welcome!

@Arakula Wusik 4000 is a new modular-synth project by Wusik. It allows open-source custom modules to be created and used with it, and it's totally cross-platform, that's why it uses JUCE for the whole thing.

[WilliamK]

http://en.wikipedia.org/wiki/Software_development_kit
http://en.wikipedia.org/wiki/Juce

Thanks, this helps out, I forgot that some users here are not C++ coders. Sorry guys, my bad.

[aciddose]

I must protest regarding the unnamed enums, huge chains of if{}else where a switch statement would have worked and so on.

Most notable of the so-ons is that you're using:

Code: Select all

class name
{
 public:
contents...
};

When you could have used:

Code: Select all

struct name
{
 contents...
};

The preprocessor macro functions for accessing arrays are also horrifying.

Ah... also the double underscores... Isn't that space supposed to be purely owned by the compiler?

The more I look the more stuff I find. You might want to review the code quality a bit.

[WilliamK]

Got it, but please, help me out them?

[aciddose]

Well I don't want to try to force anyone to use a particular set of rules for code.

Generally though I use struct where the object is simply a container for data with maybe some accessor functions, but generally public data members.

When I use class the object is fully encapsulated, no public data members, usually the interface is abstract.

Any time I need to check more than three static == conditions related to a single variable I use a switch.

if (v == a) else (v == b) else (v == c) to me looks a lot more difficult to read than switch (v) case a: case b: case c:.

My header ifdef wrappers all use this format: inc_file_name.

If you're really worried about name collisions why not go with wusik4000_inc_file_name ?

Double-underscore isn't exclusive to the compiler, but the compiler is not allowed (or shouldn't be) to define anything without one. I find it useful to maintain this separation so that any time you see something like #if defined(__WIN32) you know it's defined by the compiler, while #if defined(WUSIK4K_WINDOWS_VERSION) is clearly code-defined.

Little things like that can make a big difference to readability in my experience. Although preferences vary of course...

I wouldn't be comfortable making those sorts of massive edits to your code (if that is what you mean by "help") unless you want to write a standard for the format of the code which I'm sure you could find a lot of voices wanting to put in their 2c here.

My own standards are changing over time and you can see when I wrote a particular piece of code based upon how it was written

[WilliamK]

Actually what you did was what I was thinking as help. Since I'm swamped with things to do here, and very tired already with all the hard work I have done so far on W4k, I need directions. Thanks for the effort. Not sure if I can do the changes right now, but I will keep those in mind. If you ever have the time and feel like, please, could you make a list of everything you would think would be good for me to change, with some examples on how to?

[WilliamK]

I must protest regarding the unnamed enums

And please, what does that means?

[aciddose]

You've used:

Code: Select all

enum 
{
 apple, banana, celery,
};

Which is "unnamed". Enums should have a name, like:

Code: Select all

enum fruit_vegetable
{
 apple, banana, celery,
};

When you use any sort of code analysis tool the enum will now show up as "enum fruit_vegetable" not "enum unnamed_13583".

Also, my recommendation is while waiting for proper enum class support from c++2011, wrap enums in a struct like this:

Code: Select all

struct fruit_vegetable
{
 enum T
 {
  apple, banana, celery, 
 }
 fruit_vegetable(int i) { v = T(i); }
 fruit_vegetable(T i) { v = i; }
 operator const T &() const { return v; }
 operator T &() { return v; }
 T v;
};

For this I use a macro function:

Code: Select all

#define encapsulated_enum_members(name, defaultvalue) name() : v(defaultvalue) {} \
	name(int v) : v(T(v)) {} \
	name(T v) : v(v) {} \
	operator T() const { return v; } \
	T v

Then:

Code: Select all

struct fruit_vegetable
{
  enum T
 {
  apple, banana, celery,
 };
 
 encapsulated_enum_members(fruit_vegetable, apple);
};

Then you can use the type fruit_vegetable as a type-safe variable for function calls, for example.

My favorite use is:

Code: Select all

fruit_vegetable v = fruit_vegetable::celery;

switch (v) {
 case fruit_vegetable::apple:
 ...
}

[aciddose]

Ah!

Also, please use namespaces.

Code: Select all

namespace wusik
{
 namespace _4k
 {
  struct mouse_event
  {
   enum T 
  {
        // Mouse Event Types
        invalid = -1,
        down = 0,
        up,
        drag,
        enter,
        exit,
        move,
        wheel,
   };

     encapsulated_enum_members(mouse_event, invalid); 

     struct flag
     {
       enum T
       {  
        invalid = -1,
        RightDown = 1,
        LeftDown,
        MiddleDown,
        MenuDown,
        ControlDown,
        AltDown,
        ShiftDown,
        CommandDown,
        WasClicked,     
        };

        encapsulated_enum_members(flag, invalid); 
     };
  };
 };
};

If you use structs this way to wrap the enums you can also forward-declare them and this allows you to put each type in it's own header.

Code: Select all

using namespace wusik::_4k;

function(mouse_event event, mouse_event::flag flag)
{
  switch (event) {
   case mouse_event::down:
    if (flag == mouse_event::flag::LeftDown) { 
    }
   break;
  }
}

Of course I'd use slightly different methods like a struct with several bools, one for each button, but that's an aesthetic choice I think.