TuneScope removes the ability to use vanilla sound blocks

I was just playing around with the TuneScope library, but then I noticed that when I used any of the sound blocks, they threw this error

Note.getAudioContext is not a function

What really baffles me, is that even the volume blocks throw the error. Why does TuneScope use their own volume, instead of just using the built in volume blocks. It even uses the tempo blocks.

I even tested it out without loading TuneScope, and it works.

This is unacceptable. A library should not remove the ability to use vanilla blocks.

Yes, that's right and I wholeheartedly agree. I've created the TuneScope extension from a project they've sent me which makes extensive use of JS-Functions and offered to help with turning it into an extension, and I'm glad that it already works - in principle -. The problem with developers is that they tend to put everything into the global namespace and basically fork Snap by overloading functions, which in turn breaks other things. Also, the architecture of TuneScope is very much "duck-tape-style", they've thrown together stuff they found online and sorta glued it together quickly just barely enough so it works for their purposes. Since their main developer has left their team I'm going to try to help them fix it. But it might take me longer than the imminent release of v8.

Being a former classical orchestra musician (violin) myself I also disagree with quite a few of their musical design choices. For example, their decision to regulate volume on a per-instrument basis is - I think - bonkers (and that puts it mildly). their strange ideas about tempo and measures are also - I think - rather ill-advised and - I'm afraid - more influenced by questionable opinions stemming from the former LOGO community than from real musicians or music didactics. But I'm not going to interfere with those.

What I love about the TuneScope extension is that it lets you create really beautiful, breathtakingly awesome generative music projects. And I'm going to look into how we can merge the best of TuneScope directly into Snap in the future.

Thank you for looking at this Jens, and we apologize for the error. Our developers are student programmers, and often their implementation strategies are not ideal. Unfortunately, as non-CS folk, Glen and I aren't the best at spotting potential errors like this. One of the main developers will be back in August, we're bringing more onboard to replace those who graduated, and we're adding more oversight from CS faculty.

Our intention was not to remove the ability to use vanilla blocks. Setting the global volume should absolute be done from the vanilla block. We asked for the ability to set volume by instrument so that it would be possible to create a mixing board and allow for dynamics like crescendos. We'll see if we can't think of a better way to do that.

As for the tempo and measures, we'd be more than happy to discuss more optimal implementations. We structured the notation and procedures based on feedback from both coders and musicians, but there's always room for improvement. We have absolutely no ego in this and simply want to see it succeed.

well, I've actually started to improve the current library myself, making it much more in line with the vanilla music blocks in snap (e.g. using numbers for notes and note durations), all while keeping it's current features (while also improving them). I am also a trumpet player, so I do know a lot about music.

Uh oh, Jens has already made some changes, fixing the volume thing I think for example. As for numbers for notes and note durations, you need to remember that there's a curriculum that goes along with TuneScope, so you can't just change something you consider a misfeature, such as named notes, the way you can change what's clearly a bug, like the volume situation.

I was just discussing all this with Jens. He's adamantly on your side with respect to durations -- that they should be how many beats rather than the duration name. We didn't talk about note names vs. -- actually, what are you suggesting? Frequencies? MIDI note numbers?

I took a music theory course back in 1969, so I'm not a music expert and I guess I don't really have the right to an opinion, but I have an opinion anyway, namely that the needs of musicians, who might use TuneScope the way other people use, I dunno, GarageBand, or maybe Max, are different from the needs of absolute beginners. For them, what they need depends on whether or not you want them to be able to read sheet music. If so, then they need to know about quarter notes and all that. So I think that before you start writing code (or Jens either, for fixing misfeatures rather than fixing bugs) you have to have a conversation with Glen about what his needs are. He's the one who gets to decide how TuneScope behaves.

Hi, I am a graduate student in the Make to Learn Lab at the University of Virginia and a member of the TuneScope team. I have an undergraduate degree in music from Oberlin Conservatory. I have extensive experience with music pedagogy teaching students attending music camps. I was initially in the music technology doctoral program at the University of Virginia before switching to a degree in education. Luke Dahl, a professor of music technology at the University of Virginia has served as an advisor for both the music theory and pedagogical aspects of TuneScope development. We have offered a course in art and music based on TuneScope during the fall and spring semesters of the past three years, for a total of six offerings at the undergraduate level. Brian Harvey has provided generous support and reviewed much of this content. The average response on the summative evaluation across all six offering has been 4.88 on a scale of 5.0 (the average response across all university courses is 3.9 on a scale of 5.0).

We have also offered the course to academically disadvantaged students at the high school level, as an elective at the community college level, and in two successive summer academies with middle school girls with equally good results. For that reason, we believe the format of the music blocks and the associated course content is achieving our goal of engaging students who are novices at both music and coding.

This morning we met with Rich Nguyen, a professor of computer science who has been overseeing the implementation of TuneScope. Rich is currently in Vietnam but will return to the United States on August 10th. Rich apologized for the global variables that conflict with native Snap! blocks and is very appreciative that Jens has corrected some of these scoping issues. Rich noted that the coding of TuneScope has been entirely done by undergraduate CS majors who have limited development experience in some cases. The lead undergraduate CS student, Eric Stein, has graduated and is now working at Google. However, another undergraduate CS student, Harsh Padhye, will be returning for his senior year of college on August 20. At that point, we will have more capacity to contribute to corrections and errors that may remain.

One section of the art and music course is based on the concept of a digital audio workstation (DAW), which is a common tool used in many music composition classes. For that reason, in addition to a master volume control, we need the capability to adjust the volume level of each instrument individually, just as you would in most DAWs.

We attempted initially to teach music novices to read sheet music, but we found that in the time available (six weeks for the music section of the art and music course) there simply wasn't time to teach novices to read sheet music and learn all the other concepts. The use of music note durations (quarter, half, etc.) is in widespread use in music courses in the United States, and we have adopted that notation in all of our materials. (We understand that in other countries other notation systems are used.) Use of the notation system we employ does not preclude use of alternate notations (such as beats) in addition to, rather than in place of, the notation that we currently employ.

We are very excited about moving some of this work into mainstream Snap! to make it available to a wider audience. Luke Dahl and other professors of music technology and music theory at the University of Virginia are more than open to exploration of how to best to represent measures. We certainly don't feel that the system we have developed over the past three years is the perfect solution. It is just the best compromise between the technological and pedagogical constraints that we have been able to develop to date, based on field tests with students. We are looking forward to the continued conversation. :)

actually, what are you suggesting? Frequencies? MIDI note numbers?

I'm suggesting midi note numbers, as that's what's used in the vanilla snap music blocks. If I wanted frequencies, I can just convert a frequency to a midi note number, using a block in the music comp library. Just to be clear, I've actually modified the tunescope library to add this. I did also allow you to use duration names, as well as duration numbers, and I think my implementation is really good. I made it support dotted dotted notes.

I've got more modifications, but I'm waiting to finish it all before sending it.

Thanks, everybody, for your comments. @watts-j and @rachelkgibson I'm sorry for perhaps coming across too harsh about TuneScope. That's totally not the case, though, I love everything you do, and we'll get the technological side all to work and integrate perfectly into Snap! I'm absolutely sure.

Turns out the one technical quirk that interfered with Snap's own musical system was caused by a 3rd party library you're using (webmidi) which overloads our own Note constructor. @bromagosa and I spent the better part of yesterday researching into how we can use that library (which is supposed to be an iife module and - in theory - should not collide with Snap's namespace at all, but somehow does) in a safe way. We've skimmed their repo and found another version - an esm module - which we were able to import correctly into Snap. the part where I got stuck is that it only worked for me if I imported it statically instead of dynamically. However, for modules I can't always import their dependencies into vanilla snap, because most of the time most of the users will not need them at all. So, while we're researching into this (did I mention lately that web programming is utterly terribly broken?) I've made a tiny change to the 3rd party library (I know, that's not sustainable, but we're shadowing it on our server anyway, so I think we can get away with this for a while) which simply renames their Note class to _Note, and that seems to work just fine for now.

WRT to some of the strange design decisions I noticed in TuneScope I was discussing them with @brianharvey and was amused to learn that Brian is to blame for the telling you to put English words of Note durations as fractions of a measure into the "duration" inputs ("Quarter", "Whole" etc.). I guess that's a matter of taste, but the downsides of that design seem overwhelmingly negative to me:

1) Using words instead of numerical beats breaks the ability to easily map over a melody to transform its tempo, say, for a Fugue. Especially for non-musicians the traditional names for note durations hardly make any sense at all. Why is a 4/4 note even "whole" in the context of a 3/2 measure? Clearly, if you're not teaching traditional musical notation beats is a much more approachable concept.

2) Using English text as value makes TuneScope hard / impossible to use in other parts of the world. The same applies to using letters for Note pitch values, because some countries use "H" instead of "B", and many countries don't use letter at all (but Solmization). But the point is that for non-musicians diatonic sequences with strange letterings like "A-H-C-D" or "Do Re Mi Fa" are anything but a low floor, whereas ascending integer sequences representing chromatic scales must be much more approachable, especially in the context of computing.

3) Mapping volume to instrument types instead of individual voices must be plain wrong. Imagine a quartet of same instruments / voices. Surely there has to be a way to emphasize themes in individual voices / players.

But, again, this are just my layman's remark. I'm not an active violinist anymore and I really don't now anything about pedagogy at all. The great thing about extensions is that they let everyone have their own way. So, yay for TuneScope!

Thanks @jmoenig. We're sorry that the webmidi library presented problems. We added it recently because students wanted to explore use of MIDI keyboards. Here's a link to a short video in which Rachel introduced the capability:

MIDI Keyboard Video

It's nice to have, and students like it, but it is buggy in its current form and not essential to the course.

Regarding mapping and transpositions, similar issues arise between note names (e.g., C, D, E...) and MIDI numbers as well as between the names of note durations and their numerical values. We created MIDI to Note and Note to MIDI blocks to go back and forth when dealing with note names. The ability to switch between names of durations and numerical values might also provide the best of both worlds. With the exception of Rich Nguyen, we're not computer scientists, so there may be many considerations about Snap! as a whole that you're in a better position to judge.

We are confident about music pedagogy that we've observed directly in our classes, although we are still learning. Our instruction depends on approaching the material from the perspective of a musician. Roughly half the students in our classes have had prior musical training. These students typically use duration names and expect us to use them as well. Therefore, employing Snap! capabilities to allow people to use their preferred approach would be ideal.

We have a draft description of all TuneScope blocks, which Brian has been reviewing. Since you and Brian have different perspectives, it may be helpful to share this document with you as well. Here's a link to the file in DropBox:

TuneScope Block Descriptions

Regarding volume, your comments make perfect sense. We had not considered differentiating between two tracks using the same instrument, primarily because most students have selected different instruments for their tracks.

There are a number of other unresolved issues at this time. For example, we have not identified a good way to notate ties across bars. There is a tension between completeness of a notation system and its simplicity. Since we are primarily working with novices, we have erred on the side of simplicity. However, with a fresh set of eyes, it may be that elegant ways to address gaps will be identified.

In comparison with other available systems, one of TuneScope’s biggest needs is a library of songs in the TuneScope format. The availability of a song library would be helpful and inspirational. However, we did not want to invest time in building a song library until the notation system was finalized and integrated into mainstream Snap!.

Thanks again for make our dream of incorporating TuneScope into Snap! a reality. We are very appreciative of the effort you are devoting to this.

Well, I submitted a pull request to fix all the things I (and jens) didn't like about the tunescope library. Of course, I still kept everything that was already there (well, at least the functionality, the code may be different). Here it is https://github.com/jmoenig/Snap/pull/3074

@ego-lay-atman-bay

TL/DR: Very helpful. I'm going to go back through all of these, make the appropriate changes, re-order the blocks, and then export the XML file. As soon as I have it done, I'll post it here.

There are some things here that would be good to implement as well as some things we considered and then decided against for reasons I'll explain below.

Play Note Love the end result. Introduction of a default octave will help prevent frustration, and being able to enter notes/MIDI numbers and beat names/numerical values is a huge help.

A couple of thoughts on the implementation. Generally speaking, we like to avoid placing a default value in input fields, particularly if the data can be input multiple ways. We'd also like to keep our original menu structure. Field testing showed that novices found the listing of enharmonic notes next to each other to be confusing; they much preferred to select the desired note from a sub-menu. Also, I'm currently working on a way to replicate your results in Snap. Wherever possible, we'd like to keep the code as transparent as possible and minimize the use of javascript.

Play Chord Play Chord does not need to be changed. It should only accept a list as an input, as this is where the curriculum really starts diving into the concept of lists. I'll correct the input type to reflect that.

Position of Note Please leave as is. We are working only with the major and minor scales. Introducing too many scale types up front can be overwhelming for students. Later modules within the curriculum teach them how to derive additional scales.

Interval Between Notes Please leave as is. I'm not sure using MIDI numbers here makes sense, since we're dealing with Western scales. While it is possible to determine the interval between MIDI 60 and MIDI 64 in the C major scale, I've never heard or seen the scale referenced as the MIDI 60 major scale.

Diminished Scale This block should exist as a hidden block. Basic scales are difficult enough for novices to grasp without the addition of diminished and augmented scales. I do however like your implementation better than ours and will update the block accordingly.

Diminished Chord Not needed. Muddies the waters. Students can build their own diminished chord blocks as an extension activity if they want one.

List of Major Scales This block should be hidden.

Major/Minor Chord Please do not change. Note and Octave should be separate inputs, as this is easier for novices to grasp, particularly at lower grade levels. I'll attempt to think of other ways MIDI numbers could be used in addition to Scientific Pitch Notation.

Major/Minor Chord Position Same as above. Also, please do not change the menu for chord positions. Roman numeral numbering not only matches music theory standards but also helps students differentiate between other numbering systems used in TuneScope.

Add Note to Chord Looks good.

Beats in Measure Much more elegant.

Drum Loop Going to double check, but I believe we need to use the "Item i" block rather than the "Each" block. This could be why your tracks stopped working.

Track Much more elegant.

Note from Hz Two things here. First, on blocks, we like to use mixed case and plain language. If we were to use this block, we would want it to be "Note from Frequency in Hz". That being said, we've tried introducing frequencies in the past with little success. This stems largely from the time constraints if trying to pack so much material into an already overcrowded curriculum. I see nothing wrong with including the blocks for more advanced students, but they likely wouldn't be included in the core instruction.

Hz from Note Same as above.

Note Duration Can't hurt to add.

Major Scale See previous comments regarding scales.

Beats in Time Signature This is tricky. Technically, time signature denotes not only how many beats are in a measure but also what duration of note gets the beat. For example, 4/4 has four beats and the quarter note gets the beat. However, in 6/8 time, there are six beats per measure and the eighth note gets the beat. Thus, the math isn't quite as straight forward as it first appears. For simplicity's sake, we've ignored all of that and we constantly consider the quarter note to be one beat. This isn't the correct way to do it, but we couldn't think of a better way to simplify the concept. I'm see if I can't come up with something better.

Note We had a block like this and then removed it. And then added it back. And then removed it. Overall, I don't think it particularly adds anything, but it also doesn't hurt. One thing we would want to do is call it Pitch Notation. A note consists of a pitch and a duration, as illustrated in one of our other blocks. This block needs to differentiate itself from that one.

I'm going to go back through all of these, make the appropriate changes, re-order the blocks, and then export the XML file. As soon as I have it done, I'll post it here for feedback.

I'll post it here for feedback.

I'd prefer it if you posted it on the pull request, to keep things in order.

I'm going to post my full reply there, to try and move this conversation over.

jmoenig / Snap

TuneScope removes the ability to use vanilla sound blocks #3072