Wusik 4000 Module SDK Docs Ready

[aciddose]

You can't possibly agree with this one:

Spaces vs. Tabs

Use only spaces, and indent 2 spaces at a time.

We use spaces for indentation. Do not use tabs in your code. You should set your editor to emit spaces when you hit the tab key.

What is the justification for that? Why not use tab and set tab to = 2 spaces? No really, what is the honest justification for never using a basic feature of ASCII?

A good rule is instead:

Always use tab for indentation, this allows you to configure tab-width to your liking and minimizes the size of tabs to a single byte, even if it is one, two, five or forty spaces wide. A tab must begin on the start of a line. Never use a tab mid-line after any other character but a series of tabs from the start of the line. For fixed-width indentation of data or otherwise use only spaces. This makes fixed-width indentation compatible with variable tab width.

[aciddose]

Also I'm not merely "spattering on a forum", I'm posting stuff here so anyone who like can point out how awesome/stupid/total shit it is and it can get worked out to a point where everyone is satisfied.

I may end up changing some of my own practices / style in the process.

For example I recently (only years ago!) switched from flat bracketing (on their own lines) to vertically condensed bracketing.

Code: Select all

if (condition)
{
 dosomething;
} 
else 
{
 ABORT!
}

vs.

Code: Select all

if (condition) {
 dosomething;
} else {
 ABORT!
}

This isn't significantly harder to read. It takes a little time to adjust, but you save so much vertical space this way it's hard to justify other styles.

Yes I know they have their names, I just don't really care to bother looking up the names of the style guides which happen to include things like that. It's somewhat irrelevant really as while I might agree with this one rule, I'll hate a lot of the other rules included so it wouldn't clarify anything.

Eventually I can go back and read over the thread and try to write up a style guide as WilliamK requested.

[mtytel]

Alright, I didn't mean to step on your toes when I suggested the google style guide.
I realize that it may seem like I was trying to one up you or negate all the recommendations you had by suggesting an alternative, and that's not what I meant. You offered a lot of good advice and if you collected it into a full guide that'd be pretty great. I only wanted to offer a current full style reference, one that I personally find useful.

If you forgive me and you're ever in San Francisco, I'll buy you a drink and we can talk coding style till they send us home.

[WilliamK]

If you forgive me and you're ever in San Francisco, I'll buy you a drink and we can talk coding style till they send us home.

Guys, I'm listening to all the talk here, but it will take some time until I can figure out how I can put all this into practical terms.

[aciddose]

Alright, I didn't mean to step on your toes when I suggested the google style guide.
I realize that it may seem like I was trying to one up you or negate all the recommendations you had by suggesting an alternative, and that's not what I meant. You offered a lot of good advice and if you collected it into a full guide that'd be pretty great. I only wanted to offer a current full style reference, one that I personally find useful.

If you forgive me and you're ever in San Francisco, I'll buy you a drink and we can talk coding style till they send us home.

I understood what you meant, I probably come off as a little too defensive/offensive when I comment on anything partially due to the way I dive right in without worrying about whether I've put things lightly/politely.

I only meant to point out things that people may not want to follow in the google style. Of course it contains many parts which make perfect sense.

After reading it through again in greater detail they actually have written in the detailed section regarding namespaces exactly what I wrote about. They didn't actually mean "Do not use a using-directive" but "...inside other namespaces or headers." Some of the rules they have seem on their face to be ridiculous until you read them very carefully.

It is really a good thing to look at many other existing styles and figure out which elements make sense and which don't when writing a new one so I do appreciate the contribution of the link very much. To see that sort of comment is exactly the reason I'd put effort into making these posts. Armed with a functioning human brain I may have prefaced my replies with this paragraph

[aciddose]

WilliamK, are you doing closed-source modules?

What would really help me to choose something to write as a test would be a list of all the modules currently available and information about their properties.

For example:

internal:
- filter (cutoff, res with 6db, 12db, 24db, 48db low/band/high)
- amp (volume, pan)
- envelope (linear adsr + keytrack with re-trigger input)

open-source examples:
- ...

I'm not sure for example if an "analog" style adsr would be useful or if you already have that.

[WilliamK]

All Wusik 4000 modules must be open-source, so there can't be any closed-source modules.

Ahh, a nice list, yes, I need to do that, sorry I haven't done so far. What you could do is just take a look at the Github files and see what I have done so far.

https://github.com/Wusik4000/Wusik_4000_SDK

But here's a quick list:

Effect:
Simple Reverb
Oscilloscope
Oscilloscope Mini
Low Pass Filter
Multi Filter

Filter:
Multi Filter Poly

Modulation:
LFO
X/Y Pad

Sound Generator:
Basic OSC
Single OSC
White Noise

MIDI:
Sticky Keys
Key Switching

[aciddose]

Okay, so maybe I'll do an envelope to test the interface for modulation, then a filter to test audio. I'll let you know when I have something.

[WilliamK]

Okay, so maybe I'll do an envelope to test the interface for modulation, then a filter to test audio. I'll let you know when I have something.

And ask me anything here, I will add those questions to the FAQ area in the doc pdf file. I'm also going to update the docs with more examples soon.

[WilliamK]

How about this?

Code: Select all

class WNoteEvent
{
public:
	WNoteEvent(int32 _type, int32 _channel = 1, int32 _val1 = 0, int32 _val2 = 0, int32 _delta = 0, int32 _voice = 0, uint32 _flags = 0, paramptr _noteFine = wv0, paramptr _unisonFine = wv0) : type(_type), channel(_channel), val1(_val1), val2(_val2), delta(_delta), voice(_voice), flags(_flags), noteFine(_noteFine), unisonFine(_unisonFine) {};
	void setNoteOn(int32 note, int32 velocity, uint32 _flags, int32 _delta) { type = Type::kNoteOn; val1 = note; val2 = velocity; flags = _flags; delta = _delta; voice = 0; }
	void setNoteOff(int32 note, uint32 _flags, int32 _delta) { type = Type::kNoteOff; val1 = note; val2 = 0; flags = _flags; delta = _delta; voice = 0; }
	int32 getNote() { return val1; }
	int32 getVelocity() { return val2; }
	int32 type, val1, val2, delta, voice, channel;
	uint32 flags;
	paramptr noteFine; // this is used to micro-tune / -1.0 to 1.0
	paramptr unisonFine;
	//
	enum Type
	{
		kNoteOn = 0,
		kNoteOff,
		kPitchBend,							// -127 to 127 (0 = middle)
		kMidiCC,							// Midi Control Change
		kMidiAftTouch,						// Midi After Touch
		kEmptyEvent,						// Internal Use
		kTransportStart,
		kTransportStop,
		kTransportContinue,					// This will also carry the position of the transport, and if this position changes at some point, a new event will be sent with the new position
		kEventsEOF							// Empty "End of File" Event
	};
	//
	enum Flags
	{
		kFlagFirst = 1,						// The first note played after all notes were released
		kFlagSteal,							// This note is stealing a voice to play
		kFlagLast,							// Last key been hold while in Mono mode
		kFlagReset,							// When set, an Envelope or Sound Source should re-start or sync its data, meaning its a new note for a voice that was idle
	};
};

[aciddose]

If you use the enum wrapper class (struct) that I posted earlier it'll enable you to use the enums as types for variables which can be really useful.

C++11 also has: enum class name { ... } which does exactly the same thing and also allows you to specify the type (int32_t, etc) for the enum values. That is the best thing to use although not all compilers in common use support it at this point.

It does solve the issue of namespace collisions by wrapping them in a parent class of course and to use them requires WNoteEvent::kNoteOn, for example.

Seems fine to me to do it that way if you don't want to use the enums as variables although I find it very useful to have type-safety for passing such values where normal enums are just of "int" type.

[WilliamK]

I understand the variable part, but for now we are not using it, so I will keep things simple if you don't mind. I'm changing all enums to go inside a class now, a lot of changes, but it does look better, thank you for pushing me into doing this...

[WilliamK]

Ok, updated all Enums now, and it does look better, thanks bud for the idea!

Here's the final file. Let me know if I did something bad.

https://github.com/Wusik4000/Wusik_4000 ... k4000mod.h

[WilliamK]

One part that I still don't like is that since I'm doing 32 and 64 bit versions, I need to worry about things like 1.0 and 1.0f. Or am I doing this wrongly? So far I'm using those wv1 Definitions for 1.0 and 1.0f, but if anyone has a better idea...

[WilliamK]

Of course, I will need to edit all module's code so it uses this new format. Compiled modules will still work with the new Wusik 4000 files, as it was only a semantic change to the Enums.