Color Highlighting with easyflow ‐ introduction - HenriAugusto/easyflow GitHub Wiki

This article is about a technique i've been using in my Pure Data programming throughout the years. It is simply my suggestion, based on my practical experience, of you you can do to better organize your code in case you need it. There are no rules and no right or wrong here.

I've devised those practices naturally to solve some organization challenges when writing complex code. From time to time i question, change or expand those concepts. I've decided to share them in hope they might me useful for other people. I am, of course, open to suggestions and would like to hear about your experience.


The result was some kind of color highlighting, somewhat similar to syntax highlighting but you're not coloring words according to their use but instead coloring wireless connections in order to take advantage of the [send][receive] objects to write clean and easily readable code.

**It is important to note that those techniques should not alter the functionality of the code in any way. ** Just like syntax highlighting in any text editor. (There is a single, justifiable, exception.)

PD is a graphical language. So managing space is crucial to organizing your code (especially if you're using small displays).

You should see many examples of color highlighting throughout the easyflow library.

(if you don't know what an abstraction does just check easyflow-help.pd. Every examples use only vanilla and easyflow unless otherwise noted)


In this wiki we will

  • Explain the concept of color highlighting
  • Show you the some [easyflow] objects that you may use to aid you in the task. There are two workflows presented.
  • Discuss the workflows and when to use each one

Motivation

First i'm going to show you why using color highlighting might be useful and show some examples. Then finally i'm going to show how to do it using easyflow.

Let's take a look at [easyflow/listConcatenate].

First of all, wireless connections ([send][receive]) are not only useful to send messages to other canvases but they're also very useful to avoid crossing your "cables" around the screen!

This is [easyflow/ListConcatenate] without any wireless connections! Ew! [easyflow/ListConcatenate] abstraction without colors and wireless connections

Now let's get rid of this mess using wireless connections

[easyflow/ListConcatenate] abstraction without colors but with wireless connections

Imagine you don't know (maybe you really don't) what this code does. How fast can you figure it out? How easy it is to follow the data flow? How many wireless connections are there? Now let's do something to make it easier for our eyes to find matching [send][receive] objects. For each unique [s][r] name we will add a colored [cnv] object besides it, with a matching unique color. (unique name = unique color)

[easyflow/ListConcatenate] abstraction with colors!

A breeze, right? You can almost instantly find matching [s][r] objects on the same page. You can rapidly count there are 4 unique [s][r] names.

Now, what about the [r $0-outlet]? Where is it's matching [s] objects? They're not on this page, but you can easily find it by following the circles besides sub patches to find it. Noticed an black circle besides testForOneElementLists? Just open it and here it is!

[easyflow/listConcatenate] subpatch!

For an example that uses this highlighting more extensively let's take a look at [easyflow/for]

easyflow/for(https://github.com/HenriAugusto/EasyFlow/raw/master/wikiFiles/forColorCircDemo.png)

Let's say you want to find the matching [send]s for the [r $0-direction]. From the top level patch you already know that all of them are inside [pd modeCheck]. Then you open it and you see there is one inside [pd mode1] and other inside [pd mode2]. After looking at [pd mode2] You've just found the one inside it. After looking at [pd mode1] is still you can quiclky find it is inside [pd checkDirection].

Easy, right? No need to hit ctrl+f and have a thousand windows opening and clustering your view. This is specially true if you have many sends/receives with similar names, for example [$0-initialize] or anything you might use a lot. Using the "find tool" is not reading your code. Browsing your patch is reading your code.

Say, if you're looking for a specific send/receive name related to some functionality of your code, like for example reading a sample from the disk, you will directly "follow the circles" from the top level down to your object starting by clicking on your subpatch that is responsible by reading a sample from the disk. Instead of searching the [s][r] objects in creating order ("ctrl+f") method you will only see the windows related to what you're looking for, because you know your code and you've marked it.


Next: Color Highlighting with easyflow ‐ inlets and outlets