spektroaudio / patchbook Goto Github PK

If in your examples you had 2 Metropolis modules would the idea be that you'd say "Metropolis 1" and "Metropolis 2"?

Or would it be better to have a section that describes a modules characteristics (or a library for other users to build upon) to say to "Module1" is a type of Metropolis with these characteristics that are different than the "default" settings; and "Module2" is also a type of Metropolis with these values that are different from "default"?

Great work, really interested to see where this goes 👍

If you have a patch with two or three VCOs, how would you denote them being tuned or detuned? Or tuned an octave up or down?

It would be helpful to externalize the parser commands (module, connections, export, graph). It's more efficient and faster to just call the commands directly.

I propose that comments be added to the spec.
Maybe # or // ?

Hi!

Choosing graph direction DN selects wrong direction in output to dot. The fix is trivial.
direction_fix.patch.txt

Kind regards,
Michael

With respect to what I mentioned in the the colors thread, graphviz is drawing lines on top of each other as they traverse a graph, which then emerge in different directions. Its impossible to tell which one came from which output.

I suggested color attribute as we are discussing, but also I found it good to have the following style of the edges (cables) so that its starting point is clearly defined, which makes it even more clear when the cable gets assigned a colour. Perhaps this should be the default?

[arrowtail=dot, dir=both]

Hi!

Naming a Module "A-185-2 Adder/Bus Access" needs the '-' and '/' removed before output to dot.
A possible fix is attached.
modulename_fix.patch.txt

Kind regards,
Michael

Absolutely love this, thanks for your hard work! Wondering if it would be worth exploring adding a midi type to the types of connections available. Maybe "m>"? Many folks use midi with their modular systems, but currently I'm not sure how to best document that using patchbook

I'm getting an error if my comments are on the def line of a module parameter description
* TTLFOv2: // squares to siren to random | Wave = Square | Mode = bipolar

For the sake of easier use, it would be awesome to just export to svg directly using graphviz, when calling graph on an input file.

There doesn't seem to be any activity. There's some feedback from the community which hasn't been addressed. It's a great project and it would be a waste if it would become obsolete!

@icaroferre let me know if you need any help. I could take care of the current PRs, for example. Another option is to fork the project.

I found that because graphviz is often merging edges (cables) into the same line , it can be difficult to see which signal is being patched where at the end.

I found that I can untangle this easiest using the color attribute (and svg text color labels) in graphviz, but perhaps it could be useful to have it the markup too?

• Metropolis (Pitch) p> Braids (1v/oct) :blue

SpektroAudio has been noticed that he is trying to use a name that has already been used and copyrighted since 1996. It was suggested that he rename it. Www.PatchBook.com

The export command tries dumping the json file wherever the input file resides, when supporting it with an absolute path.
When export is called with a relative path, it tries to export where the script resides.

It should export to current working directory (wherever the script is called from) instead, to prevent trying to write to system directories. Also, a check whether being able to write to said directory should be done before trying to write (and failing in the case of a directory with insufficient permissions).

Thanks for the additions @icaroferre

I'm still struggling with too much ambiguity in the graphviz output. I don't know why GraphViz dot makes polylines join and then branch off. If they are the same colour, their output and input are ambiguous.

Here is an example of such ambiguity as the edges cross/follow the same paths and as they stick to the border of the node too closely.

I've tried a few experiments with the code to see what happens, like adding random weights, and different types of styling.

# @nel hack randomise weights line_style_array.append("weight = "+ str(random.randint(1,10)))

It kinds of shakes up the cables, but even then we get points where some polylines coming out from the same module meet at the same 'elbow' and then branch off. I suppose adding colours when this happens might help, but its a bit fiddly trying to do that in both Graphviz and the Patchbook markup script.

I did add a new styling, which helps a bit more with ambiguity than the current default I find.

`# @nel style

def graphviz():

linetypes = {
    "audio": {"color": "slategrey", "arrowtail": "dot", "arrowhead" : "normal", "arrowsize": "1.3", "dir": "both", "style": "filled"},
    "cv": {"color": "forestgreen", "arrowtail": "dot", "arrowhead" : "onormal", "arrowsize": "1.3", "dir": "both", "style": "filled"},
    "gate": {"color": "blue", "style": "dashed", "arrowtail": "dot", "arrowhead" : "onormal", "arrowsize": "1.3", "dir": "both"},
    "trigger": {"color": "orange", "style": "dashed", "arrowtail": "dot", "arrowhead" : "onormal", "arrowsize": "1.3", "dir": "both"},
    "pitch": {"color": "turquoise", "arrowtail": "dot", "arrowhead" : "normal", "arrowsize": "1.3", "dir": "both"},
    "clock": {"color": "purple", "style": "dashed", "arrowtail": "dot", "arrowhead" : "onormal", "arrowsize": "1.3", "dir": "both" }
}


            graphviz_parameters = [
                "color", "weight", "style", "arrowtail", "dir", "arrowhead", "arrowsize", "penwidth"]`

Here is an output showing the new styling , and what happens with my hack for random weights.

Would be good to have the knob settings appear in the graph alongside the connections.

Hey there!
Terrificly useful script! I'd like to package it for Arch Linux.

It would be awesome to have signed releases of the script, so packaging (besides a -git version) will become easier (and more reliable than latest HEAD).

Also, but this is a matter of taste, would it be possible to add a shebang? Otherwise I will have to do it during packaging. Something like

#!/usr/bin/python3

should be unixversally applicable.