^^ crow: max + m4l devices (currently testing refactor!)

[dan_derks]

@benjaminz + @emsahp!
here’s a “knob-to-cv” device that has passed 30 minutes of modulation testing, would love your eyes on it. if y’all dig it, it will be brought into the main ^^outs device.

testouts.amxd (57.4 KB)

i ran envelope lanes that looked like this:

…and it was really fun! more importantly, no crashes!

when you load up, the device will look like this:

choose an output from the out dropdown in the top left corner and if you wish to clip the range, adjust min and max to taste.

smooth

i think what was happening with the original device is that I was trying to provide as high a resolution as possible, but between the scheduler and what ended up being insane traffic to crow, knob modulation was super unstable (you could crank it with a midi cc fine, which was how i was originally testing, but that didn’t turn out to be the primary use-case in practice).

so, what i’ve done is limited the number of messages sent to crow and leveraged crow’s internal slewing as a way to make up the difference. resolution seems totally workable, but you may find that certain scenarios require different smooth times. for example, i found that 200ms works nicely for fast-moving data, but 1s was required for those nice long swoops.

anyway, thanks for the patience and persistence, y’all. hope this works!

[benjaminz]

ahh thank you!! can’t tell you how excited i am to play with this. will report back!

[dan_derks]

new ^^ins, please test <3

cleaned up + formalized @emsahp’s feedback:

v/8 + trigger: cv-to-note

• input 1: v/8 cv. low sets which midi note 0V equals, high sets upper bound of midi note range.
• input 2: triggers (i find the fourth duration on kria works well), will fire off the v/8 cv as a midi note. crows will also pulse

nb. press more > to map your v/8 cv and modulate Live parameters in parallel!

streams: cv-to-cc

tons of modulation routings!

• d: depth of cv-to-cc
• o: offset the scaling of received cv values
• s: slew the cv-to-cc conversion, to soften clickiness/steppiness when mapping to audio parameters (like panning, filter cutoff, gain, etc)

press more > to get six total channels from crow’s two inputs (1 and 2). each of the white 1's and 2's can be changed. so you can have three 1's and one 2, for example.

seems super stable on my end, would love a bit of real-world testing before release, though. any takers?

^^ins.amxd (1.5 MB)

[jlmitch5]

looks awesome. I can this weekend (either before or after your release…a bit swamped with stuff until then)

[jlmitch5]

@dan_derks

note responsiveness (as in number of dropped notes, midi jitter, etc.) at low sample rates (the problem I was having before) seems v good! I can set the trigger quite high and it stays locked in. If I really load up stuff and make the clock high, I can get some lag of the notes for a brief second messing with abletons interface (i.e. scrolling the device bottom bar with lots of lfos and stuff), but it’s definitely tighter than it was. Can’t remember if I tested the old one with the high sample rates (which causes a lot of midi jitter in ableton for me), but I’d say on where this is at now.

the note length generated seems very small…you have to zoom in a lot to see it on the transport. I’m not sure if that will cause an issue or not. could be nice if the note length responded to the pulse length rather than triggering a static note length, but no idea how difficult that would be (current behavior is fine)

the low and high controls seem to work as expected, clamping the values to the range.

DOS (atleast while in note mode) seems broken. I tried to midimap a param to a 0…5v offset knob and set low/high to 0…5v. I could not get that to map to a knobs CCW…CW state at any DOS values (It did some like turning things was doing something to affect the range, and I could get the voltage to affect the param somewhat…think there may just be some math issues there.

Random thing…it does seem like the gate length of my pulse to in 1 affects the pitch slightly to in 2. Larger pulse values seemed to be a semitone up (and I could dial in a pulse that would randomly switch between the two notes. maybe this is a hardware thing…some leaking of the pulse voltage from in 1 onto in 2?

[dan_derks]

hey john, thanks so much for testing!

@jlmitch5

note responsiveness (as in number of dropped notes, midi jitter, etc.) at low sample rates (the problem I was having before) seems v good! I can set the trigger quite high and it stays locked in.

awesome, so glad to hear we got this solved

@jlmitch5

some lag of the notes for a brief second messing with abletons interface (i.e. scrolling the device bottom bar with lots of lfos and stuff)

yeah, unfortunate side effect of Live’s de-prioritization of raw data (vs audio). crow and the m4l devices are 100% data-driven and can manifest the hiccups of Live’s scheduler. it’s sorta the same thing that happens when you load a few of the built-in LFO device, for example – the redraw is de-prioritized as you load each one and will hang for a sec. from what I can tell, data to/from crow is essentially as important to Live as redrawing that LFO window

@jlmitch5

the note length generated seems very small […] could be nice if the note length responded to the pulse length rather than triggering a static note length

the anatomy of the patch is pretty much using a change event to sample the current input value and execute a note. i couldn’t see an obvious path toward sorting out what’s a rest vs what’s a long pulse (especially in the 1/0 paradigm), so currently the [makenote] has a default 10ms duration. but you can throw Live’s note length device in after and dial in your preferred length!

@jlmitch5

DOS

having a hard time repro’ing the trouble you described…but perhaps it’s worth mentioning that any slew you add is going to reduce the dynamic range of the control? here’s a quick test of a cv-to-note-to-map that is sending 0-5v map to a 0-5v knob, with various slewing.

@jlmitch5

it does seem like the gate length of my pulse to in 1 affects the pitch slightly to in 2

reading this, it sounds like you’re sending pulses to 1 and v/8 cv to 2? the device only supports v/8 in 1 and pulses to 2. in the intended config, i wasn’t able to repro this with ansible running kria. i got expected pitches with every length excepting the super shortest.

feel free to reply here or github, thanks so much for the help!!

[emsahp]

Hey @dan_derks I’m trying-testing everything since two days now
Great improvement on both ^^ins and ^^testouts !! really solid and reliable
No more crow freeze on my side
^^ins work great even with a pan knob (slew is great when you do some bold S&H panning action )
The new ^^ins interface is crystal clear and it’s super nice to be able to route both 1 and 2 to multiple destinations and at different ratio
^^testouts finally able to rec some wired automations on the fly without any issues !!

Thanks a lot for all your work !!

[jlmitch5]

thanks for all the updates @dan_derks all makes sense and sounds good. i’ll test the DOS stuff again soon, maybe there was something weird on my end!

@dan_derks

reading this, it sounds like you’re sending pulses to 1 and v/8 cv to 2? the device only supports v/8 in 1 and pulses to 2. in the intended config, i wasn’t able to repro this with ansible running kria. i got expected pitches with every length excepting the super shortest.

this was probably just an error on my part typing it…it was most definitely working, so I had to have had it the right way hah.

---

I’ve noticed one issue with ^^command_center…it seems to “eat” druid output, the same as if you had druid up in two terminals (it’s like you’ll sometimes get a chunk of whatever you print but I guess it will only print to one or the other and it’s a race condition or something determining which it prints too). Thinking about it, it might be better fixed on the druid side, and I can file an issue there depending on what you think

[Galapagoose]

@jlmitch5

it seems to “eat” druid output

I don’t think 2 applications can talk to the same serial port and both reliably receive every message. The OS needs to know when the data has been ‘read’ (and thus delete it from the buffer).

I think we should disallow multiple programs to connect to the same serial port. Perhaps there is a way ^^command_center could be extended so you don’t need druid as well? Why are you using both simultaneously? Is it to view the output (we should just print unmatched messages to the Max window), or is it to send text commands to crow (we could allow a sendable code box like ^^derwydd).

[jlmitch5]

Why are you using both simultaneously?

I was using the terminal to test changes to a var and m4l (^^comand_center/^^macros/midi notes) to sequence the var values with midi notes on the ableton timeline of the song I was working on once I figured out what I wanted them to be.

@Galapagoose

I think we should disallow multiple programs to connect to the same serial port. Perhaps there is a way ^^command_center could be extended so you don’t need druid as well? Why are you using both simultaneously? Is it to view the output (we should just print unmatched messages to the Max window), or is it to send text commands to crow (we could allow a sendable code box like ^^derwydd).

when I’m working in ableton, I think I could probably get along with staying completely in there…I could have done what I was doing in the terminal with ^^derwydd (which uses the serial connection you set up with ^^command_center)…just did not realize that would fix things, but understanding the serial connection thing, I think it would have. I’ll try that next time and see how it fits in the workflow.

[benjaminz]

works flawlessly! crash-free. experimenting now

[autreland]

a feature request for @dan_derks

it would be incredible if ^^jf_synth could assign a midi track to each individual voice—my current dream is to nearness multi-octave 808s into dedicated stereo spaces!

[dan_derks]

thank u for the ping! a shared dream, for sure.

i’ll take a peek at this again — with the early firmware, addressing too many single jf voices caused crow to crash. a good task for this week

[autreland]

amazing—thank you!!

i’d be happy even if i was limited to two or three at a time

[cosmicsoundexplorer]

@dan_derks Just jumped into Crow and Max territory, Its amazing!
One thing I couldn’t set up properly without sacrificing 2 channels of crow was getting a gate to trigger on every midi note. What I’m trying to achieve is playing JF and having a gate trigger another JF to do envelopes/modulation for my filters and FX. Would it be possible to add a midi note to gate out to the ^^outs device? Unless there is a better method that Ive overlooked?

[dan_derks]

totally possible – i’ll just change the v/8 mode to notes and have you select whether you want to send the note-on as a pulse or the note as v/8 cv! and then for both, you just use ^^dual

great idea, thank you!

[cosmicsoundexplorer]

That would be fantastic Thank you!!!

[tyleretters]

I want to use crow to trigger a gate (specifically on Intellijel Dual ADSR, if it matters?).

Is this a job for [crow.ar] ? Attack 0, Decay 0, Peak 5v?

[dan_derks]

sending "output[x]( pulse(sec, V, pol) )" as a message could do as well!
so, "output[2]( pulse(0.05, 5.) )" for a (default positive) 50ms rise to 5V from output 2.

but the [crow.ar] packs up all the helper stuff nicely (thanks to @voidstar)

[tyleretters]

Awesome, thank you. And 5V is the right number? Read a lot of different stuff…