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:
.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?
The time signature is used to make sure the tracks stay in sync by counting the measures.
The standard music notation way to do that is to use a tie across the bar between measures. To get a note of duration 3/2 of a measure, you'd tie a whole note in one measure to a half note in the following measure. Dunno if this works in TuneScope.
That’s what I’m curious about (I knew about the standard music notation, of course).
Pretty sure it should, or at least if you have a duration that extends beyond the measure. The actual code doesn't check if the duration is goes outside the measure, and it also doesn't wait for the note to end.
Did you analyze the TuneScope primitives code? (in JavaScript, I suppose) - if so, did you find out what happens to the next note(-s)?
Yeah, I did read (and modify) the TuneScope javascript code. I don't know what you mean by "next note(s", because it plays the notes in the order you put them in.
