I started learning livecode so that I could build a prototype of an idea I have for documenting open source hardware projects. It's complicated enough that it requires a dedicated application. I've shown the idea to other people and they've liked it, but they don't work in livecode.

So I'd like to see if anyone who already knows livecode is interested in working on the project with me, but there isn't an obvious place like "here's what I'm working on" in the forum. It would be nice to have a place like that to encourage people to collaborate in livecode.

Anywho, if there is a more appropriate place than the "off topic" section I can move this later.

------------- the pitch --------------
I'm more of a hardware guy and I got more and more involved in open source hardware after building a RepRap Mendel (3d printer). There's a lot of potential for an open source approach to hardware projects to rapidly advance the state of the art and reduce costs just as that approach helped in software. The problem is that hardware projects rely on a human to "compile" the object from source so they require much more complicated instructions than software projects. I've been working on a framework for handling that complexity for a few years and for the last year I've been trying to implement it by writing software. After a couple false starts I found livecode and I've made good progress learning it and working through the details of architecting the application.

Several other people in the open source hardware space like the approach I'm taking but they either don't code at all or don't want to sit down and learn livecode. So I'd like to try to convince someone who already knows livecode that this open source hardware documentation thing is a worthwhile project.

What I'm working on is 2 of 3 primary components: a text file (platypus) and an application (platyvue). The platypus files are human-readable text that serve as a kind of "index" for the entire hardware project; tying together all of the various pieces of information and incompatible files. The data structure is a list of keys that count up from 1. Some of the keys contain "historical" actions and some contain the results of those actions. When parsed into a livecode array and displayed in the platyvue application the user sees a graphical network of steps which lead them from the beginning of the project (list of tools/materials) through a series of changes to the end of the project (a finished thing). The user can create and recombine the steps and the information/hyperlinks attached to them to build up instructions so that other people can replicate their hardware project.

The platyvue application itself is based on the idea that the network of project information is too complicated to represent in only one way. So there is one consistent record (the platypus data structure) and any number of different ways to render it to make it easier to understand and edit. For example, the array itself is the rawest representation, I'm using rTree as a slightly less raw way to view the information in the array. I've also got a graphical network view that shows the steps as links and nodes that can be dragged around. Some other views to come later are a bill of materials, a list of step-by-step instructions that serialize the network, and maybe project views like a resource list and gantt chart. The idea is that all sorts of different views can provide insight into the same project by focusing on different facets of it; so it should be quite extensible in that way.

The platypus data structure it's based on records of the entire history of changes to the project (effectively it's one long undo stack). Those changes include relatively simple incremental steps like "make a new node", "link these two nodes", and "tag this node with this data." The structure is primarily made up of state and change nodes with flow links putting them in order from "earlier" to "later" in the scope of the project. The structure is also recursive in that each project has a scope and each node can define other nodes as being inside of its scope. The structure allows for linking between different platypus projects so that if someone has already created instructions you can just "include" them instead of recreating them. The structure also allows for recording pretty much any activity at all and keeping track of what order things happened in. So, for example, you could gradually build up the instructions for a project in platypus AND you could discuss your design decisions in another platypus file. That way you could link to what you're talking about and the link would always reflect the status of the project at the time you talked about it; preserving important context.

The end goal is the 3rd of 3 components which is to host this on a website so that it's easy for people to discover and remix the documentation. A website would also allow for all kinds of neat big-data utilities. For example, by crawling all of the instruction everyone has built and hosted it would be easy to build a histogram of which size bolts are most popular. Then developers might see that if they switched to a different sized bolt it wouldn't change anything significant about their hardware but it would leverage a lot of bolts that people already have, making their project easier to replicate.

It's audacious and it would be nice to work on it with someone else who understands livecode so that we can talk more nitty-gritty implementation stuff.

@ mattmaier: Thanks for posting this. Sounds like a great project, and I appreciate the effort you went to in posting your outline here and setting up your Github repo.

I just created a new forum section here to house such projects, and have moved your thread into this new section. I also took the liberty of editing the thread title to more clearly reflect the project.

Thanks again - looking forward to seeing some good collaboration here.

Richard Gaskin
Community volunteer LiveCode Community LiaisonLiveCode development, training, and consulting services: Fourth World Systems:http://FourthWorld.comLiveCode User Group on Facebook :http://FaceBook.com/groups/LiveCodeUsers/

It looks like it could evolve into an app for tracing the evolution of any kind of sequential process – for example, creating an eLearning course or planning an intentional community.

An interesting interactive text<->diagram tool called Proquis AllClear Flowcharter offers a highly intuitive system for creating visual maps of sequential process steps. One can create a script in text format in a dead simple way, and a flowchart instantly appears.

Hi Matt,
Thanks for the presentation at the Users group meeting. It's very cool! I hope you do end up adding some screenshots to this post, because I think it will help people to understand your project better.
Happy to see the evolution. Best of luck!

openworld wrote:
It looks like it could evolve into an app for tracing the evolution of any kind of sequential process – for example, creating an eLearning course or planning an intentional community.

An interesting interactive text<->diagram tool called Proquis AllClear Flowcharter offers a highly intuitive system for creating visual maps of sequential process steps. One can create a script in text format in a dead simple way, and a flowchart instantly appears.

A change log might then let people see the evolution of a diagram, and ideally enable forking of part or all of the script/diagram at any point.

What do you think?

That's a nice way to interact with the data structure. I like having more than one way of representing the same thing so that you can use whichever makes the thing you want to do next easier or clearer. How does it represent non-linear, non-hierarchical flowcharts in text? The video I found had someone building a "flowchart" that was just a fancy list.

Actually when I started out, and for most of my initial work, I was trying to work out a syntax for writing Platypus in plain text. Eventually it morphed more and more and I realized that there wasn't any advantage over a simple adjacency list, and even then a project of any size at all was impossible to make sense of. So I held on to the human-readable part by using JSON to store the array, but there's no particular reason the files have to be plain text aside from the principle of openness. I'm curious how they addressed the complexity of a network structure using only document formatting. Seems like at some point a new line won't tell you enough and you have to just start using pointers to addresses. That's when the whole "just write a description of the network" thing starts to get questionable. I don't think humans can understand and edit a network without a picture. But Platyuve does have a text-based editor (in rTree) because it's a good backup.

Diane wrote:Hi Matt,
Thanks for the presentation at the Users group meeting. It's very cool! I hope you do end up adding some screenshots to this post, because I think it will help people to understand your project better.
Happy to see the evolution. Best of luck!

Howdy, thanks I really appreciate that. Here are three screencaps of the things Platyvue does at the moment. The instructions printout and the resources printout are calculated automatically after every change.

Instructions is using a breadth-first-search nested inside of a depth-first-search. It starts at the highest level of scope (nodes that only contain other nodes) and dives in. When it gets to nodes that start the flow it follows them. When it gets to a node in the flow that also contains other nodes, it dives in and follows the flow again.

Resources is using a depth-first-search starting at both ends of the flow contained in record 1 (which is system generated). It builds an equation out of the link weights it finds and applies the result to the nodes that begin and end the flow. This one works as long as the project is pure assembly or pure disassembly. If the project contains both then the math doesn't work. I'm wrestling with how to build the equation so it handles more cases.

I came across today a system that (like Proquis Allclear) uses a quite simple script to create and nest flowcharts and mind maps. It's an online service called TextoGrafo, and a brief video on it is here –

>> How does [Proquis AllClear] represent non-linear, non-hierarchical flowcharts in text? The video I found had someone building a "flowchart" that was just a fancy list....I'm curious how they addressed the complexity of a network structure using only document formatting. Seems like at some point a new line won't tell you enough and you have to just start using pointers to addresses.

I just experimented with Proquis. The text content inside the two non-linear diagram objects shown in the attached screenshot is sensitive to whatever one types into the pane on the right side. The right pane shows all of the scripting used for creating the branching behavior in the two diagrams.

Yet it turns out the location and styles of the diagram objects themselves are not set by the script visible on the right pane. Instead, the desired diagram form(s) and images must first be dragged and dropped into the center canvas, from a pallete of options at the far left side. Dragging them into the canvas immediately populates the associated placeholder text and syntax into the pane on the right. Once there, the diagram and the text are mutually linked – changes in the text for either one ripples through immediately to the other.

Hope this helps... look forward to any comments or further ideas relating to this.