Youtube tutorials from Josh the Gamer

The Quorum team recently had a chance to interview a student in Nebraska that uses Quorum in the classroom. As it happens, he goes by the moniker Josh the Gamer and has been building some great youtube tutorials on Quorum. He was kind enough to do an interview and let us post it on here. There are links to all of the tutorials at the end of this post. Thanks for all your hard work, Josh!

Can you tell us more about yourself?

I am a 17-year-old legally blind junior in high school at Lincoln Northeast high school in Lincoln, Nebraska. I have been learning programming since 2012, starting with the Java programming language, then going on to languages such as HTML, CSS, JavaScript and C# using the .NET framework. I am very passionate about computer science education, and I want to help educate as many people as I possibly can about the importance that computer science holds in the modern world. Starting in 2016, I became a Minecraft mod developer, meaning that I can develop mods for the game for others to use in their own copy of the game. I am actually a very meticulous coder. I do super, sometimes unnecessarily large and lengthy tests on my code to find and squash bugs in my code, which is very important. As of now, I am fluent in five programming languages. These languages specifically are Java, C#, HTML, CSS and Quorum. Programming and computer science are probably some of my biggest passions right now and will be for many years to come.

What got you interested in writing a video tutorial series on Quorum?

I became interested in making tutorials for the Quorum Programming Language because of how passionate I am about spreading knowledge of programming and computer science as a whole. At the time of starting my Quorum programming tutorial series, I had already started on a tutorial series for the Java programming language, which is meant for beginners to that specific language. However, I wanted to make a series for a programming language that is syntactically easy to understand to the average person that may be an absolute beginner with programming or computer science as a whole. That is when I thought of the Quorum language. Why was it the first language to come to mind? Why not something like SQL or HTML? Simply because Quorum is not only designed for those with visual impairments in mind, therefore including a whole minority group into the world of computer programming and computer science, but also because it is evidence oriented, meaning that there has been a lot of research done to decide on easy to understand syntax, such as repeat, repeat while and repeat until instead of for or while to define loops.


What kind of programming are you interested in generally?

Generally, I am interested in languages that are object oriented. I do want to understand other types of programming languages that are not object oriented, however.

Are you planning on doing any more tutorials in the future?

Yes, I am planning on doing some more tutorials in the future. Very soon I’m going to start recording tutorials for Quorum’s game engine. This is also going to include the new physics system for Quorum 5.0. The series for Quorum’s game engine will consist of both 2D and 3D aspects of the engine. It will be in total around 50 tutorial videos, as there are many aspects of the Engine to cover from what a frame is to keyboard input to collision detection, and I want to split them into smaller bits for easier consumption of the information.

The Quorum team wants to thank Josh for all of his hard work in putting these together. We appreciate the effort and hope to see more soon! Here’s a list of Josh’s tutorials:





User Input:



Object-Oriented Programming:

Lexical Scoping:


Random Class:

DateTime class:



Access Modifiers:




Sound Synthesis in Quorum 5

The next round of beta releases was pushed as part of our continued testing of Quorum 5, which has the label 5.0.5. There are several major improvements to this release, including:

  1. The 2D physics system now has rope and weld joints, for which internally we have some neat demos (e.g., slinky going downstairs).
  2. We have completed the API for skyboxes, which is being used for some new tutorials and a new hour of code related to astronomy.
  3. The first version of the AudioSamples API, which is being used for low level sound access in Quorum 5, is now included.

I won’t go into detail about all of these, but we haven’t talked about the new Sound APIs much publicly, so now seems like a good time. Here’s an example of a little noise generator that can be created in Quorum:

use Libraries.Sound.Audio
use Libraries.Sound.AudioSamples
use Libraries.Compute.Math
use Libraries.Compute.Random

class Main
    action Main
        AudioSamples samples
        output samples:GetSize()
        output samples:GetSizeInSeconds()
        Math math
        Random random
        integer counter = 0
        repeat while counter < samples:GetSize()
            samples:Set(counter, random:RandomNumber() * 2 - 1)
            samples:Set(counter, random:RandomNumber() * 2 - 1, 1)
            counter = counter + 1

        Audio audio


How this works is that we have an AudioSamples object that we give information to about its size (3 seconds) and channels (e.g., stereo, mono, 5.1). From there, we can fill this object, which is a buffer in memory, with information. In this case, we are filling it with random values, so this kind of algorithm will let us generate noise, but we could do effectively any kind of digital signal processing here for computer music systems. For example, we could do FM synthesis, AM synthesis, sine, square, or any other kind of generators.

Put another way, this new system will allow us to do the kinds of operations we might have been able to do in programming languages like SuperCollider, CSound, Max MSP, or others, but all in Quorum and without needing any plugins. To say the least, it could lead to really fun lessons and has a variety of sound synthesis applications.

Quorum 5 Coming Together

With every release, there always seems to be a time on our team where things are starting to “gel.” Today, on the Quorum team, I feel like we are hitting that for Quorum 5.  One thing I am particularly excited about, the team is working hard on a new accessible hour of code based on computational astronomy. This one is going to be slightly more advanced then our last, but is our first attempt to show how parts of the field of astronomy can be made accessible. It is still designed for young users, but features two features of Quorum 5 that the team is pretty pumped about. These are 1) a converter to JavaScript for Quorum, and the as yet unannounced 2) Skyboxes.

First, Quorum 5 internally can convert itself to JavaScript and, just like Quorum on the Java Virtual Machine, we can write plugins for it do whatever kind of stuff we want on the web. This includes writing web games, which have exactly the same source code as if we want to write them on desktop. While we are using this for a new hour of code, it also means we will be able to make a vast number of our online lessons runnable in the browser. This includes graphics and audio (but not MIDI, in Quorum 5).

Second, in computer science, we sometimes talk about the concept of a skybox. Math of skyboxes aside, it is often has use cases like making the user feel like they are in a bigger world, with mountains or other images behind 3D rendered objects. Here is a link, for the curious, on how it actually works (and pictures, for those that can see them):!Advanced-OpenGL/Cubemaps

Fortunately for us, we have simplified the details considerably. As such, we load these skyboxes like this:

//Make the skybox objects
Skybox skybox

//Load each of the images from a folder called Skybox

Because skyboxes are inherently a 3D concept, we then apply them to our 3D layer like this:

//Get the layer and put our skybox in
Layer3D layer = GetCurrentLayer3D()

That’s a lot of fancy graphics code for little effort and it’s a core component of what will be our accessible computational astronomy hour of code. All in all, it is an exciting time for our team. We have made huge progress this year and are excited to start talking more about the considerable enhancements to other systems in this release.

Pictures using Quorum

Want you or your school to be highlighted by the Quorum team in the next refresh of the website? If you’ve taken some photographs of yourself, or your students using Quorum or doing programming, and have permission to post the photos, we would love to hear about it. We are in the middle of a refresh of the website and would love to highlight the great work being done by our partners. If that’s you, let us know!

Breaking Stuff with the Keyboard

We are now neck deep in implementing changes for the Quorum 5.0 release. Most of the time when we make changes, we go out of our way to not break backward compatibility. When we do, depending on what kind of system it is we are adjusting, our team internally requires evidence. For example, changes to core syntax or semantics require a randomized controlled trial or other rigorous techniques. If the changes are to something less important, our standards change accordingly. Further, if we identify technical problems, sometimes just make the changes. In other words, if we find a bug, we aren’t going to run an experiment. We’re just going to fix the bug.

For Quorum 5, one change we are making that will break backward compatibility with Quorum 4 is in keyboard constants. Basically, we did a review pass of using keyboard events in the game engine. As we are porting the engine to the web, we noticed every browser and platform was even more varied than we realized (e.g., Safari is very different than Chrome). Further, our keyboard constants were pretty messy and, so far as we could tell, had problems that fell in the technical issue camp. As such, here’s a list of all of the changes to the constants in KeyboardEvent and related keyboard input classes:


The following constants were removed because they could not be detected by our backend anyway. They represented extra hooks we thought we had, but really didn’t, from way back in the Quorum 3 release.



The following constants were renamed to make them more consistent with other, similar keys, or just to more closely follow standard Quorum naming conventions:

NUM changed to NUM_LOCK


These constants were added to allow for control over a wider number of standard keys on a keyboard.


Web Compatibility

All key constants in the new version are usable on the web, with the exception of these constants:

As always with changes that can potentially break an app, if anyone has concerns or comments, they are welcome to email the mailing list. In this case, we imagine this particular change won’t impact many people, but we want to put the information out there anyway.

Quorum Web Update

We have now made significant progress in the lab on the Quorum 5.0 web updates. The following is now working internally for the web version of Quorum:

  1. 2D Graphics: We have all the normal pieces functioning now, except for image sheets
  2. 3D Graphics: Pretty much everything is finished here as well, except for loading custom 3D models.
  3. Sound: Sound works similarly to Quorum in offline mode, except that in-browser sound systems do have some limitations (e.g., HRTF support only instead of 5.1, no doppler). There are also some limitations to specific browsers.
  4. Embedding: On the Quorum site, it will not be long until these little development environments start popping up all over the site. They can now be embedded in our lessons.

We still have a few things left to do. Notably, our testing has been pretty limited so far, we have only embedded into one lesson, and we have not finished our accessibility and user input designs. We are close though and this thing is pretty fun to play with.

This image shows three components. First, there is a normal Quorum development environment, coupled with its error or console window. Finally, there is a canvas window shown, which executes any audio or visual content.

There is one last thing that is worth noting. Right now, if we want to run our games on the web, there is some extra code we have to tell Quorum about, which looks like this:

WebConfiguration config = GetWebConfiguration()
//which HTML canvas do we want to draw on?
//We need to know because there can be multiple games
//on a page
config:canvasID = "instantiateObjectIdeGameOutput"

The reason is because Quorum needs to know which part of a web page to alter for games. It is possible there is a way around this with some sensible defaults, but right now it is the one difference between online and offline modes. Either way, considering there is zero JavaScript required, a pure Quorum solution, it is a small sacrifice.