Wusik 4000 Module SDK Docs Ready
- Banned
- Topic Starter
- 5089 posts since 12 Jun, 2001 from Wusik Dot Com
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
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
Last edited by WilliamK on Wed Nov 20, 2013 3:55 pm, edited 1 time in total.
- Banned
- Topic Starter
- 5089 posts since 12 Jun, 2001 from Wusik Dot Com
- Banned
- Topic Starter
- 5089 posts since 12 Jun, 2001 from Wusik Dot Com
-
- KVRAF
- 1940 posts since 16 Aug, 2004 from Vienna, Austria
-
- KVRian
- 1111 posts since 6 Jul, 2009
- Banned
- Topic Starter
- 5089 posts since 12 Jun, 2001 from Wusik Dot Com
@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.
@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.
- Banned
- Topic Starter
- 5089 posts since 12 Jun, 2001 from Wusik Dot Com
Thanks, this helps out, I forgot that some users here are not C++ coders. Sorry guys, my bad.
- KVRAF
- 12555 posts since 7 Dec, 2004
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:
When you could have used:
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.
Most notable of the so-ons is that you're using:
Code: Select all
class name
{
public:
contents...
};
Code: Select all
struct name
{
contents...
};
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.
Last edited by aciddose on Wed Nov 20, 2013 4:05 pm, edited 1 time in total.
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
- Banned
- Topic Starter
- 5089 posts since 12 Jun, 2001 from Wusik Dot Com
- KVRAF
- 12555 posts since 7 Dec, 2004
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
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
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
- Banned
- Topic Starter
- 5089 posts since 12 Jun, 2001 from Wusik Dot Com
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?
- Banned
- Topic Starter
- 5089 posts since 12 Jun, 2001 from Wusik Dot Com
And please, what does that means?aciddose wrote:I must protest regarding the unnamed enums
- KVRAF
- 12555 posts since 7 Dec, 2004
You've used:
Which is "unnamed". Enums should have a name, like:
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:
For this I use a macro function:
Then:
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
enum
{
apple, banana, celery,
};
Code: Select all
enum fruit_vegetable
{
apple, banana, celery,
};
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;
};
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
Code: Select all
struct fruit_vegetable
{
enum T
{
apple, banana, celery,
};
encapsulated_enum_members(fruit_vegetable, apple);
};
My favorite use is:
Code: Select all
fruit_vegetable v = fruit_vegetable::celery;
switch (v) {
case fruit_vegetable::apple:
...
}
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
- KVRAF
- 12555 posts since 7 Dec, 2004
Ah!
Also, please use namespaces.
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.
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.
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);
};
};
};
};
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;
}
}
Free plug-ins for Windows, MacOS and Linux. Xhip Synthesizer v8.0 and Xhip Effects Bundle v6.7.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.
The coder's credo: We believe our work is neither clever nor difficult; it is done because we thought it would be easy.
Work less; get more done.