|spesk bd4f2084d7 Updated README, new modules, minor compiler changes||10 months ago|
|module_lib||10 months ago|
|patches||10 months ago|
|.gitignore||10 months ago|
|README.md||10 months ago|
|README.org||10 months ago|
|pl_proto.pl||10 months ago|
This repo encapsulates an attempt to develop a markup language for describing modular synth patches.
In future, this scope may be expanded to make available a language for describing arbitrary audio and data routing across a wide array of devices.
This software is currently a prototype. Right now the "compiler" is a Perl script that translates a
.modmark file into a flowchart via Graphviz.
A rough road map looks something like:
-chars, possibly other chars
[ ] Implement modmark as a source-to-source compiler in Racket ( "Real" implementation )
import assemantics for brevity
import Module::MakeNoise::*semantics for brevity
[ ] Standardize input/knob labeling semantics:
- Input: Foo -- Position: [1,12] - Knob: Foo -- Position: [1,12] # Currently both of above "compile", and work as expected, in the case where a # module parameter has both a knob and an input. It may be better to only have one way?
[ ] Develop libraries for as many modules as possible
In the past I've found it difficult to discuss discrete details of modular patches on the internet. This arises, I believe, from the large amount of effort and time it takes to describe the intricacies of a modular patch in long form plain English. This prototype language is an attempt to address that problem.
By specifying a concise syntax that favors brevity over absolute human-readability, the hope is to get more modular synth users to document their patches and enable more knowledge sharing across the community.
I know of one other attempt to solve this problem: https://github.com/SpektroAudio/Patchbook
My problem with Patchbook is that it still requires a lot of "boilerplate", in that you have to specify
modules yourself. Modmark aims to offload this task by having the community describe modules in a Library format
.module files) that can then be imported. In this way, we can specify a module once and then not have
to do that work again the next time we'd like to use it in a patch.