Nice! I like the saturation a whole lot better than the quick-and-dirty tanh~ that I was using. A few quick thoughts…
-You’ll want to test the friction control with the Arc. The reason it was kind of hacky is that the friction is displayed on the Arc itself (i.e. you’ll see the speed control sink back to 0). I was having a difficult time coming up with a solution that kept the Arc within useful boundaries, updated smoothly, and displayed properly… This current method sounds nicer, but it’s not interacting with the Arc. The “line” method stinks, though, I agree hahah.
-When friction == 0, it should just stay at the current speed. I’ve been using this for more sustained loops and finding ideal spots to scrub. It’s also really nice when using the alternate Stretch mode.
-Wow/Flutter should have a depth control. Just a 0-1 that multiplies the W/F jitter at the last stage.
-Likewise, Random Filter/Volume/Compression should be optional.
-Which popup thing was killing you in BEAP? I typically use it with “autoname” enabled, which generates soundfiles in the arcTape directory automatically whenever you hit record. In my mind, that allowed for more rapid experimentation without breaking flow. The sfrecord~ can also give false security. If you hit “Record” without hitting “open” and naming a file first, it will silently post an error to the Max window. That’s more of a workflow thing, though. If you like to generate one big, specifically named file, sfrecord~ interferes less. If you like to generate a bunch of smaller files all at once, BEAP’s autoname is easier.
I guess, in general, I had started this as an HC-TT emulator, and then it kind of became a more general purpose arc-based soundfile manipulator as I started using it. We could do:
Split this into two related projects. One could be a more dedicated HC-TT emulator, with all of the tape and friction features always-enabled.
Merge the two projects, but add in switches and controls to determine exactly how tape-tastic the output is.
What OS is your Mac Mini on? There are some required methods for fixing the FTDI driver that have been posted on the updated installation instructions: http://monome.org/docs/setup/
I had to:
I imagine you have something specific in mind, so you can just grab whatever bits you find useful from what I put in.
I was aiming for something along the lines of scratching a tape type sound, so there was no ‘play’ really, only momentary bursts of activity, with friction being the only thing that maintained momentum as it were.
The bits I built in have parameters exposed, so it would be easy enough to make them fully controllable, or to have presets or something along those lines (the approach I’ve done in TPV2 since there are so many things to control/tweak).
The BEAP thing that was bugging me was that just opening the file would prompt me for a name, so I just pulled it out. But just a matter of preference and workflow. And yeah for creating lots of files that’s a good way to go.
For the serialosc I’m on 10.11 so I’ll try doing that. I’ve never tried my arc on this computer, but my grid does work (though it would never reconnect if I unplugged it).
My Arc returned today! I haven’t had a chance to sit down and work out merging Rodrigo’s friction changes, but I’ve added in his awesome saturation, compression, and TPV2 random macros. Compression and “Jitter” (random filtering and amplitude) are buttons, while Wow + Jitter are a smooth control. Just pushed it:
Here are my current plans for a “final” version:
-Make friction variable and better.
-Add a switch to select which control is targeted by Arc knob 4.
-Add @Rodrigo’s name to the interface if he’s cool with it.
-Cleanup the interface now that the control set is pretty much final.
Other than that, I think that his improvements have taken it to a lovely place. It’s a really fun, versatile instrument.
So I was messing around with my OP-1 and I wondered how easy would it be to implement a “record head” in the same fashion that the play head is currently implemented - similar, to the manual record head function on the OP-1. I realize this departs from the original intent of Capstarc, just wanted to throw it in as something to think about.
Apologies for necrobumping this, but in case you never sorted this, one of the objects in the patch no longer works, at least in Max 7. If you go in and find the red/shaded out object, change grooveduck2 to groove~, leaving the rest of the arguments the same. Mostly leaving this here in case anyone else comes along in the future and has the same issue!
grooveduck2 should be in the standard Max library (including 7, as I built Capstarc with that). It’s an abstraction that adds envelopes to the sides of the groove~ playback buffer to reduce clicks. I just double-checked, and it’s also part of the standard Max 8 library. It should be located in:
~/AppData/Roaming/Cycling '74/Max 8/examples/sequencing-looping/audio-rate-sequencing-looping
No worries at all, this is excellent to know. I’ve upgraded to Max 8 in the meantime, and found the object help file in the location you suggested. The object also works if I go in and change it, i.e., it doesn’t go red, as it was when I was having issues initially. Don’t have time to check it with an arc right now, but I will when I get a chance.
Oh boy, I’m having a blast with this (new arc user here, greatly excited). A few questions though: is there a way to alter the sample length loaded? When I open the maxpatch in Max 8 (very new to Max, but trying to wrap my head around it), there is a box labeled “sample length”. But when I alter the number, it still keeps the value of 3456. something. Is the length of the sample played fixed forever? Do I need to adjust another box?
thanks a lot !
I figured out - I have to drop another sample on the tape deck. But, if somebody is reading - is there a way to change the units of loop length to seconds/milliseconds ?