Motto

We are the Home Entertainment System that Allows you to Visualise Your Music in Virtual Reality. We want to be able to bridge the gap between the tedious manual efforts that make us not want to have fun in life and bring it back!

It is worth noting that we have so far is a "proof of concept."

Inspiration

Having understood that Video DJing is becoming more popular, we wanted to bring this to the ever-scalable world of Virtual Reality.

Many of us hear good music we like on the radio, and want to have the same "mad" skills these DJs have in order to mix our own music as well. However, DJing has always been a rather tedious manually controlled industry, where there are controllers for the sound equalizing, Vinyl and CD turntables for the scratching sounds and playing the music, and sometimes extra digital equipment to help store more music, or to act as a virtual alternative for the above.

On the converse, the younger generation really likes playing games as well. Any new game developed on code for mobile OS will have a decent chance at becoming a popular game amongst any group of friends. This can be proven by the way that many Android emulators are now made to 'play' the game that is the mobile application, and how so many have tools directly to help game players record their progress, etc.

With Virtual Reality games taking the market by storm, it's poised to be the next Internet (still popular after 20 years), as it was similarly developed for use in Military (simulation) and is now being used to adapt a public taste. Plus, more and more people are thinking it's cool that we can create an experience of our own making.

To this end, it made sense to us that we could create a music player game of sorts, where by loading the desired music to be listened to, one could make artistic designs from fractals or even see a side view of a guy dancing to the speed and flavor of the music.

What it does

The "Club @ Home" is your all-in-one solution for having fun. Why? For DJs, this gives you extra practice with real-time audio-video and you can even get real-time feedback. All while giving a real-audience the time of their lives, and making smarter use of your practice time. [Disclaimer: Realistically speaking, until we can get enough partners, there will be many automated DJs as well, similar to the type that some radio stations use.]

For the listeners at home, this gives you the perfect opportunity to pick up your VR devices (for example, the ones that came with your new Samsung S7 phone) and rock out to beats. And like many other music services you already know, you can rate whether you like what you are hearing. This will give the DJ you are listening to a better idea of what songs they should mix. If the DJ has enabled it, you can even message them and talk about songs with them.

All things said, the big story of this product is the Visual Reality aspect.

For DJs, this is the future of DJing, where you might interact with your audience remotely. You can view a good show of both art and (with a license) also make your own virtual avatars to predict how your club would dance, interact (with each other), and react (to you). We aim for this to be a totally virtual, but also completely immersive solution.

For the listeners, this allows for not only a listening experience that some services already provide, but also adds on a visual image of the club as well, allowing you to imagine yourself as a part of the club. In the free versions, it's a show of art and pre-made video reactions to the music that you will view. However, if you enter a pay-per-view server show of a live DJ who chose to make this own video reactions, or if you make your own as an enthusiast with the licensed DJ version, then you can see a realistic club rave scene!

It's a DJ-"OS" emulator where it is running a "club music player @ home" application.

The "OS" is provided by underlying API code through Unity and mostly in C++ linking the movie types designed with the waveforms of the uploaded and matched music.

The application, of a music player similar to most home theatre systems is of a regular nature for such a program; however, through Unity and the Oculus SDK, we've made a version that can be ran in Virtual Reality platforms instead. This makes it similar to most first-person games, which allows for an immersive experience, where it is more convincing that you are truly a DJ of the arts and dance.

In today's Software as a Service environment, we find it important that there be automation to provide what we may want, and as DJs, we can say that it might make the practice sessions so many of us do at home much more enjoyable (with perfected graphics and the like).

How We built it

Code-wise, the development is supported by Unity's own language structure, with all of the animations and music recognition engines being powered by C++ code.

The backend API is provided by a Unity IDE and the Microsoft Visual Studio 2015.

The design is a hybrid of assets found on Unity and that of creation by C++ code. All movie interactions are also C++.

Finally, it is being relayed through to the Oculus VR console by the SDK provided hardwired projecting HDMI cable, but in the future, we hope it might be supported by wireless download to an embedded storage chip on the VR console itself, so one only needs the console (regardless of Internet) to play this game.

Challenges we ran into

We learned that Oculus has SDKs for both their DK2 (and DK1) developer's SDK kits, and their Rift products, separately. This took some time to adjust to. Consequently, we kept having failed installations.

This event also tested our sense of utility and alternative solutions. Our WiFi connection at the initial Hackathon was often weak, which for having to download and move files between computers, was poisonous. However, we kept moving around, tracing the source of problems, and we all learned more about how the assigning switch end of the cables work.

Finally, in making the music and movie, we had to test our understanding of standards and ear. By standards, for the music, this would mean the types of music that we can play, without obviously overloading the program (e.g. hard rock is a true difficulty, as the gain in the waveform creates an annoying white noise). For the movie, it was a matter of understanding the true nature of different file forms and containers, as we had to re-encode an "Mp4" file so it was truly in the H.264 - 5.2 encoding schema. Fortunately, there is good software like HandBrake to do

Accomplishments that We're proud of

In understanding that the music for the demo had to be acceptably not ripped music off the Internet, but at least have creativity and fair use to be used, we used the commercial modification platform for [computer-only] DJs, Virtual DJ Pro7. Not having done a lot of fancy mixing before, we were intrigued by the many possibilities proposed by changing the key or the beat, or even just making one song fit well with another. Many thanks to the DJ of the team, DJ Icewobs.

We also were able to successfully integrate all the files between both a Windows version of the Unity SDK and a Mac version, showing that our code is quite tolerant to use through a code-content management system for server commitment backups, such as GitHub.

Finally, we're happy to have had the great designing skills for the movies, and for the creation of the fractals within them. This was very helpful to the creation of the movies we used with the program.

What we learned

We learned that using the wrong software for a system can really destroy it. During the competition, a misconfigured install of a program led to the corruption of the OS. This was very problematic, but we managed to fix this.

Also, we learned about the difficulty of actually changing music in a way that it still makes sense. When people usually play music as a DJ, they just play a song. However, we learned that as a fact of commercial pitching, if using a well-known song, we must consider copyright status, and apply to the US Copyright Stature 106 of "Fair Use" by making "considerable modifications" where the new product is "measurably different" than the original.

FInally, we learned more about some of the newer changes in Unity 5 (vs. what we were more familiar with in previous versions) and made adjustments to our working knowledge by understanding and leveraging the nature of what is "documentation."

Economic Versatility of Seed

We want to calculate a risk of asking for 50000000 JPY (五千万円)in total from interested investors.

This is because we want to start as a privately invested company with chance of becoming an IPO if the idea becomes big.

We estimate two major costs:

An average of 850000 (八十五万円) JPY per year salary for 15 employees and An average of 250000 (二十五万円)JPY per month cost of running electricity in a small office building and for taking out aobut 15 (10-20) cloud servers. An average of about 12000000 (千二百万円) for 50 more employees yearly salary of 240000 JPY (二十四万円)

We estimate a business model of the following listings of revenue stream in the first year:

About 90000 yen each, of thirty "30-second advertisements", or an asking price of about 3000 yen per each second. About 5000 yen each for each of at least about 4000 private pay-per-view sessions (sessions attended) About 25000 yen for each Premium license (making a profit from this software is OK commercial licenses) for DJs and enthusiasts who want to make custom avatars. About 13000 yen for each for each Pro [fessional] license (able to make your own virtual server to stream your own music, but not your own avatars). You many not make a profit with this license.

On case-by-case basis, we can also support requests from educational, governmental, and not-for-profit organisations to provide them with a similar version to the Premium license that works for only one event (about a week) up to three such events per organisation per year (one, plus one more up to three for referring the software to someone else).

The licensing model will be a yearly subscription where the amount you pay will be slightly higher than the listed above prices if you opt to pay on a monthly basis. We have yet to set this amount as we wish help from industry to set such a price. If interested, we could discuss the licensing models we have in mind and discuss the best ways to make this work.

As a side note, ((850000*15) + (250000*12) + (50*20000*12)) - ((90000*30) + (5000*4000) + (500*25000) + (1000*13000)) is the calculation of Costs - revenue, which gives us a net profit of 20450000 yen (2045万円)per year.

This is not considering unknown, hidden, and licensing costs that we may have to incur, so further advice would be needed on this matter if it were to be made into an actual startup.

What's next for Club @ Home

Perhaps the next thing would be to finish up the backend, so that the code could be made committable into a GitHub repository.

Following this automation of the backend, further animation work on the frontend movies might be done, in order to open up more options.

A mobile controller using the Oculus Mobile SDK would certainly be the next step, as more and more people are now using mobile devices to game, including cases where the mobile is only used as the controller (and the image is sent wirelessly and over bluetooth to the headset in such cases).

Somewhere around here, we would have to start making web and media advertisements to try to advertise our product, and perhaps start offering trial periods in order to grow into the three Vs of bigger scales of data: variety of input data (songs), a large volume of users (from different regions), and a high velocity system where data can be efficiently transported (perhaps forcing us to consider re-writing inefficient portions of code) between say central servers of our product and a desktop or mobile user (either by Internet, or mobile data cell towers, respectively).

Finally, if the game got large enough, over many platforms, then we might need a scalable big data web services provider in order to both simultaneously collect data usage for pattern recognition and suggestions of the next song.

Considerations on security might begin at this point as well, including ways to discourage reverse engineering and to handle large amounts of users with more accuracy. We might also have to worry about making sure that if users decide to start personalising and storing their information, that we give them the option of making a username and password, and on our end, securely encrypting their password in a harder to crack form, such as SHA-1024 or even SHA-2048 key.

Concluding Thought

Realistically, not everyone will want to DJ, but we hope that anyone who's "felt the beat" before will consider raving along with our cool product!

Built With

Share this project:
×

Updates