Color Highlighting with easyflow ‐ the abstractions - HenriAugusto/easyflow GitHub Wiki
I'm assuming you've read all the previous chapters about the concepts of color highlighting.
Types of [cnv]
Currently the types of [cnv] objects that we aim to create are
- rectangle, non-labeled: used for marking matching [send][receive][value] objects
- circle: used for marking what [send][receive][value] objects are inside a subpatch
- triangle: used for marking variable wireless connections.
- rectangle, labeled: used for multiple purposes, including grouping [s][r][v] objects with related function.
- curly: used for marking local [s][r] names (ie. telling they are/should be used only on that patch)
manual vs automatic
There are two ways of adding color hihglighting to your code with easyflow. I'll explain both and then compare then.
Automatic
The automatic color highlighting methods lets you associate colors with unique names. Then you create an abstraction that loads one of the [cnv] "types" to highlight your code and pass the associated unique name as an argument and it loads the sets the [cnv] color automatically.
See, in the image below, that we have 4 unique [s][r] names ($0-testName1-4). They color are declared with the [colorDef] objects. When you change the definition of a color the corresponding objects change their color automatically. This provides an easy way to set up the colors.
For example, if you decide later to change the color associated with an name you don't have to manually set the new color on each [cnv] object.
[colorHighlighting]
This is the object responsible for:
- holding the list of unique names and their associated colors
- calculating their integer value to be used with the |color( message to control vanilla's gui objects and sending it to the other objects
[colorDef]
This is the object responsible for:
- telling [colorHighlighting] to add a (unique name,color) pair
- telling [colorHighlighting] that a color was updated
[colorCnv][colorCirc][colorTri][labelCnv][colorCurly]
Those are the objects to create the display the [cnv] objects. They are meant to stay in your patch.
[sColor][rColor]
It is a wrapper containing a [colorCnv] and a [send][receive] object!
Those are the only exception in the sense that they DO alter code functionality. That means: if someone doesn't have easyflow and tries to load the patch the [s][r] inside [sColor][rColor] will not be created, thus the code will behave unexpectedly. Yet they are powerful because they're the only ones that are updated automatically when you change the [s][n] making changes on the code very easy. Also when you move the object the colored canvas is moved automatically with it!
Manual
Those are "factory objects", meant to create [cnv] objects of fixed colors. When creating one of them you specify exactly it's color (following [colorSyntax] definitions). After loading the object you copy-paste the [cnv] into your code and delete the abstraction.
Why? Because each of those factories contains a [colorSyntax] which is a big and complex object. If one would leave the factories in the patch then the loading time of the patches would increase significantly. If you have never seen what a .pd file looks like try loading one into a text editor. The .pd files must be parsed when loaded and when you have a lot of abstractions inside each other (some which are very complex themselves) Pure Data will have lots of file parsing to do. One more reason, as we will discuss later, is that it would add a dependency on your code.
Important note
After copy-pasting a vanilla's [cnv] object from a factory you do not need them anymore. You can just copy-paste from similar [cnv] that you have in your patch and edit it from there. (but the factory might still be usefull if you want to specify the color using [colorSyntax])
[colorCnvF]
(https://github.com/HenriAugusto/easyflow/raw/master/wikiFiles/colorCnvDemo.png)
[labelCnvF]
(https://github.com/HenriAugusto/easyflow/raw/master/wikiFiles/labelCnvDemo.png)
[colorCircF]
(https://github.com/HenriAugusto/easyflow/raw/master/wikiFiles/colorCircDemo.png)
[colorTriF]
(https://github.com/HenriAugusto/easyflow/raw/master/wikiFiles/colorTriDemo.png)
note: You need to delete the receive symbol when using the "factory objects"
After copying the [cnv] objects into your patch you should delete the receive name" from them.
For some reason the color values output form the color objects do not work with dynamic patching so creating the [cnv] objects dynamically doesn't work. Also clearing a [cnv]'s receive symbol from the patch results in a bug. This is the reason you must still delete the receive symbol from the [cnv]s you copy. The abastractions can't delete them automatically (for now).
Prev: Color Highlighting with easyflow ‐ variable wireless connections