MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

Patchbook – A Markup Language for Modular Synth Patches
MUFF WIGGLER Forum Index -> Modular Synth General Discussion Goto page 1, 2  Next [all]
Author Patchbook – A Markup Language for Modular Synth Patches
icaroferre
Hey wigglers, here's something I've been working on that might be interesting to some of you: it's an open-source markup language + parser for modular synth patches called Patchbook.



GitHub Repo: http://github.com/spektroaudio/patchbook

Blog post: http://spektroaudio.com/blog/2017/8/22/introducing-patchbook-a-markup- language-for-modular-synth-patches

Regular synth users could adopt this as a standard for writing down patches in a very simple way while other developers could use this standard (and it's JSON based data structure) to do all kinds of interesting things with patches written in this format.

While practical applications for regular users depend on other developers working with this standard as well, the official parser is already capable of generating flow charts and doing some other clever stuff with the patch data.

There's a lot to this project so if you're interested I'd highly recommend checking out the latest post on the Spektro Audio blog as well as the github project page.

Hope this is useful for some of you and, as always, I'm always open to ideas, suggestions, etc!
arthur
nice !
PISS.EXE
I might try messing with this as i'm currently mad at both excel and visio for trying to plan my synths' wiring structures as i redo the studio. shamefully i have reverted to graph paper and a pen and it sucks, this might save me



arthur wrote:
nice !


It took him 4 years to write that post hihi
goesbykyle
I'm excited to try this out, and I'll definitely be keeping up with the project. iterations/versions of patches with notes on changes between iterations could be really useful, especially for complex patches where a lot can change with tiny adjustments.

now to keep my inevitable laziness at bay...
arthur
arthur wrote:
nice !


It took him 4 years to write that post hihi[/quote]

first post tho smile)))
noisejockey
I must say, bravo, Icaro. I think this is a smart and extensible approach. What I super dig about it is the simplicity; a very low barrier to understanding/entry will encourage folks to use it. I love the future implications even more: I'm already imagining a parser that'd create a Pure Data patch out of my hardware patch...

Now I know what will be in the liner notes for my next album. lol

Excited to follow, and will try this out the next time I need to document a patch!

-Nathan
trinithis
Looks usable, but I don't understand the CAPS restriction for voices. Isn't (->) sufficient to denote audio?
oberdada
This is pretty similar to the way I use to document my patches, just neater.
One nice thing about it is that each line starting with - represents a patch cord. This makes it very easy to set up a patch.

You seem to indicate cv signals by >> or p> or g>, and audio by ->. This is elegant and intuitive, but how do you handle cases where you feed cv signals into typical audio inputs or vice versa?
PeterDeVault
I've thought about something like this for a while (actually it started before I was into modular and just wanted to document how all my studio equipment was set up for reproducibility). I'm eager to dig in to this. Thanks!
stylesforfree
This is interesting, I always probe and scour the far corners of the internet looking for modular patches only to no avail. So thank you.
SonicVoltage
I like it! Great work.

Use any .txt editor?

Or do u have some thing like syntax errors checks, syntax highlighting working in a specific IDE?

Intellisense? Code completion....
funky catsmell
now we just need some sort of computer controlled switch matrix that can ingest these descriptions and output patches. servo knob turners?

jokes aside this is very useful; i've been using lucidchart to plan and document patches, and having a simple human-readable markup language sounds a lot nicer than dragging and dropping boxes.
icaroferre
Hey guys, sorry about the delay.
Took me a while to get back here because I've been getting quite a lot of feedback in regards to this project (not all positive but oh well hihi).


trinithis wrote:
Looks usable, but I don't understand the CAPS restriction for voices. Isn't (->) sufficient to denote audio?


Voices can contain more than just audio connections. They're all in caps because it helps visually separate sections of the patch (I know that's a personal thing but I quite like it).

oberdada wrote:
You seem to indicate cv signals by >> or p> or g>, and audio by ->. This is elegant and intuitive, but how do you handle cases where you feed cv signals into typical audio inputs or vice versa?

The connection type should always be based on the signal being sent, so even if you're sending a CV to an Audio input, you should write it as a CV connection.

SonicVoltage wrote:
I like it! Great work.

Use any .txt editor?

Or do u have some thing like syntax errors checks, syntax highlighting working in a specific IDE?

Intellisense? Code completion....


I haven't had the time to work on that but it'd definitely be super neat to have this in SublimeText or something.
trinithis
Quote:

The connection type should always be based on the signal being sent, so even if you're sending a CV to an Audio input, you should write it as a CV connection.


I would instead suggest the following rule:
If a signal ultimately makes it to your speakers, it must be written as (->). Other signals must not use this symbol (even if it's an audio rate CV signal). To handle the case where a signal is split to feed both audio and cv inputs, the following signals must be used on the source "before the split"
(->>) (-p>) (-g>) (-g>>) (-p>) (-p>>) (-gp>) (-gp>>) [and other compounds as necessary]

Example:
Osc square out -g>> Mult
Mult out -> Filter audio in
Mult out >> Filter fm in
Mult out g> Envelope gate in
Filter audio out -> Vca audio in
Envelope out >> Vca cv in
Vca audo out -> Speakers
trinithis
deleted
Flareless
This is VERY COOL!

I've only spent a few minutes marking up a basic patch but so far it works great.

I'm going to test it out on a more advanced patch to see how it scales up.

Thanks so much for producing this!! thumbs up
mt3
This is great stuff.
eb0687
Thanks for this, great work! It's peanut butter jelly time!
diophantine
Interesting! I'll need to take a closer look later, but after looking at the blog post & the above discussion I have a few comments.

I'd really recommend ditching the variant symbols for ->, and just stick with ->. Neither your synth nor patch cables care if a signal is CV or audio or whatever, and the markup language shouldn't care, either. The language is just describing a directed (undirected if I'm being pedantic), unweighted graph, plus knob/switch settings.

However, adding optional metadata to indicate that a signal is CV/audio/gate/trigger/s-trigger/etc. could definitely be useful.

Some sort of symbol to indicate voice output would also be good; eg. VCO -> {OUTPUT}. Ditto for external inputs, and even MIDI.

To address a comment above, the markup shouldn't need to indicate mults. A parser should take care of that, to flag outputs that go to multiple destinations, etc. The beauty of a markup language is that it is easy to write; you shouldn't have to care if it is CV/audio/multed/etc.

I've thought about this sort of markup language before, but it has always been purely academic, because we don't (yet) have robots patching our synths. So there's technically no need for a computer-readable format to represent patches. But just this past weekend I saw some ads on Facebook for virtual versions of Mutable, SynthTech, and other modules, so who knows... maybe this could be used to program such things. Or hey, even translate to csound.

If this becomes popular/accepted it does seem that there could be a need/desire for some sort of module definitions that could be enforced. Like an XML DTD or something. ("Module (Left Red Squiggly Mark) -> Module (Lower Green Blob Symbol)") Perhaps modulargrid would be willing to host/maintain something like that? Seems like the most logical choice. Maybe manufacturers would be willing to contribute? But, of course, at that point we start making it more complex, where you have to reference a definition to write it, and thus making it more difficult for the average user to utilize it.

Sorry if I addressed something already discussed in the github documentation - just haven't had a chance to look yet.
dumbledog
So. I've given Patchbook a go with a somewhat formidable voice -- a patch I was playing around with using a Xaoc Drezno into a sequential switch that I'm rather fond of but want to unpatch for a bit while I explore elsewhere:

https://www.instagram.com/p/BY7acNqgWzu/

Here's the code:

Code:
SEQUENCE:
   - Pamelas New Workout (Out 1) c> Dark Time (Clk In)
   - Pamelas New Workout (Out 2) g> Selektor (Reset)
   - Dark Time (Gate 1 Out) g> ADSRVCA (Gate)
   - Dark Time (Gate 1 Out g> Selektor (Trig)
   - Dark Time (CV1 Out) p> Arpitecht (Input)
   - Arpitecht (1V/Oct) p> Tides (V/Oct)
   - Arpitecht (1V/Oct) p> Polaris (FM1)
   - Tides (Bi) -> Drezno (ADC Input)
   - Drezno (Out 7531) -> Selektor (ABCD)
   - Drezno (Out 6420) >> Drezno (In 7654)
   - Drezno (DAC Out) -> Black Xfade (In2)
   - Selektor (Out) -> Black Xfade (In1)
   - Black Xfade (Out) -> Polaris (In)
   - Polaris (Multi) -> ADSRVCA (In)
   - ADSRVCA (Out) -> Warps (1)
   - ADSRVCA (+Env) -> Polaris (FM2)
   - Warps (Aux) -> Disting 1 (X)
   - Disting 1 (A) -> MF103 (In)
   - MF103 (Out) -> Warps (2)
   - Warps (1x2) -> Disting 2 (X)
   - Disting 2 (AB) -> INTERFACE (LR)
   
   * Pamelas New Workout:
   | BPM = 117
   | Out 1 Rate = x2
   | Out 1 Wave = Gate
   | Out 2 Rate = /4
   | Out 2 Wave = Gate
   
   * Dark Time:
   | Range = 2V
   | Sequence = 0464 6435 0654 6445
   
   * Arpitecht:
   | Transpose = 0
   | Scale = Minor
   | Notes = Pent. min
   | Slide Time = CCW
   | Slide Rhythm = CCW
   | Rhythm = CW
   
   * Selektor:
   | Steps = 4
   | Direction = Down
   
   * Polaris:
   | Mode = LP
   | Type = D
   | Drive = Noon
   | Q = 10 o'clock
   | FM1 = 2 o'clock
   | FM2 = 1 o'clock
   | Distort = Off
   
   * ADSRVCA:
   | A = 0
   | D = 10
   | S = 10
   | R = 2
   | AD/Loop = Off
   | Hi/Lo = Hi
   
   * Warps:
   | Algorithm = Delay
   | Int Osc = Off
   | Big Knob = 9 o'clock
   | Small Knob = 11 o'clock
   | Level 1 = 10:30
   | Level 2 = 10:30
   
   * Disting 1:
   | Algorithm = Mono Reverb (3a/1c)
   | Z = Mostly Red
   | P0 = 20
   | P1 = 18
   | P2 = 2
   | P3 = 8
   
   * Tides:
   | Mode = Cycle
   | Range = Hi
   | Frequency = Noon
   | Shape = Noon
   | Slope = Noon
   | Smoothness = 12:30
   
   * Drezno:
   | In Gain = 100
   | In Offset = 100
   | Out Gain = 100
   | Out Offset = 100
   
   * Black Xfade:
   | Fade = CCW
   | Mode = Audio
   | In1 = Noon
   | In2 = 9 o'clock
   
   * Disting 2:
   | Mode = Reverb (3a/1b)
   | Z = Somewhat Wet
   | P0 = 15
   | P1 = 23
   | P2 = 2
   | P3 = 8
   
   * MF103:
   | Amount = 3.25
   | Rate = 8
   | Sweep = 5
   | Resonance = 6
   | Speed = Lo
   | Stages = 12


And the chart... um


The text is certainly readable. I'll try repatching this in a week or so and see if I can recreate my original patch, but I don't think it'll be a problem.

Took me like an hour and a half to type that damned thing up, but that probably can't be helped.

I don't think GraphViz will be too much help with patches this large (the other output options were worse), but perhaps it can be ported to the various mind-mapping apps like iThoughts.
oootini
FWIW, i wanted something similar a while back for a blog: http://manual-synthesis.info/2017/02/13/buscephalus/

I wanted to create generalized diagrams, and i ended up using simple flowcharts with mermaidjs https://mermaidjs.github.io/.

Less detailed that patchbook, but maybe just enough detail to make sense...
mt3
dumbledog 1 hour to type? Damn, I guess that's the next optimization. Thanks for sharing.
dumbledog
Part of the problem is having to type it on an iPad since there's a couple feet between the modular and my computer and I'll be damned if I go back and forth a million times to check knobs constantly.
wednesdayayay
hey I would love to use this my video synth
could you add in a v> video connection?
that would be helpful
maybe even
v>
vr>
vg>
vb>

that way you could separate your video rate signals/video from your RGB signal chain

I just took some patch notes on something today I'll type it up with this and see how I like it
wednesdayayay


hey is there any way to make this a bit more readable? as far as where connections are going

this is so cool
thank you! nanners


EDIT:
here is my source


COLORIZE:


- Visual cortex (Luma) >> Visual Cortex (A channel, Red)
- Visual cortex (Red) >> Curtain (Filter)
- Visual cortex (Green) >> Prismatic ray (sync)
- Visual cortex (Blue) >> Visual cortex (colorizer)
- Visual cortex (Blue) >> Visual cortex (composite)
- Visual cortex (H-V) >> Curtain (Depth)

* Visual cortex:
| Mirror mode switch = UP - H&V outputs mirrored
| Shape mode switch = Center - Linear
| Spectrum = UP - on
| Solarize = UP - on
| Composite mode switch = Center - Fade
| Key mode switch = Center - keys off
| Slider control = 20%

- Prismatic ray (anti-sine) >> Curtain (Width)
- Prismatic ray (Triangle) >> Visual cortex (A channel, Blue)
- Prismatic ray (Parabolic) >> Visual cortex (A channel, Green)
- Prismatic ray (Sine) >> Visual cortex (B channel, Blue)

*Prismatic ray:
| Sync mode switch = Gate mode
| Frequency range & sync source switch = 4th - vertical bars horizontal sync
| Frequency offset control = minimum value

- Curtain (Mix) >> Visual cortex (A channel, Green)
- Curtain (Filter) >> Visual cortex (A channel, Red)

*Curtain:
| Shape switch = 1st position, fully left
| Width ac/dc switch = DC
| Depth ac/dc switch = DC
| Range switch = 3rd position, fully right
MUFF WIGGLER Forum Index -> Modular Synth General Discussion Goto page 1, 2  Next [all]
Page 1 of 2
Powered by phpBB © phpBB Group