Forum

Welcome Guest 

Show/Hide Header

Welcome Guest, posting in this forum requires registration.





Pages: [1]
Author Topic: Polargraph API
sandy
Administrator
Posts: 1317
Permalink
sandy
Post Polargraph API
on: September 2, 2013, 23:43
Quote

So there's been a bit of chat about making an API for the polargraph machine.

Decoupling the control interface from the comms and from the pattern generation stuff is something I've been meaning to do for about as long as the controller has existed, but what I've actually done is just shoe-horned more and more stuff into the controller instead. The downside to that is that the barrier to other folks adding anything gets steeper as the code becomes more and more dense.

I think abstracting the modular parts out to a library is the right thing to do. I don't have the right skills to do that very well with the firmware, but I can do it for the processing stuff I think.

The problem I'll have is figuring out how abstract I can actually make the interface for it. Actually the current controller has the machine itself fairly well abstracted, but some extra simplification might be necessary because it incorporates all the image loading, position and guides and things on it.

So something like:

// set width, height, max drawable area (top left, bot right coords), and steps per mm,
m = new Polargraph(890, 1000, 100, 120, 790, 800, 66.7);
 
// define the home position throw exception if outside of drawable area
m.setHomePosition(new PVector(445, 120));
 
// define the area to be used for drawing operations
// this is an area that will have it's own coordinates system and can behave a bit like a mini machine
sub = m.createNewDrawing(100, 120, 400, 400);
 
// make a queue up and attach it to the machine object
PolargraphQueueWriter queue = new PolargraphQueueWriterVirtualCom("COM 14");
sub.addQueueWriter(queue);
queue.pause();
 
// build a couple of commands and put them in the queue
PolargraphCommand command = sub.getCommand(sub.SET_POSITION_TO_HOME);
queue.addCommand(command);
command = sub.getCommand(sub.MOVE_TO_POSITION);
command.addParams(100, 150);
queue.addCommand(command);
 
// run the queue
if (queue.ready())
    queue.sendNextCommand();

I'm putting this here as a way to see if my way is stupid. Have a think about things you would want to be able to do. I'm working on the basis that you make a machine object, define an area on that machine, define a scaling value for that area, and then start firing coordinates into it. Now it could take care of the comms too, and the queue, or it could just return each input coordinate as it's own translated command, and it'd be your job (or the job of some other class) to catch those and put them in a queue, however you're connecting to it.

The former would be an easier thing to get up and running, but the latter is a better plan in the long run. I'll have a think too. This probably isn't the best way to design an API, but we'll go with it for now 🙂

Cheers!
sn

gontiki
Newbie
Posts: 24
Permalink
gontiki
Post Re: Polargraph API
on: September 13, 2013, 00:07
Quote

Hi Sandy

There are not much comments on your question yet, so I may make the beginning.

I think it would be certainly interesting to have a way to program user modules which generate vector drawings (either plain algorithmic or from the pixel image) within the controller.

With the current controller it is to complicated to do it, it is easier to make some SVG graphic with whatever tools external and just load it into the controller.

I am not sure if I would need to program or use the queue, or set machine parameter - it is all there. But I would like to have access to the pixel image already loaded and being able to draw vectors on a virtual canvas (just as the controller does it somewhere hidden in the processing code). Having such a defined module framework would allow to migrate own modules from one controller update to the next and user could share their extensions.

That said, as long as the controller compiles only on Processing 1.5 and hasn't been updated to 2.0, the whole project becomes more and more obsolete which is really a pity.

sandy
Administrator
Posts: 1317
Permalink
sandy
Post Re: Polargraph API
on: September 13, 2013, 18:43
Quote

Fair points gontiki, thanks. I will say now that I have no desire or will to make the controller resemble anything programmable, or to add more "drawing" type tools to it. If anything, it will go the other way, and I will reduce it to a module that plugs into another application - like the eggbot software in inkscape. Your response that it is easier to make some SVG externally and load it is exactly what I was hoping for! Of course a middle-ground would be nice, so that it is not so complicated to add new features to the controller.

I think separating the control API from the interface is a good step to achieving that. I had considered the image processing parts (re-rasterising the bitmap images etc) to be part of the interface, but perhaps that could be abstracted out too, and have it's own API.

I'm working on upgrading to processing 2. I think like you discovered, that bit is easy enough, but moving up to the new version of controlp5 is turning out not to be trivial! Controlp5 has removed a few of the things I count on (sub windows mainly) and reinstating them is awkward.

I believe only a minority of folks actually compile the controller to run it themselves - most use the precompiled binaries, so a dependence on older stuff is not the problem it might at first appear to be. For the handful of people running from source though (I thought it was just me :)), yes it will only become harder over time.

sn

gontiki
Newbie
Posts: 24
Permalink
gontiki
Post Re: Polargraph API
on: September 13, 2013, 21:55
Quote

It really depends on what people want to do (and I can only talk for myself). And it is not trivial to see where the next steps might be without opening the Pandoras box or collapse the whole project.

I know Processing since the early days because I am interested in generative art and now having the Polargraph and being able to draw huge size graphics for a very affordable price is unique.

So, size is one important point. Next we have a nice GUI (as nice as it gets in Processing) to load pixels or SVG, manipulate them send them to the server. To my opinion, that is a very nice framework, worth to keep alive. You have put a lot of work into this and it is appreciated.

I also looked into the Inkscape EggBot plugin a few weeks ago because I could not resist to bake the WaterColorBot Kickstarter. But this plugin is basically a SVG to stepper converter. And also within Inkscape one is more or less limited to the effects and filter they offer. It is not really a good environment for experimenting with generative art. On the other side, for Processing there are so many ideas and sketches available (http://www.openprocessing.org/) which could be adapted to the Polargraph. As an example of what I mean I would like to mention the work from Harvey Moon (http://unanything.com/).

This is where my idea for this "drawing module" came in. As input the drawing module gets nothing/preprocessed pixel/splines and it gives back a virtual canvas of vectors (i.e. a list of vectors). The controller take them over, scale them to machine coordinates and send them to the server. (I don't touch the discussion about the coordinate system here).

I am not surprised that only a few people actually compile the controller in Processing, because as it is, for an outsider there is little to do. I see a better change if we would have those "drawing module" and a well documented interface.

That would indeed mean to restart with a stripped down version of the controller (like 1.2.5) and only the INPUT, SETUP and QUEUE tab to start with. I am certainly willing to contribute to this project, but (there is always a BUT), I have no knowledge about controlp5 because I always hated GUI programming.

So, to summaries, one possible way might be: strip it down to the essentials, move to Processing 2 and choose a better naming scheme for the code modules which makes it clear what belongs together.

Let's see what others think about...

PS: Next eight days I am offline, so no immediate response from my side.

Pages: [1]
Mingle Forum by cartpauj
Version: 1.0.34 ; Page loaded in: 0.024 seconds.