This implements a first cut Wavenet model for the audio generation task on the VCTK dataset. This uses the Python + Tensorflow version here as a reference implementation.

At the moment only the training loop works and there are some limitations / missing features that need to be addressed:

• [ ] Add PaddingFIFOQueue to correctly produce batches from data files
• [ ] Add generation step to generate new audio samples
• [ ] Add preprocessing function to trim silent sections of audio
• [ ] Make model configurable with command line args

Additionally, I have some ideas for future improvements / enhancements that I can include as follow up PRs:

• Uselibrosa instead of the simplistic pydub library in Python for reading and processing audio. Initial attempts resulted in the following error:

Assertion failed: (PassInf && "Expected all immutable passes to be initialized"), function addImmutablePass, file /Users/buildbot/miniconda3/conda-bld/llvmdev_1556270736866/work/lib/IR/LegacyPassManager.cpp, line 849.
Abort trap: 6

• Possibly use Swift-native audio libraries like AVFoundation? Initial attempts at this caused linker issues:

dyld: Symbol not found $<symbol-name>
expected in <path-to-swift-toolchain>/AVFoundation.swift

• Add XLA support
• Add support for more tasks and datasets
• Add scalar input mode (non one-hot inputs)
• Add L2 regularization for weights
• Factor out some of the dataset and audio reading code into common utils

I'd love to get some early feedback on this!

Closing this out since it's outdated. I'll pull in updates from swift-apis etc. and reopen shortly!

@diwakar-vsingh - Right now, Colab uses Swift for TensorFlow toolchains with tensorflow/swift-apis as part of them. That means that you only get the swift-apis capabilities that correspond with those present at the time the toolchain was compiled (in this case, the 0.12 release). It's a difficult process to update the Colab images, so we only do that on stable releases.

If you instead develop locally, using our nightly toolchains, you'll get the latest APIs included in those. Or build swift-apis using CMake locally from a Swift.org toolchain.

@BradLarson I created the new colab notebook to test out the updated 'depthwiseConv2D()' function. However, I am not able to add a dilation argument inside it. When we import TensorFlow, don't we get the most up-to-date APIs?

This copies the existing Python interoperability document into our main list of guides, and inserts an entry for it in the table of contents. The interoperability document has been slightly edited to modernize the text, links, and some of the code examples to match the current state of the project.

This copies the existing Python interoperability document into our main list of guides, and inserts an entry for it in the table of contents. The interoperability document has been slightly edited to modernize the text, links, and some of the code examples to match the current state of the project.

It's been my pleasure to contribute. I'll open up another PR in few weeks with DeepLab implementation.

Extended the depthwiseConv2D struct to control dilation rate as well.

I'm merging this in for now, to allow for the documentation to be accessible and to unblock work on improvements that depend on this.

CheckpointReader and CheckpointWriter provide the building blocks for reading and writing model tensors to TensorFlow v2 checkpoint files, but to use them you have had to write model-specific code for extracting Tensors and their names, as well as placing parameters back into the model. This introduces a higher-level API that makes it easy to checkpoint and restore simpler models, and provides customization options for more complex models or for matching the naming schemes of external frameworks.

Writing a checkpoint becomes as easy as

extension LeNet: Checkpointable {}

let model = LeNet()

try model.writeCheckpoint(to: directory, name: "LeNet")

and reading

var newModel = LeNet()

try newModel.readCheckpoint(from: directory, name: "LeNet")

This is handled via the new Checkpointable protocol, which builds on KeyPathIterable. If you extend a model to be Checkpointable you will gain the writeCheckpoint(to:...) and readCheckpoint(from:...) methods for writing and reading checkpoints. By default, this will generate path names for each Tensor<Float> within your model using a naming scheme where each level in the model is named by its property name and separated by "/". For example: conv1/filter.

This can be overridden in a number of ways. The internal separator string can be changed by providing a different checkpointSeparator in the protocol conformance. Specific tensors within the model can be ignored for checkpointing by providing them in ignoredTensorPaths in the protocol conformance.

For the greatest flexibility, customized String -> String mapping between internal tensor path names and those in the on-disk checkpoint can be provided as a default for the model via tensorNameMap in the protocol conformance, or as a parameter when reading or writing a specific checkpoint. This allows for interoperability between a wide variety of frameworks and model naming conventions.

Documentation and tests have been provided for checkpointing overall, and this new functionality in particular. This is now ready for review.