#1

cccccccc

ccs for arc’s dials.

Send CC messages by value or LFO (current LFO types: sin, saw, square, random).

I made this little script because I have never used the midi LFO mode on my OP-1. TBD how much musicality it really ads to the synth, but at least fun in my tests so far. There are a couple things like this floating around for max and the modules but I am not good enough at computers to understand any of their code, so hopefully this is not super repetitive!

to do

soon:

-making the demo video i realized i really need a bypass toggle
-random is not random in the right way
-lock lfos to bpm
-pattern recording for knob mode
-exponential waveforms

long term:

-lfos as callable objects (rewrap as library?)
-assign LFOS internally or externally.
-envelopes triggered by amplitude of incoming signal assignable to LFO retrig or effects
-supercollider effects for audio

Requirements

– arc
– something to send midi ccs to

Documentation

Each dial of the arc can send either a constant value or an LFO. The last touched dial is highlighted on the display and its parameters can be refined on the norns in the following ways:

– encoder 1: lfo type
– encoder 2: set cc amp (range maybe better term?)
– encoder 3: set cc offset
– key 2: toggle lfo/dial mode
– key 3: change focus to next dial

Download

v1.0.0 - https://github.com/ypxk/cccccccc/archive/master.zip

15 Likes
#2

Can’t wait to try this with the digitone for some extra LFOs. Will just need to be able to select which cc’s though as the default cc’s in this script are not going to be super useful. Unless I missed something here

1 Like
#3

definitely let me know if you do and anything seems off! can only test on my op-1 which i think we can safely say is not the best device when it comes to ensuring midi compatibility…

1 Like
#4

the cc’s are working but it seems they are locked to cc 1 through 4. Id like to be able to assign them freely. If not in the working script what lines would I need to adjust to even pick my own hard coded 4 cc’s?

#5

wow, exactly the kind of oversight i would make. line 149 is where the ccs go out, you could add numbers to it to force it to use higher ccs, as long as they are in order.

md:cc(num+4,val,params:get("midi_chan")) -- ccs will be 5,6,7,8

i will add some params for independent cc numbers per dial soon as i get a chance to do some coding, thanks for pointing that out!

1 Like
#6

@Prnts fixed this real quick. i have no clue how many ccs there are, i put in 1-127. select desired cc channel from params, it should display the channel name on the ui. no other changes besides this for now.

let me know if that is a good fit, i do not know much about ccs on other gear!

#7

This is a great library. I used to use the hell out of the midi LFOs on my octatrack to ge around limited modulation on other synths.

There’s an interesting overlap here with my Arcify library, for instance I could see moving the LFO functionality up a level into a shared library that lets you apply LFOs to either Norns params or midi output.

6 Likes
#8

love this idea.
also, i’m not sure how complex the coding behind ansible’s “cycles” mode is, but the adjustable force/drag physics of it would surely be a welcomed addition to the growing arc library.

8 Likes
#9

that’s definitely the way i am wanting to do it. i actually tried writing it initially in a way that could just get bolted into arcify but i am not quite confident enough yet in my coding knowledge to trust that i could get it right. (case in point, i somehow made a cc script with no way to customize cc numbers)

i would be happy to assist on a library like that if someone could tell me what to do (:wink:), in the mean time i will keep working towards it on my own.

i actually looked up the code for this when i was starting off, but couldn’t work it out at all. i could probably with enough googling decipher the c, but i have really hit the edge of my understanding with this math wise. i spent more time on kahn academy for this than i did writing the script. i have hope that i will eventually know enough to do something like that but it’s so far off i’m sure someone else will have picked it up!

—

to update my original skepticism, happy to report the arc actually ads a lot to the op-1. really amazing how much more expressive it feels just using encoders that don’t click (plus mapping effect and synth params without changing the page…). frustratingly the op-1 midi lfo pitch param doesn’t seem to be able to change by values smaller than a semitone? but volume swells, woo!

2 Likes
#10

Let’s talk re: integrating these two. I’m happy to help you reverse engineer the LFO core code out into a new library, and then we can look at adding that to Arcify. The trick with this stuff is usually just to break it into a bunch of small parts so they can be used in any combination.

The force/physics stuff sounds awesome- I haven’t used Ansible. That’s a little out of my comfort zone too but it’s worth a look.

As far as setting midi CC numbers, I think they would work well as number type params with a min of 0 and max of something like 100-127. My experience is just about any number variable in a Norns script can be “parameterized” with just a few lines of code. I can probably dig up some examples, there might be one in the studies?

2 Likes
#11

i did get that fixed (though just reading this i have learned i need to add in 0), just mentioned it to illustrate the lack of foresight i worry about bringing to something else, haha

i will take a swing at separating the lfo stuff out soon and send you a PM, will be a good excuse for me to learn how branches work on github. thanks!

#12

Hi, this is pretty excellent, thank you! I was just wondering if you or anyone know of a way to make the LFO sound more continuous when the encoder is turned. As it is currently, the LFO seems to wait until you stop turning before it updates to the new setting. Clock synchronization would also be nice… internal or external. Thanks again! So mesmerizing.

1 Like
#13

thanks!

i do not, unfortunately. it drives me insane too and i’m definitely hoping to figure it out eventually, it’s another weird math issue that i probably could have solved if i didn’t get a c in high school geometry a decade ago and never thought about it again. i know @Justmat is working on a similar feature (not sure if it’s on the lua side), maybe he has figured it out?

from what i understand, the problem is that the way i am calculating the sine means that it changes by large amounts between small variations in speed, which sometimes puts it not even near the prior value at all. to fix that i added the ‘waiting’ you noticed (actually a concept called ‘linear interpolation’ that i discovered while making this thing), so that it would slowly adjust to the correct point instead of just jumping there right away. but it’s not good at all, and literally every other lfo i’ve used has not had that problem, so there must be super easy way to fix it.

clock sync is coming as soon as i get a chance to sit down and do it though, super easy to add. thanks for the reminder, i will push it to the top of the list.

1 Like
#14

I’m working on some arc lfo stuff too. I’m interested in the physics inertia thing and know enough to be dangerous so I’d like to explore how to implement this in a library.

4 Likes
#15

That would be a no. In fact, after you shared cccccccc I pretty much started over, using your LFO work as a jumping off point. :sweat_smile:

4 Likes