You can use a piano keyboard as input to a custom block. Open the long form input dialog (the one where you can say what type it expects), right click on the background, choose Menu, then choose Piano Keyboard. We know, that's not very discoverable. We're going to work on the user interface.
That isn't what i meant. I meant having the keyboard inside the input slot instead of as a popup.
Ah, I see. I'm unenthusiastic about that as a UI feature, because the resulting block will be huge, making scripts that use it unmanageable. I'd rather you make it a costume for a sprite on the stage. That's probably the right thing anyway, since the most common use would be a keyboard that plays in real time, even if it also records the notes played.
But of course you can write a little JS to do what you want, just for your own project!
Yea, but unfortunately, most of the source code and actual functions are completely uncommented or at least described making it really difficult to figure out how it works and how different components interact. Lack of documentation is what limits most of what I do. Great documentation always goes a long way and saves from a ton on unnecessary reverse-engineering. Yes, there are a lot of comments but most are over overview or over objects and not really over function or how to use something.
Ooh, criticizing Jens's code, watch out for lightning bolts! :~)
But I think I disagree in principle about commenting. The problem with commenting functions is that you have to already know what function you have to use, in order to find the comment that tells you. Much better would be to have a separate, coherent document that teaches the program structure, with annotated examples that transcend a particular function. More like "suppose you want to..." and then a walkthrough of inventing code to do that.
Sorry, you pushed one of my buttons; I'm fanatical about this because everyone else who teaches programming disagrees with me and likes lots of comments in the code. So, here's how I think about it: A program is more or less a tree structure, in which the top level is a big module with a particular function, perhaps it's one file in the source code, and then underneath that there are medium-size chunks, possibly including object definitions if it's an OOP-style program, and underneath that come the individual interface procedures that expect to be called from outside the module, and then underneath that might be subprocedures that are part of the implementation of some interface and don't expect to be called by anyone else.
So, in a perfect world, programmers would provide documentation in a parallel tree structure, with documentation at every node: the program as a whole, its large modules, its medium-size chunks, etc. But programmers are notoriously lazy about documentation, so you're not going to get them to write all of that. So, which piece of it should you ask for? I argue that the best thing would be really good documentation at the top couple of levels of the tree: documenting each module, and documenting the big chunks within each module. Instead of that, teachers insist on getting the least useful kind of documentation, namely details down at the leaves of the tree.
When I was working at IBM (every programmer my age has war stories about having worked at IBM), for every customer-visible program there was a document called the Program Logic Manual that you could buy, just like the user-oriented manuals. Those were the glory days of documentation! Nobody does that any more, more's the pity.
Also, yes, I do sort of agree. I'm not asking specifically for comments on every single line or every single function. Some place somewhere in existence that documents them would probably be much better. It's just that not having that much to go on means people have to spend hours trying to figure out what's going on in the source code and would have no idea how to use the methods and properties properly until they've looked through every reference or it is something that was mentioned in one of the headers. Also, I usually just look for keywords such as XML and try to see what the purpose of each element is in order to figure out how to use it.