I understand. However I prefer to use (library) functions “as-is” - if possible, of course.
Yeah, sorry. I didn't really understand what you were asking for. If it's just a dotted quarter note, you can just type in "dotted quarter".
I've never heard of a dotted quarter note referred to as a 3/4 note.
A 3/4 note is a Dotted Half, actually. 
Yeah, I was thinking that, I just didn't type it, lol.
In musical notation a dot behind a note means it is played 50% longer.
To keep things clear - the following matters are still open:
- How can one express a 5/8 note in Tunescope? (post #4)
- Is there an easy way to combine chords and simple notes within one track? (post #6)
- The Tunescope documentation, on Learn to Make, that the Snap! Reference manual refers to has some issues. (post #1)
Update on question 2
I found an easy way myself. I replaced the TRACK block with:
… where:
What it does is replace any single note within a sequence with a chord consisting of the note and two R’s (= rest); the pre-existing chords are left as they are.
I’m not even sure if the two R’s are required. A list with the note as single element appears to work as well - but since chords are defined as having a three elements or more, I added them anyway, “just in case”.
Another useful TuneScope extension block
Suppose your music score consists of many measures, and you need to add a track consisting of just one small part, like a few trumpet blows during the last seconds. You can use the following block to insert R’s during the preceding measures:
Here’s an example of its use. A piece has a flute track and a piano track. In the last part, the flute is replaced by a trumpet:
The standard music notation way to do that would be to use a tie: a half and an eighth note with a ⁀ spanning both of them. I don't know if Tunescope has a notation for that.
But there's a limit to how far you can take such questions. There's no notation, afaik, for a seventh note in our standard music representation. Other cultures have other notations, and also, weird modern musicians who want things like seventh notes make up their own notations.
It doesn't, but it does allow you to enter numbers as durations... in seconds. I really don't like this because music doesn't use seconds for time, it uses beats per second minute, and snap (and scratch) already has a play note block that uses a note duration, which is not the same as tunescope. In order to get note durations that use beats instead of seconds in tunescope (for doing stuff like making ties), you need to do some math (or just edit the block to remove the seconds conversion). Of course you do need to do math for the play tracks block, because the seconds conversion is done in javascript.
:~P
I just realized my mistake, it's beats per minute, lol. I'm even doing marching band right now.
No, no, it's plain "beats," not per anything. The context was "music doesn't use seconds for time, it uses ___" and the unit of time is the beat. "Beats per second" (or per minute) is the unit of tempo: how long in actual time is a unit of music time. (EDIT: Well, okay, the unit of tempo is actually the reciprocal of that, seconds per beat.)
Well, anyway … @ego-lay_atman-bay has a point: it’s somewhat inconvenient that Tunescope (being its authorized music library) doesn’t fully support Snap!’s tempo system (though I’m not sure what it does with numbers for notes - especially with very low tempi, below 20). Perhaps that’s another thing @glenbull (and you?) could look into during college break.
bh isn't even a developer of the library, so he can't really do anything.
I could learn how it works, I suppose, but I'm not going to, because Glen has students, who are basically indentured apprentices, to work on this. :~)
@ego-lay_atman-bay: Would you have a look at my suggested TuneScope improvements? I’m looking forward to your (well-informed) comments.
I’ve also been experimenting with duration-to-real-time conversion, with tempo (bpm) as parameter, but I’m a bit puzzled. My impression is that will actually take the tempo setting into account when duration is specified as a number (it’s coded like that, and it can be measured). It seems however that TuneScope will regard any tempo setting below 20 bpm as 20 bpm. Plus with many tempi it will distort melodies. I’m curious as to what you found.
I would love to, but I don't really understand what you're proposing. Can you tell me which blocks you added / changed, and what the differences are?
All blocks are categorized Tunescope+
Modified TuneScope blocks:
-
SECTION: more efficient code;
-
TRACK; more efficient code + Chord type tracks will now allow single notes, too (by converting them to chord-format); thus chords and single notes can be combined within a common track;
-
♪ a shorter version of NOTE;
-
NOTE DURATION (~ VALUE): I corrected the durations of Eighth ~ and Sixteenth Triplets;
-
CONVERT MIDI TO NOTE / NOTE TO MIDI; I added range checks (C0 = 12 .. B9 = 131), and introduced meaningful error messages;
New blocks:
-
⋮ (CHORD): a block to specify any random notes combination as a chord;
-
ALL CHORDS: converts a sequence of notes and/or chords (w/durations) to a sequence of chords (w/durations). Is called by my version of TRACKS (see above);
-
ALL R: reports a sequence of R (rest) -s that is equally long as the input sequence; for easy synchronization between tracks;
-
RAISE: raises all notes and chords within a sequence by the same number of steps (e.g. -12 steps = 1 octave lower);
-
INVERSION: a block for inversion of a chord (a well-known operation in music), in both directions;
-
REST: a specified number of rest measures; again for easy synchronization between tracks.
Thank you in advance!
Both of these are great
Personally I would think it's better to use the word "note" rather than a unicode symbol, because some devices may have a font that doesn't have the symbol.
That's good.
The error message is good, although I would not restrict the octave range.
This is a good block, although I would use the snap symbol instead of a unicode symbol ($verticalEllipsis-0.8, the -0.8 is to make it a bit smaller).
That's a good block.
That's also a good block.
That's also good
This is also a good block.
By the way, I am not on the TuneScope team, I just have a love for music and programming.
Thanks for your review!
I’m aware of that - I asked you to review because I had read in your profile, at Current Projects: “Making the TuneScope library better”.
Text is probably better than not-widely-recognized symbols, but for a prototype I just like to use symbols. 
I now adopted the Snap! version of verticalEllipsis, and enlarged the note symbol.
The restriction was already in the original TuneScope blocks (and possibly in the MIDI standard itself). E.g. MIDI# 132 is converted to C1, MIDI# 11 becomes B-. Conversely, B-1 and C10 are not accepted by the original TuneScope CONVERT TO MIDI block, causing unspecific error messages like:
.
So all I did was add better error messaging.
I hope @glenbull and his team will find some of the stuff (or at least the underlying ideas) helpful inspiration for improving TuneScope - which IMO is a very nice library deserving to be widely used in educational environments.
BTW how can I import a MIDI file into Snap! for processing by TuneScope?
Here's another question: what exactly does the 'time signature' in the PLAY TRACKS do?
I've noticed that a mismatch between measure length and time signature causes distortion during playback, but I haven't been able to find a system for that.
And is it possible to sustain a note for longer than a full measure?