this is probably out there, but I have no idea what to look for. basically I need a module of which outputs a value that’s correlated to the amount of occurrence of note-ons or open gates. say I play a lot of short notes (in a given amount of time), then I want this module to output a small value, say I play mostly longer notes (in a given amount of time) then I want it to output higher values.
say in time x I have 50% open gates, so I want the output value be 0.5 (float), say in the same time I change my playing to mostly play shorter notes, I want the output to change accordingly so it outputs 0.4 or 0.3 instead.
the time window should either follow a certain logic, or be cv controllable. the idea behind this module or functionality, is that I want to hook an cv-controllable adsr to this, which then leads to some kind of adaptive auto-adsr, it changes its envelope times according to your playing style, if the module notices you are slowing down, it will adjust the envelope times. not sure anymore if this was done already, but I have no way of finding out, I mean what should I look for?
anyone got an idea which logic module or math module would get me towards my goal here?
edit: ok nvm, I think I found something useful in an external prgrammable fx processor, a module called “rms” and it basically lets me choose a time window and it will calculate the average energy in this window - the window size is “modulatable” so, time to experiment.
I haven’t thought about modules at this point, but I am confused by your requirement.
Are you looking to measure note lengths - long vs short? or note density - continuous sound vs lots of rests? They are orthogonal (not related). You can have a continuous stream of very short notes where the on/off ratio is high. Or you can have very long notes with even longer gaps in between where the on/off ratio is low.
good questions, I think I’ll need both. but first I need to make sure that when I play 16th notes, the attacks and decays go to a level where it makes sense, and if I start playing slower, the attack and decay should increase accordingly. maybe it’s smarter to define the goal first, which is: I want to make sure that my adsr gets snappy when it detects me playing lots of short notes, or many notes in succession, and when I hold notes longer it should adapt as well. the problem formulation is not easy. maybe in general terms, I just want an adsr that correlates with my playing, whatever the parameters are in the end, but you are right, there needs to be differentiated between time spent with gate on vs gate off, and total gates (triggers) executed in any given timeframe. maybe the values should intermingle and intermix somehow as well.
doesn’t this sound like a cool idea generally? I mean we use gates, v/oct modwheels and even aftertouch in our midi, but we never deduced any control signals from other derivatives of our playing so far, which in this case is "how many notes are you playing? are you rather playing long notes or short ones? these should be parameters that we use in our music, it could help a lot with vivid and interesting modulations. especially for an adsr in my case.
I’ll patch something up and likely post an example mp3 later if I have some success with the rms module.
so what you see in this patch is the gates from the midi module (coming from ableton live) going to output 17 which is the external RMS module, which essentially calculates the average energy of my gates, which seems to affect total open gate time over a specified time-window, I specified 1000ms for this example. what comes back you can see on the scope, this then goes into the stock adsr (still on rack v1 as I get crashes with v2 and midi map module) the vca’s are just for finetuning the output of the RMS. notice the correlation between how many notes play in this sequence. sounds kinda useful or intriguing, doesn’t it?
also notice how the times decrease once I program more gaps between the notes played. isn’t this rather useful? wait a minute. why so complicated, a lag generator might just do the same thing- d-oh
A module of that kind will always lag behind your playing. I think you can achieve better control by using a MIDI volume pedal or an MPE controller or simply use MIDI velocity to speed up or slow down the attack and the release of an envelope.
this is how I have been doing this so far, I just wanted to automate this even though it will lack behind, the logic involved might be interesting if done right, or the algo used could be used musically if you know what I mean. one could even use machine learning or musical play-style habit tracking, there’s no limits to building a nice AI for this then it gets really interesting. on day hal9000 will take over though
I think you want to measure two different ratios and convert them to CV
Frequency (notes per unit time)
The Nysthi clock multiplier can do this. I don’t know if it measures the instantaneous frequency based on the time interval between each gate/trigger, or if it does some kind of averaging. If instantaneous I imagine you could use a slew limiter to sort of average out the signal.
The simple patch pictured below outputs CV based on the rate you press the top PULSES button.
Average voltage within a given time frame. Not sure what module would do this, but it ought to be simple to build. The gate signal varies between 0 and 10V. Simply sum the voltage of each sample and divide by the number of samples to get the average voltage, with an output value ranging between 0 and 10. Or count the number of high 10V samples and divide by the total number of samples to get a value ranging between 0 and 1.
I imagine you would want a rolling average that buffers each sample value within a given computation. Each time a new sample is added, the oldest sample is dropped.
I use a variable time averager in lock mode
but in the case of the CMD is set to 1 points (meaning that compute in 2 pulse and after locks and you need a reset for a new computation)
I have other modules with more free averaging in 3 and 5 points (clockabel delay, bitshifter, metaAArdvark lfomultiphase)
