Modular synth patch markup lang
spesk bd4f2084d7 Updated README, new modules, minor compiler changes | há 2 anos atrás | |
---|---|---|
module_lib | há 2 anos atrás | |
patches | há 2 anos atrás | |
.gitignore | há 2 anos atrás | |
README.md | há 2 anos atrás | |
README.org | há 2 anos atrás | |
pl_proto.pl | há 2 anos atrás |
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 as
semantics for brevityimport Module::MakeNoise::*
semantics for brevityimport Module::MakeNoise::Wogglebug::Rev1
[ ] 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.