deepjazz: two layers, 36 hours, and a preprocessing step you have to edit yourself

The first line of the readme says the project is over

The readme opens with a note rather than a description. It says deepjazz is no longer being worked on, that it may be refactored at some point in the future, and it says goodbye and thanks the reader, with a crying emoji at the end. That framing is not contradicted by the forge: the repository is not archived, and the last commit is dated 2026-03-19, so somebody has touched it within the last half year. What is absent is any sign of a release. The repository has no tagged releases at all, which for a project people are invited to run means there is no version to pin, no changelog to read and nothing to compare a checkout against. The promise of a future refactor is the only forward-looking sentence in the file, and nothing on the page says what a refactor would change.

preprocess.py must be edited before it reads your file

This is the constraint that decides whether the project works for you. A note states that preprocess.py must be modified to work with other MIDI files, because the relevant melody part needs to be selected, and that the ability to handle this natively is a planned feature. So out of the box the pipeline is wired to one input: the MIDI file in the repository, chosen by hand at some point in the preprocessing script. Anyone bringing their own file has to open the script and change it, and anyone hoping for a flag has to wait for a feature that the closing note says will not be coming. The generator itself takes one positional argument, the number of epochs, with no default and no validation described. Everything else about the run is a single command.

THEANO_FLAGS=mode=FAST_RUN,device=gpu,floatX=float32 python generator.py [# of epochs]

The dependency you install is a branch, not a release

Three dependencies are named and one of them is unusual. Keras and a music theory library are ordinary installs. The deep learning backend is not: it is specified as the bleeding-edge version on the project's GitHub rather than as a published release, which means you are building against whatever the tip of that repository is on the day you clone it. That is the instruction as written, and it is the instruction that ages worst, since a library with no tagged releases can change under an existing install. The page is careful about the other half of the stack: running the pair on a GPU is described as formally supported only for cards from one vendor, through the CUDA backend. The environment variables in the run command set the execution mode, the device and the floating point type together, which is the documented way to ask that backend for GPU execution.

Five Python files at the top level

The whole project is small enough to read in one sitting, and the layout tells you the pipeline. At the root there are five Python files and one directory. The generator is the entry point the instructions name. There is a file for the recurrent model, one for the musical grammar the model learns, one for preprocessing, and one more file whose purpose the readme never explains, which is named for quality assurance and appears in no command. The MIDI directory holds the input material. A licence file and a notice file sit alongside them, which is the correct pairing for an Apache-licensed project that carries third-party attribution. There is no package manifest, no requirements file, no configuration file and no test directory, so there is nothing to install and nothing to pin.

The code is Apache, the recordings are not

The licensing section splits the project in two and is unusually clear about it. Code is under the Apache License 2.0. Images and other media are copyrighted by the author. So the music you hear on the linked sound page is not covered by the licence of the code that produced it, and anyone reusing either needs to read both statements. Attribution is handled rather than hand-waved: the project says it develops a lot of preprocessing code with permission from another project, names that author and links to it, and adds that public examples from the framework's own documentation were referenced. That is what the notice file at the root is for, and its presence alongside the split licence statement is the clearest part of the legal picture here.

Two layers, thirty-six hours, one hackathon

The technical claim is small and specific, which is to its credit. It builds a two-layer LSTM and trains it on a given MIDI file, using the recurrent network to generate music rather than to classify anything. The provenance is stated just as plainly: the author built it in thirty-six hours at a hackathon. That framing explains the shape of everything else, from the one bundled input file to the absence of releases, and it is worth holding in mind when reading the marketing around it. The page positions the work by pointing at the two systems it says the technique powers, a game-playing system and a question answering system, and then argues that generating music is the harder demonstration because music is treated as deeply human. The output is published on a sound hosting page rather than in the repository.

One author, a plain http site, and no version anywhere

The project page is served over plain http rather than https, and the author's contact details are given in an obfuscated form, with the at sign written out in parentheses. The affiliation is a university department, which tells you the context this was built in. What is missing is any version identifier. There is no release, no tag, no version constant documented and no way to tell whether the copy you cloned this morning is the copy from a hackathon two years ago or something edited since. The readme's own links point outward for everything procedural: the dependencies, the recurrent network background, the installation instructions for the backend, and the music itself. Nothing in the repository tells you which commit is the good one.

Editorial conclusion

deepjazz is worth reading as a compact example of a generative recurrent network applied to music, and not worth installing as a dependency. Take it if you want to see the whole pipeline in five files, because the preprocessing, the model, the grammar and the generator are all at the top level with nothing hidden. Expect to edit the preprocessing script before it will read your own MIDI, since the melody track is selected by hand and native support is described as a planned feature that never arrived. Install the dependency from its GitHub branch rather than expecting a release, and treat the output as a starting point rather than a tune. And note that only the code is Apache-licensed; the audio and images are not.

Frequently asked questions

Official sources

1. Issues
2. jisungk/deepjazz on GitHub
3. License: Apache-2.0
4. Project website
5. README