NG Media and Implements

[techninja]

This has been touched on before, but as I build out the "custom colorset" builder/functionality, I wish to clarify what makes the most sense for an "open" future in this, leaving the path open to supporting "everything" capable by bots without having to redo everything in the relatively near future.

I'd say there's two paths to go here:

1. The more direct path that simply "adds" support for arbitrary pen groupings
2. The more complete path that defines implement types, media, and optionally, targets

I've already done a preliminary design of what the definition of each of the three things might be for option 2. This allows for some pretty wacky things that although not physically supported yet could technically be in the future, or with some other bot type.

// Mediasets define everything about how a set of thing will be used
// 1. Define What implements are allowable
// 2. Define the tool change procedure should be used
// 3. Define what the set is

var mediaSetOptions = [
  {
    implement: n,
    media: n
  }
]

// Implements are the things that contain or transmit media. Implements define a
// shape, output dimensions, name (for searching), and a type that defines
// what media they accept. They also define IF they accempt any media at all.
var implementOptions = {
  allowsMedia: n, // Boolean, if the implement allows for media on it.
  // Brush, wax, pen (tehchnically) do; engraver, laser other do not.
  outputDimensions: {
    width: n, // Effective area defined from these, as will preview
    height: n,
    length: n // Bresh bend amount calculated from this
  },
  angle: n,
  // Shape is mostly for brushes, defines dynamic at different Z height, and
  // purpose of "angle" above.
  shape: ['flat', 'round', 'filbert', 'fan', 'angle', 'mop', 'rigger'],
  name: n,
  type: ['brush', 'pen', 'refillpen', 'engraver', 'wax', 'laser', 'extruder', 'other']
}


// Media is a thing that goes on/in an implement. Like a paint color, or the
// stuff being extruded from an extruder. It defines a color and what kind of
// implements can use it. I suppose it should also define viscosity or any other
// interesting properties it might have that we care about :P
var mediaOptions = {
  color: {
    display: n, // Display one color, match to another
    match: n
  },
  limitType: n, // Array of of implements this media allows
  type: [
    // Ink within the implement, saved here for the sake of grouping.
    'penink',
    'dry', // Metal scribe, pencils, etc
    'dryink', // Dry ink block, used with brush
    'drypaint', // Water color paint
    'wetpaint', // Acrylic, oil, etc
    'water',
    'extruded' // Plastic or chocolate, it's all extruded!
  ]
}

// Define Media target, or base (what MEDIA is being applied TO via the
// IMPLEMENT). Paper, cloth (for batik), etc. These also define what media and
// implements are allowed (or make sense when applied). Could you laser an egg?
// Probably. Can you water color metal? no. Should you extrude pancake batter
// onto paper? no. 
var mediaTarget = {
  type: ['paper', 'cloth', 'egg', 'metal', 'hotplate'],
  allowedMedia: [],
  allowedImplements: []
  color: n
}

Honestly, I know this opens up a TON of edge cases and cans of worms inside of cans of worms, but I wanted to at very minimum define the workspace we'd be defining our supported uses cases in would be.

[techninja]

@oskay I've made great progress, and have found the JSON Schema format that can perfectly describe The above, AND this can be used to both create input forms automatically, and verify the data! In fact this is so cool it's likely to completely replace the current settings form insanity of huge tracts of mostly duplicate HTML and somewhat duplicate data verification and saving.

Regardless, I'd like to now discuss specifics for real world users:

• The above defines basically that a "media set" is a collection of implements paired with either an implement type, or a specific implement (the latter being most important).
• The order of these pairings within a media set the order in which they're chosen/grouped.
• Any implement/media selection can be made into a media set. This means:
  • Our current "standard" media sets will just be drypaint media with colors defined, associated with a given media set with simply the "brush" type associated. Each media definition will also include a refill index, and refill grouping name (you'll see why).
  • A more advanced media set could simply duplicate any existing media set and add to it any implement switch for a media (change brush types for certain colors), or add a black sharpie to the start/end of a painting.
  • You could even combine specific colors from multiple color palettes, and when complete with one (we can tell because of the refill grouping name from before), you will be prompted to switch it out and confirm when complete.
• This means not only pause/resume for pens, but for any user required change of implement, or refill grouping (paint palette). This is going to need the bot having a good idea of what's physically installed, and telling the user what it thinks it knows clearly.
• With some space on the right side of the toolbar we already have planned a small icon to represent what bot is connected. To the right of it we would show an icon of what implement should be in, and what media we expect to be on it (either none, or a color).
  • This would have helpful hover text and if clicked would allow you to correct it if it's wrong, or select something else.
  • This same place would appear during print to assist in clarifying what you need to change to (and from) and calibration before continuing.

Yes, this all feels a bit too all encompassing, and a bit over-engineered, but I'd certainly call it a best case scenario goal.

We may want to schedule a conversation to work out a better short-term plan for making only pen switches work, or just skipping that altogether and just pushing for more testing to get the current version released.

[oskay]

I'll be happy to schedule that conversation, but I do feel that it is more urgent to begin working towards test and release-- I'd really like to get the new version out that works under El Capitan, and I'm quite happy to help with testing and so forth. So, my inclination would be to preferentially favor beta release over new features at this time.

[techninja]

Same here. Leave the pot cooking for too long and it grows tentacles. I've done a huge amount of work to make it faster and more reliable, and it does no one any good to leave it behind bars waiting around.

I'll need to do some testing, but I'll see what I can do to make a beta pre-release, we'll call it version 2.