arc devs, come play

  • I'm posting the primitive beginnings of an arc experiment. Understand, it's not usable in its current form, but I think this shows potential, so I wanted to put it in your hands sooner rather than later.

    (This is one of those early brainstorming ideas that I promised to work on long before the arc was released)

    So... What are we looking at?

    You've got two sliders, with values currently ranging from 0-127.
    (I should have gone 0.-1., but I wasn't really thinking)

    Turn knob #0 slowly (and continuously) to the left. One slider's value will increase a bit. Turn it slightly faster. The value should increase a bit more. Slow down a bit for a decrease. Stop and watch it fall to 0.

    You might think of this as applying air pressure from the bellows of an accordion, or moving your bow across the strings of a cello. Stop moving, and it goes silent.

    Now, rotate that same knob to the right. The second slider behaves as the first did, and your first slider falls gracefully back to 0 if it wasn't already empty.

    There's also a checkbox onscreen. If checked (orange), switching directions will cause the slider you were just controlling to immediately drop back to 0. This might be more appropriate for simulating intricate bowing patterns, inhaling and exhaling into a harmonica, etc.

    Still to do:

    * Make things cleaner and more flexible

    * Add LED feedback

    * Figure out what do do with the button, if anything

    * Support more knobs

    * Output CCs, map this to two parameters in Live, or actually build a synth around it

    So, there you go. What can we do with this?

    Please dissect it and build something completely unexpected. =)

  • I'm assuming this is in Max? Either way, really good idea for a gestural-ish use of the encoders!

  • It is in max.

    There isn't anything terribly sophisticated going on under the hood, so it could probably be ported to pd or something easily enough.

    ...just not by myself, 'cause pd doesn't like my Windows 7 machine. (tcl/tk issues, I guess?)

  • Oops. Forgot to make it open in presentation mode. Not worth re-uploading just for this, but if clicking the "presentation" button is unwieldy (I think it is)...

    1) Open the View menu.

    2) Select "Patcher Inspector"

    3) Mark the "open in presentation mode" checkbox.

    4) Save the file.

    Sorry about that.

  • Not the most practical example, but here's a double square wave slide whistle for arc 2.

    Connect to SerialOSC, and make sure the speaker icon is active.

    Knob #1: turn left and right to select your pitch.

    Knob #0:
    - turn right to apply volume.
    - turn left to apply volume to a re-pitched version (ie, an octave down. configurable on-screen)

    Still no LED feedback. Watch the screen for your pitch info.

    If someone wants to add Stretta's modes and scales to this thing, it would almost be useful. =)

  • coool. must have a look!

  • Nice idea !

    Probably you could map the button to reverse your CC-range you send off. Pressure off = range 0-127
    Pressure on = range 127-0

    I don't own an arc, so I can't really conribute. Perhaps we could port such functionality to monome slider. This could be fun. It reminds me on Lemur's physics feature...

  • @as,

    You could do something very different on the monome inspired by this, and that could take many forms.

    (I don't think pressing and holding a button to keep the value in one place offers much in the way of subtlety or inspiration, but you might have something better in mind for the slider?)

    I've actually got something lying around for monome whose first two iterations were based on the same idea.

    1) lay your hand flat on the monome and cover as many buttons as you can. Rocking your hand back and forth presses some buttons and releases others.

    I got as far as "use the number of buttons currently pressed to drive a CC or parameter", but didn't take the next step of "figure out what direction your hand is moving and control different parameters that way" because, in MonomeSerial on PC, you'd get a lot of "stuck LEDs". The issue was fixed in SerialOSC, on PC at least. Not sure if it'd be stable on Mac or not.

    2) I got around that by having the buttons only remain active for a short time. This improved interaction by forcing you to keep your hand moving, but completely changed the dynamic. Rather than an accordion-like air pumping motion, it became closer to brush strokes.

    ...and looked, on the surface, exactly like "trails".

    I ended up veering off in a different direction with that to set it apart, but this much was viable for the same kind of gestures.

    In fact, I got a little further with it before veering off. Hmm...

    I might dig that up later (busy all weekend) and start a different thread with it. For now, check out "trails" 'cause it's awesome, and let's try to keep this thread arc-based.


    I did think about CC reversal (it'd really be more "gravity reversal") for the button. It's just a little strange because that affects both the "left" and "right" controls. Still, it could work. It'd be more intuitive with LEDs in place, at any rate.

    I suppose it could also be a "press-turn-release" menu to select different directional configurations. (up is reversed, down is normal, left and right reverse one half only?)

    Hmm again...

  • Last post: October 8th. Interesting.

    I'm retracing my steps. The arc is somewhere in my apartment, but damn if I can't find it anywhere.

    So, last seen: two weeks ago. Great...

  • Never mind. Found it. Lost half the weekend looking, but we're good.

    Okay, workin' on something...

  • Okay, this one's even more obtuse, and you might end up filing it in the "why would I want to do that?" category, but see attached...

    Each knob controls two sliders (and an integer).

    The horizontal slider is pretty straightforward. Rotate left, the value moves left. Rotate right, it moves to the right. This one happens to wrap around, so if you pass one edge you end up on the other. That's about it.

    The vertical slider is like the "bellows" experiments described earlier in this thread. Key differences being:

    * direction doesn't matter -- it's simply measuring how forcefully you turn the knob.

    * if you stop rotating, the value falls to 0 much faster.

    And the integer is probably best ignored. (that was sort of an LED brightness reference for myself, but I just noticed I got the range wrong. 0-15, not 16...)

    So, if this were applied to the synth from my previous post, you'd no longer need two knobs for pitch and volume -- one knob could control both, and four knobs could control four voices.

    ...or something. obviously, I've got a different idea in mind. but that one's easier to explain. =)

  • Also just noticed, I forgot to include serialOSC.maxpat in there. Sorry about that. If you don't have serialOSC.maxpat in your shared folders already, just copy it into this directory from any of the other files from this thread, or from pretty much any other app.

  • Here's another prototype, still building on those ideas discussed earlier...

    This one's like 90% ready to be a usable app. It doesn't do much, but it's definitely fun to play with.

    Grab a knob and spin it in either direction. An LED rotates around the ring at the speed that you threw it. Turn it the other way, it slows down (or if you've pushed far enough, moves the other way). Each knob is controlled independently of the others.

    That's just like any number of other apps; you've seen spinning LEDs before. No big deal. What is a big deal is that their rotation is constantly decelerating.

    Give the knob a spin, and that LED will eventually roll to a stop on its own. Sort of like a roulette wheel.

    Pushing the knob in causes the LED to stop faster, like hitting the brakes on a car or a bicycle. It's not an instant halt (by design), but it is more dramatic than letting gravity do it's thing.

    There are additionally two onscreen controls, for configuration.

    * The number labeled "mechanical friction" affects how fast the wheels spin down (low numbers spin longer).

    * The toggle labeled "subtle terrain" causes random amounts of additional resistance over time, to break up polyrhythms and generally prevent simple repeating patterns.

    That's pretty much all it does right now; LED juggling.

    ...but if you imagine the LEDs as representing variable speed oscillators (driving CCs or parameters in Ableton), I think you'll see there's some potential.

    These simple physics based controls, because they aren't quantized or tied into your project tempo in any way, and because they'll quickly degrade if you stop interacting with them, that should help you to stay present and spontaneous in any performance.

    (I also want to build something based on this and JP's "kradle" app...)

  • As before, make sure you've got a copy of serialOSC.maxpat in your search path, or copy it next to this. I forgot to include it again.

  • A version w/ CC output.

    (it's actually verison #3 w/ CC, but the first two sucked more)

  • Ahhhh! I want an arc! :-)>

  • that does sound like a lot of fun!

  • One more.

    Previous versions lit one LED per knob. This one leaves firey trails that vary in length and intensity based on how fast they're spinning.

    It's a bit obnoxious. More than likely to induce an epileptic fit, really. So I'm not sure if that feature will make it into the next version. Just wanted to try it. =)

  • also? the source code's an ungodly mess at this point. if you're following along to see how this all works, I apologize profusely.

  • Sounds cool! Will have a look when I get a chance. You should really try and get some of your ideas worked into full apps gtz. You've got the control/ui sorted, just need to hook it up to some musical stuff!

  • Pretty close on this one. I just polished up the Max For Live version. =)

    And more importantly, I've settled on a name: Orbituary.

    And even more importantly, I've attached a copy.

  • I don't know. I guess I'm pleased with how easy it is to map parameters in the Max For Live version, but you're still essentially limited to one per knob, where if you're using CCs, each CC can be mapped to dozens of properties. I just wish there was less setup involved in that approach.

    Maybe if we map each knob to an instance of this...

  • I would characterize this one as "fucking crazy".

    You might not want to look at the source code; it's kind of terrible. Fun results, though.

    Same overall control mechanism as above, except instead of CCs, you're controlling the speed and direction of four motorless turntables. (conceptually, anyway. these are very broad strokes; you're not going to have subtle "scratching" control here. and it's not like there are crossfaders either, to make things more useful. really, it's just chaos.)

    I've hardcoded the stereo placement so knob 0's further left than knob 3. If you're on an arc 2, you'll want to tweak those numbers. Just, y'know, wear a blindfold when you do, or try to get really drunk first.

    There will eventually be a version where the pitch and speed are handled separately based on this work:
    and that will be more musically useful.
    ...but not as much fun.

    I recommend assigning a percussion loop to each voice (the "replace" buttons on the right), and then setting friction down to 1 with the terrain switchbox on.

  • completely don't know how to use this...Is it to be used with something else?

  • it's not part of a larger construct at this time, but the explanation isn't at all self-contained. it's a set of ideas that have been evolving over the course of this thread. I'll try to make a more concise summary:

    load maxpat, connect serialosc to your arc.
    (if you don't have an arc, this whole thread's a bit useless to you)

    by default, it's going to load "jongly.aif" (a percussion sample that came with max) into all four slots. and then sit there silently, waiting for input.

    twist a knob to the right. if all is working, you will see LEDs spinning in that direction, but constantly decelerating until they stop again. you will also hear audio "spin up" (raising in pitch and speed from nothing) gradually slow down again, and eventually stop.

    twist to the left. same result, but the audio is reversed.

    twist fast in one direction, then slow it down by pulling the other way. speed it up again by moving in the original direction.

    get it moving really fast and press down on the button for that knob. greater friction is applied, slowing things down much faster.

    And that brings us to friction. there's a number box on screen which controls that. it defaults to 25. set it to 75 and try a spin. you need more force to achieve the same speeds, and it spins down faster. set it to 1, and it takes a really long time to slow down.

    there's also a checkbox. this makes things spin down faster, but randomly, in stages, by subtle organic amounts.

    (not FAQ; nobody's ever Asked these, so this is the "Frequently Imagined Questions" section)

    * "I don't like that sample. Can I replace it?
    Yup. Hit one of the "replace" buttons and navigate to an .AIFF or .WAV or .FLAC file of your choice. Repeat for the other knobs. top "replace" button is for knob 0. second down is knob 1, third down is knob 2, and bottom one's knob 4.

    * "But, how do I create a repeating pattern that I like, save that, and recall it later?"
    You can't ever do any of that. It's designed to require constant attention.

    * "okay, but the onscreen interface is crappy and confusing".
    Yeah, that wasn't a question.

  • If there's no LEDs or audio, do let me know. It's not like I've tested this on a bunch of computers.

  • Hi
    Had a bit of look - seems to work ok - need to repatch some audio. . . .

    Strangely I had been contemplating aspects of this re my LeMonArc project.
    I already have a 'Frictionless' mode for the encoder and am implementing variable 'Arc' friction and controllable speed in coming HD versions . . .

  • * "okay, but the onscreen interface is crappy and confusing".
    Yeah, that wasn't a question.

    I searched the thread to see if someone actually said this. I need to up my reading skillz. I thought "WHO THE FUCK WOULD SAY THAT?!" Understand now. I'll give it a try tonight.

  • fantastic ideas, love the throw-patch!
    would you mind to explain, how the pulseTrain-subpatch is working? i just don't get it ...

  • Honestly, no clue. =)

    One of these versions (m4l, I think) had a "credits" window which properly attributed raja for that one. There's a thread here discussing "swing" and he posted a code snippet there which this is pretty much stolen from.

    I believe this sets the Frequency of a playing (but in audible) waveform, and bangs when there's a zero crossing.

    As such, it does require audio output to be active in the patch. So I buried an ezdac object with a loadmess 1 in there, which is extremely hacky.

    In earlier versions, I used metro and tempo objects instead, but they weren't as granular, and I couldn't figure out how to not make them bang every time you change the frequency (which in this case happens a lot).

  • thanks, maybe raja wants to join in and have a little pow-wow?

  • Stranger things have happened, but he doesn't go out of his way to hang out in arc threads.

    This is where that block originated:
    Probably better to ask him there, someplace his code hasn't been mangled by amateurs...

  • ...and, demo:

  • Progress report (sort of)

    I extended the version seen in that demo by adding a MIDI button/pad controller, set up as follows:

    * Divide the pads into four groups

    * Each group is linked to one knob

    * Each time you press a button, that knob's current time index is recorded in association with that button.

    * Each time you release a button, the recorded time index is sent back to that knob.

    So you might press three or four buttons, either simultaneously or at different times, and release them in any order for a sort of dynamic un-quantized beat juggling.

    It worked, but it was counterintuitive to work with. And since the audio stream is already warping, it doesn't necessarily sound you're repeating parts of the same loop, if that makes any sense. It sounded glitchy, but the intent of your creative decisions weren't obvious.

    So I'm scrapping that for now.


    And then just for the challenge of it, I made something more mlr-like. Fun excercise in refactoring; each "row" is actually a 4x8 column to sit under an arc knob.

    I built it a quantize feature, which is sort of ridiculous since each pattern plays at an indeterminate (and constantly shifting) tempo. It works, and I'm proud of that, but I also sort of hate it, so that's turned off by default.

    And I made sure that when you pressed a button, the audio jumped to the appropriate side of that block (depending whether the knob is currently moving forwards or backwards).

    I'm not so in love with beat juggling under this arrangement, but it does work a lot better than that first idea.

    I may scrap that as well.


    In both cases, I think it was a good translation of my idea, but that my idea wasn't very good.

    Still, they're built, and both are interesting foundations to build from. So, what those could evolve into?

    The initial button thing:

    Well first off, what I built might actually feel right if, instead of returning to the actual time index, it instead jumped to the nearest transient. But I'm not there yet in my skills.


    The hold/release part doesn't make as much sense for this, so maybe it's a toggle button now.

    Switching "on" records the current position, direction and momentum of a knob before changing that knob over to an alternate control scheme; something with less "throw" and more "scratch" potential.

    Switching "off" resets the knob to that position, direction, momentum and physics model.

    The mlr thing:

    * Maybe take a page from "the chocolate grinder", and add some grit to the transitions.

    * It might be less about beat juggling as simply defining loop regions. Which is a feature I haven't built yet. Worth considering.


    What I really want:

    A step sequencer which, rather than trigger MIDI notes, adds and removes sounds from an arc-driven buffer~.

    I don't think that's directly possible (rewriting parts of the buffer instantaneously). But indirectly, I've got some ideas. It's just a lot of work.

  • Had a play with this. It sounds/looks great.

    One thing that I noticed (only because I've recently changed that out on the party van) is the int to sig~ driving groove can sometimes sound 'steppy', particularly when changing directions quickly. It has that MIDI kind of sound.

    I was going to change it in the code I downloaded but figured I'd post it here as it might be handy. But here is this line~ smoothing thing I've started using that adapts to how fast you move (so you can still do fast gestural changes but have the smoothing be sample accurate).


  • Very cool. I'll implement later and post a more recent version.

    (I did clean up the code a lot since my last posted edition, but am hesitant to include either of those features I just described, 'cause they're going to change drastically and y'all shouldn't get used to them)

  • I've become obsessed with getting rid of that sound wherever possible in my patch (while at the same time keeping things lean and using regular [line 0.] where possible).

    Yeah I'd like to see an updated version (wether or not it will change).

  • Just got to work, where my files aren't. It'll have to be tonight.

    other improvements: (small, but significant)
    I corrected the stereo placement -- the middle two knobs were pointing to the same place. also, I broke the volume control out to four sliders.

    Not yet implimented, but definitely soon:
    * the [line 0.] change rordigo just posted
    * add on-screen dials to set stereo panning for each voice manually
    * split the friction controls out so each voice has its own setting
    * impliment a press-turn-release action to alter the friction (loosening or tightening the wheel)
    * externalize a bpatcher or two, 'cause this is a pain to edit.


    Side note:
    Does anyone know if it's possible to pipe continuous changes (CC or float values) into a [poly~] and have them be recognized by
    a) individual voices that aren't necessarily the first one?
    b) every voice?

    It seems like such a simple thing, but I haven't been able to figure that out.

  • I'm currently thinking of incorporating this kind of turntable type 'platter' control to my MLR page. Could make for some interesting stuff I think.

  • I think that's possible but my poly~ knowledge isn't great. I think you can set voices to 'busy' using thispoly and it will ignore messages (and pass it on) until it's done being 'busy. You can also target individual instances in a poly too.

  • It probably does make more sense to use this as an MLR modifier than to use MLR as a modifier for this. But I'll post my "mlr-like" version tonight 'cause that'll probably give you a better place to work from in adapting it.

  • Gonna see what you have cooked up, but I was thinking of just using the platter/friction idea and mapping that to speed/direction/play/stop. So it's there if I want it, but not if I don't.

    (unrelatedly I revamped my mlr adaptation in the party van bigtime today and it's awesome!)

  • Attached is the current state of things.

    (Added rodrigo's smoothing, and stereo panning controls. Still desperately need to break things out into bpatchers.)

    The layout is still optimized for my arc4 and a 128. So, the grid is divided into four 4x8 columns that sit under the knobs rather than splitting things up by rows. This won't make a lot of sense with the 64/arc2 combo, but it should scale down to two knobs easily enough.

  • Re: adding a step sequencer:

    Somebody did something like that a few years ago, with Kontakt and Miss Pinky, I believe. The project had a name like "armory" or "munitions" (relating to military weapons). I've been trying to remember where I saw that for three or four days now, as they do at least deserve an "inspired by" credit.

    Does this sound at all familiar to anyone?

  • Looks/sounds good. Groove sure likes to click when hitting 0 speed. I think that kills an internal process or something as it can't possible make that noise just by stopping.

    My original (and still) plan for the chocolate grinder was for it to emulate a variety of media, CD to start with, but also records, and tape etc.. (all with matching/relevant GUIs). I might *cough* borrow some of the spindown code from this for the turntable type thing.

  • sounds great. borrow away!

  • I had been sitting on this. Take a look.

  • Also found this in another patch. I don't understand the theory behind why it sounds worlds better but it does.


  • Have not checked those out yet, much less implemented. But I had an exciting idea and I had to try it. And then share it. So, see attached.

    What's new?

    1) the panning knobs work. they didn't last time, 'cause I forgot the difference between floats and integers. oops.

    2) the grid... defaults to how it was before. but within any one group, if you press three buttons simultaneously, that will toggle a new feature on or off.

    When on, you still beat juggle by pressing buttons, but if no buttons are pressed, that group mutes. This adds more variety to re-attacking the same beats.

    It isn't quite the crossfader fun I was looking for yet, but I think I know how to implement that in a fun and intuitive way.

    So hopefully next version, three buttons will toggle, one will re-attack, and while that one is held, a second button will mute without re-attacking.

    ...and I probably have to replace something with whatever it is you posted there. =)

    And then these are definitely on the to-do list:

    * Encapsulate to bPatchers. Seriously, this is ridiculous.

    * make a version compatible with thealphanerd's arc reactor.

  • Nope. Tried the second-button-mute. Pretty sure I hate it.

    edit: attached. it was an interesting thought.

  • Dang. There is a depth of craziness to your turntable patch. and vice versa.