[VIDEO] GTZ arc stuff - files added

  • First up:

    I've been obsessed with arc's display capabilities since before it arrived. This video is the culmination of many prototypes and experiments, and I'm pretty thrilled with the resuts.


    So, that's neat. =)

    The patcher that's spitting out 64 LED levels each time the ring updates is also spitting out 64 float values that can be harnessed to control.. stuff.

    What does "stuff" mean? Well, we could conceivably drive a MIDI CC with each of them, or have each ring control 64 different parameters in Ableton, where values cascade from one parameter to the next as light moves around the circle. That's one option. I can't imagine the drudgery of mapping 64 different parameters to each wheel though. Using blocks of grouped LEDs would make that more manageable, but even less intuitive, I think.

    Maybe certain LEDs trigger a MIDI note, the intensity of a note's initial hit translates into velocity, and subsequent changes before we reach 0 again are treated as some sort of continuous control for that note? That might work, but it doesn't seem very intuitive.

    Maybe LED collisions trigger MIDI notes, with variables like placement and direction and intensity to change things up? That's worth exploring.

    Maybe it's about cycling through a sample with multiple concurrent scrubbers that move around at different speeds? Maybe.

    I did build one thing with it, which I'll show you next, but I wanted to start by just opening the door for some brainstorming. Given the realms of music and video in particular, but not limited to those, what would you want something that looks like this to actually -do-?

  • Next!


    This was supposed to be an audio effects plugin, but when I ran [noise~] through it, I realized it was actually a synth.

    ...sort of.

  • great work! i've been pondering this of late after noticing that on EDW the led brightness allows you to "see" a few different levels in the arc ring.

  • Nice work. I can see a lot of potential where you're headed.

  • @gtz

    this is great! i can see this project going in many different directions. the layering of patterns and interaction between the two is amazing. i enjoyed noise experiments as well. i would have to agree with you when you say that you are considering a way of "drawing" patterns on the arc. keep up the great work!

  • @GreaterThanZero

    So I imagine you are spinning two lists around and combining them into a single map message.

    I was wondering, what did you find was the best method of combining the values? Is one layer on top, or is it the max value or what. What method looks the best.

    Was thinking that a button click could move the proper layer to the front.

  • @bar|none,


    I tried to model the compositing after the "screen" blend mode in Photoshop/Flash/After Effects, with the intention to add more blend modes later.

    How that's put together... (I'm typing from memory, but this feels about right)

    [zl lace] binds the two lists and keeps them in sync.

    the result of that operation (a single 128 item list) gets fed into [zl iter 2]. This gives me a series of matched number pairs from the two lists.

    I [unpack] each pair as they come in and simply [+] the two sides together.

    The result is [scale]d from 0-X to 0-1. X is the height of my multisliders * 2. (You can increase the height of the multisliders for added drawing resolution, and increased resolution of the non-LED output)

    [t i i] sends those numbers down two paths.

    Path #1 is the LEDs. I think it's [* 15.] -> [round] -> [zl group 64] -> [zl change]

    Path #2 is the raw values. That's just [zl group 64] -> [zl change]

    (So, it compiles our 64 composited values back into a list, and outputs that list if it isn't identical to the last list that passed through it. That makes things run a whole lot smoother)

    Path #1 goes to the /prefix/ring/map command, Path #2 goes... somewhere else.

    As much as possible, I tried to keep things modular, so there's an area of the patch that processes the individual lists, and an area that composites them. These can then be swapped out and reused and stuff.

    For example, I've got a version where you're controlling the rotations directly rather than influencing the speed and direction of rotation. that one's kind of boring so far, but I think if I add a pattern looper, it'll be a lot of fun.

    And on the compositing side, I've got a version which smoothly cross-fades from one list to the other. For whatever reason, I didn't think to have the lists in motion for that version, but that's the answer to your "move the proper layer to the front" suggestion. Hmm...

  • Awesome. thx for the details. You really gave it some thought.

    Looks nice too. I'm sure it looks a lot better in real life.

    I like the idea of using single clicks to cycle through modes or focus. Use press-hold to change a second value. It's quite easy to detect the different between a click and a press-hold. Also, was thinking with the press-hold, that you could do different actions depending on the initial direction of movement. Accum the result of first .5 secs of movement and use mode A/B depending on gesture.

    It's really fun to play with this stuff.

    [edit] Oh yeah, that "zl lace" trick is great for applying processing to each pair of values. I was looking for some iterative action akin to applying an operation to each member of two lists. Thx.

  • Missed this while I was on vacation *shakes fist at tropical beaches* so bumping cause I just found it and this is awesome.

    I'm coming to the decision though that I need another 2 or 3 arc4's.

  • Okay. This is pretty raw. I need to clean the code up (a lot) and release some of the abstractions individually, but I won't have a chance to do that until after Maker Faire. So... here's the code now if you want to play.


    within that:

    layers.maxpat is what I showed as "nArcolepsy".

    layers-audio.maxpat is what I showed as "ArcAde". It's the same interface as "nArcolepsy" (four instances of _additiveTempo.maxpat), but with the numbers driving some audio now.

    I think those both have the prefix "layers" right now, 'cause I was sort of lazy.

    layers-drag.maxpat is essentially layers.maxpat, but not tempo driven. when you stop moving the patterns around, they sit still. If you swap ArcAde's _additiveTempo subpatch with what's used here (_additiveDrag.maxpat), you'll have more direct control over that. Which becomes more interesting when we add pattern recorders, but I haven't gotten there yet.

    layers-crossfade.maxpat smoothly fades from one pattern to the other. Less interesting when the two patterns aren't changing, but in combination with these other ideas, could be quite powerful.

  • Oh, and you might have missed this too!


    Much fun there. =)

  • woah. lots of cool things going on. :D

  • What I said up there about making substitutions in the layers-audio.maxpat? That isn't actually working for me right now.

    Possible (likely even) that I've messed up my files since uploading that ZIP. (I was rewriting one of my abstractions recently be reusable in more situations, and I'm beginning to think I might have broken every patch it was used in.)

    I should download a fresh copy before declaring my incompetence, and/or put some time into troubleshooting later -- meanwhile, you might be better off pretending I didn't say any of that.

  • hmmmm, this got me thinking you could do subtractive/additive "synthesis' on CC values.

    I'm thinking a m4l patch that I drop in, I get to pick a param I want to control.

    The top table contains the + values, the bottom the - values. turning the dial makes the two move.

    It would be like a crazy CC comparison LFO.

    If you don't have that on your road map, I might look into porting your ArcAde

    Arcade CC ?

  • Go for it! That'd probably end up with a different name -- this was "ArcAde" simply because the sounds it produced felt so much like classic video games.

    I definitely want to explore different compositing modes. And doing -something- with CCs was on the horizon, though I'm not sure I'd have ever come up with that arrangement, on a couple of levels.

    "Subtractive mode", I figured would start all-on, and both rings would be negative.

    Then, "Difference mode" would be reserved for more general purpose tasks that don't affect your output values. Like, "one layer represents your wave file, and the other is just your playhead" in something like Arcorder. Or "an additional layer that the user doesn't control divides the ring into regions."

    I'd never considered letting the user draw two layers at odds with each other like matter and antimatter. It's worth exploring, but I'm concerned that the user won't be able to keep track of their patterns visually. I guess it depends how you handle that.

    For CCs, I'd been thinking of a version that divides the ring into quadrants, and derives a number for each quadrant based on the interactions within it. Maybe it weighs things more heavily towards the center of each quadrant, but I like the idea that there's a constant amount of energy in play that you're just redistributing between different parameters. Like dollars in the economy, or nutrients in the food chain.

    Maybe that one'd be "arconomy" (or "ArcOnomy" to keep the naming convention going). But, for that name, I also want the patterns to slowly fade out over time, forcing you to draw new patterns more often.

    It's a better pun than playing off of "ecology", simply because everyone's expecting an "archeology" pun and they'll think "ArcOlogy" is that. Which is a shame, 'cause ecology is such a great word for cellular automata stuff. (I think my first cellular automata on arc is going to be called "Arc Coli", named for the bacteria in undercooked chicken.)

    Anyway.... by all means, play with this stuff. =)

  • ah just found this thread again, great stuff GTZ! will have a proper look at this after work... thanks!

  • Cool.

    This week's a little crazy with job hunting / wrapping up things at work / honoring my previous commitments / etc, but I'd be happy to answer questions and help adapt stuff to your own apps ...eventually.

  • hey gtz, could you tell me where to look in your additivetempo patch in order to slow down the rate of "turn" for the layers? for example, as the patch stands, you can get the layers to spin up really quickly with a single turn of encoder, i'd like to be able to have a finer rate of control.

  • I'm not near my Max/MSP computer, but that control is actually tied to a hard BPM, and I think there might was some hackiness involved to get the tempo as granular as it is. ie, slowing the tempo down and multiplying it by something, or speeding it up and dividing. Something like that. I'll have to stare at it when I get home and report back. But really, the clock is replaceable. I think it's just sending Bang messages on a regular basis?

  • Yeah I'm sure ill be able to figure it out. I too am away from my fun computer ;)

  • Also, if any of you missed them, there are a few more experiments in this thread:

    I probably should have posted them here, but those are more about interaction where these seemed to be all about LED rendering.

    Got something in the works right now that's a little of both. Strange lights, strange interactions. Lots of JavaScript. I need to hook in the MIDI output this weekend and actually hear what it's outputting, but that might be enough for a proof-of-concept video, maybe.