MIDI Synth tutorial progress


#1

http://www.juce.com/doc/tutorial_synth_using_midi_input says:

This tutorial is coming soon.
Watch this space!"

How is this tutorial shaping up?  Do we have an ETA?

π


#2

This tutorial is on its way, along with a few others (afaik this specific one is almost finished). I'll probably meet Martin, the author of the tutorials, later this week and we'll figure out when we can release them. My guess is that most likely this will happen within the next couple weeks! (can't promise anything though)


#3

Having just read through the tutorials, I have some suggestions for the tutorial style.

It should be made clear that audio architecture is pull-driven -- i.e. driven by the speaker driver requesting samples, and any element in the chain is plugging in to such requests, either sending out similar request itself, or generating the audio.

Block diagrams would often be good for illustrating what is going on. e.g. https://developer.apple.com/library/mac/documentation/MusicAudio/Conceptual/CoreAudioOverview/CoreAudioEssentials/CoreAudioEssentials.html#//apple_ref/doc/uid/TP40003577-CH10-SW1

Is currently unnecessarily difficult for a beginner to understand the tutorial on playing a .WAV for example. It has too many moving parts simultaneously floating around. It makes perfect sense if you already understand each component.

Also a note on style:

while(true)       // [1]
    print("foo"); // [2]

1. infinite loop
2. Print 'foo' to console

... is an artificial and awkward way of communicating, as the reader has to stash something completely new in their head, scroll down often a page for the explanation, then up again for the next bit. Frequently in the tutorial this is done on 10 or so consecutive lines. Commenting should be inline, so the reader can grasp the concept as quickly as possible: minimise eye-darting and absolutely minimise scrolling.

 Also,

bool param1 = true;
bool param2 = true;

func(param1, param2);

Would be better written (less clutter):

func(
    true, // param1
    true  // param2
    );

π


#4

Hi,

Thanks a lot for your feedback, we'll discuss it. I actually find the [1], [2] syntax quite useful if you have a large chunk of text underneath the code and inside that text you have to cross-reference specific lines of code. Of course, if the job can be done with short inline comments instead, without the need for further explanation, I'd prefer that. Really depends on the text!

About the parameters style: here's the JUCE guideline (just double-checked with Jules about his coding style preferences):

Use extra named variables when they are initialised using expressions:

bool param1 = getSomeBoolValue (foo);
bool param2 = (x > 3) ? true : false;

func (param1, param2);

But use the inline comment style instead if the arguments are simple literals (note the brackets/newline style):

func (true,    // param1
      true);   // param2

#5

Can we get an update on this?  I'm still eagerly awaiting this tutorial.


#6

Hey darkbob9,

There are several tutorials in the pipeline. Basically, we need to find time to finish, proof-read, and upload them, which is a bit difficult right now as we're quite busy with coding! We really need more people to help us out with all that stuff :-)

I hope that we can finish and release this particular tutorial within the next month or so.