Home › Forums › Feature Wishlist › Euclidean Sequencing
This topic contains 33 replies, has 9 voices, and was last updated by alien_brain 8 years, 6 months ago.
-
AuthorPosts
-
October 23, 2015 at 9:28 am #3336
Hi Majonymus,
thanks for the link to the code and your suggestion.
Unfortunatey it´s not that easy. I can´t use that code, because the code is under GPL and using that code would make the whole Zaquencer open source.Also, coming up with a working code is really the smallest problem (kinda weird, right?).
The bigger issues are with memory, and especially user interface. It´s always a balance between adding new features and keeping usability. I am very aware of this balance and try hard not to upset it by cramming too many features. Also as I wrote, with the current structure of the Zaquencer I can´t treat the individual drum instruments with different sequence lengths, only per track.So I hope you see there are many more issues than just getting a source code for a feature.
October 23, 2015 at 7:01 pm #3342I was thinking about this today while I was programming a hi hat rhythm. I held the hat button and turned the first encoder to fill all the beats, and thought it’d be great if turning the 2nd encoder filled just the off beats. But what if you turn the third??? Or forth? Maybe this is how we can fit in all those crazy rhythms? After all, the Euclidean rhythms could just be programmed in.
October 23, 2015 at 11:20 pm #3345Great thinking, I like this idea!
The nr of the turned encoder could always be the pauses between notes. (Encoder nr 2: place a note every second step, etc).
So simple, yet powerful.To not waste encoders, how far does this idea make sense?
8, 16? What to do with the other encoders?
Maybe also encode the offset in the row or so?
You might want to place every other note, starting with the 1st step, or also starting with the 2nd step…- This reply was modified 9 years, 2 months ago by Christian.
October 23, 2015 at 11:50 pm #3347Gah! I’m not going to give up on waveshaper mutes!
But… first row of encoders places 1 note then one rest, then two rests then three rests. Second row places 2 notes then a rest, then two rests then three rests. Third row places sets of 3 etc.
1st encoder on each row does a total fill. 5th through 6th encoder offsets by one step two step three step four.And this only works on the active sequence length. Though perhaps one could use the sequence start offset and end to employ offsets – freeing up the other encoders for alternative spacings.
Expect a detailed request for waveshaped mutes and step copies soon!
October 24, 2015 at 11:43 am #3350Maybe we should ask for everyone’s most used rhythms, and figure out which encoder makes sense. There are easily 32 important rhythms and their variations.
Like encoder nr3 could be:
..1..1..-..1..1..-..1..1..-
..1..1..
Encoder nr6:
..1..1..-1..1..1.-.1..1..1-
..1..1..
Of course, we will also have to fit in somewhere:
1..1..1.-1..1..1.-1..1..1.-
1..1..1.
And
1..1..1.-.1..1..1-..1..1..-
1..1..1.Is it possible to program it like this? I’ll bet if we ask everybody, those encoders will fill up fast!
October 24, 2015 at 12:20 pm #3351I think a key question is whether you can have a dedicated offset encoder to rotate the pattern across the sequence.The 32nd one?
it would be good to also be able to invert the pattern. From 01010 to 10101 or from 1001001 to 0110110 for example.
Current it is turn any encoder to the left you get 00000 turn to the right 11111. Maybe you could you the same mechanics for inversions of each encoder.
Personally I would rather see a mathematical layout of patterns than a selection of essential ones. Similar to how the ratchets and delays are arranged. 11111 then 10101 then 10010 then 10001 etc followed by 110011 then 110001 etc.
Horses for courses I guess
October 24, 2015 at 1:42 pm #3353Having an offset encoder would solve a major problem I just discovered. I was writing rhythms like this: first row of encoders= 8 different rythme starting on the 1, second row=8 rhythms starting on the 2, third row…(you get it)
Lots of really usable rhythms, but many were just offsets of others! This means a LOT more preset rhythms! I’d challenge someone to come up with ten good rhythms that weren’t already on the list!
And don’t be a preset hater there are no rhythms written that have never been done before. And you are in control of the melody.
October 24, 2015 at 2:25 pm #3354I’m operating under the assumption that in drum tracks we are still limited to the global track seq length – So can’t offset just be handled by the global seq step offset parameter? Or are we envisioning variable offset for each single drum instrument?
Kieran’s idea seems great tho. What if we had a lookup table that was indexed according to global seq length, ‘euclid offset knob’ and ‘euclid step knob’?
so this lookup table would have hundreds of entries, but would be first narrowed down by the value of global seq length. From here you would have available all patterns that distribute x amount of steps over the amount of steps defined by glob seq length as well as all offsets of these. now if we had a dedicated ‘euclid step knob’ you would turn it to sort through the lookup table by number of note-ons per seq.
say you set ‘euclid step knob’ to 3, and global seq length is 8. you’ve now narrowed the lookup table to only [x..x..x.] and all its offsets. from here just turn the dedicated ‘euclid offset knob’ to select one single final entry from the lookup table.
This makes sense to me, but i just woke up so maybe its nonsense lol, yall can decide
- This reply was modified 9 years, 2 months ago by bg.
October 24, 2015 at 4:44 pm #3356Rrrrr presets killed my father!
Hah no not at all. The mathematicals would need to be presets too. I just assume that its easier to reach every rhythm for every user from mathematical presets with inverts.@beau I think the goal is to be able to set a pattern per instrument yes?
Allowing a more controlled version of the random pattern by waveshape but using a lookup table.October 24, 2015 at 5:01 pm #3357Holy crap I’ve been doing binary math all day and my brain is going to melt. As far as I can tell, there are 28 different rhythms that you can create with 8 steps (if you can offset the beat,100 of them are doubles of these 28). All of the Euclidean rhythms must therefore be included in this set.
The unfortunate problem here is that these are only 8 step loops (spread over all 32 of course). If you want something like a clave rhythm, it would need 16 steps. But they are only meant to be a quick starting point anyway. You don’t want the thing to write the whole song for you, do you?
October 24, 2015 at 5:28 pm #3359Here are the rhythms. Which encoders they get assigned to… That’s another question! I’ve been grouping them by how many non-muted beats in a row.
1=note, .=mute
11111111, 1.1.1.1., 1..1..1., 1…1…, 1….1.., 1…..1.,
11……, 11….1., 11…1.., 11..1…, 11.1…., 11…11., 11..11.., 11.11…, 11.11.1.,
111….., 111…1., 111..1.., 111.1…, 111.1.1., 111..11., 111.11.., 111.111.,
1111…., 1111..1., 1111.1.., 1111.11.,
11111…, 11111.1., 111111.., 1111111.,Ok now I’ve got 31? Anyway, there may be mistakes, and this all depends on offsetting, which Christian hasn’t even confirmed is possible! Hasn’t even said he wants this at all actually! (And hopefully he is having a nice day off after just releasing the latest firmware!) But that’s what I came up with anyway.
Now to get REALLY annoying…
Christian, is it possible to define the loop point based on how far you turn the encoder (i.e. The first quarter turn gives an 8 step loop, second quarter gives a 16 step loop, third=24, fourth quarter=32)? This would be good for rhythms like 1..1..1.-.1..1..1-..1..1..-1..1..1.
October 24, 2015 at 5:42 pm #3360@Tommy, I think if we can use your idea of offsetting, every possible inversion of every rhythm should be included there. I could be wrong. Brain hurts.
November 3, 2015 at 1:23 pm #3431ah i see, i always get confused but the gnu licenses, Kieran idea seems good, i find some articles about this http://www.soundonsound.com/sos/dec14/articles/live-tech-1214.htm
i think mr stutter in the pd forum nailed it
http://forum.pdpatchrepo.info/topic/5188/euclidean-rhythms
its posted in a public forum so it shouldnt be a problem to use
Today I finally sat down to some pen-and-paper work to try and figure out what simpler way there might be to implement the algorithm, and I suppose my intuition turned out to be right, as I managed to distill the whole thing down to a handful of operations (and without needing to pregenerate a list, either!) Behold:
[inlet]
|
[+ A]
||
[% C]
|
[< B]
|
[select 1]
|
[outlet]does the trick, where integers B and C are the desired number of hits per ‘bar’ and the total number of beats per ‘bar’, respectively, and A is the ‘rotation’ or ‘offset’ applied to the rhythm. Then you feed the [inlet] with a metro-powered [f ]x[+ 1] counter, and you’ll get a ‘bang’ out every time the drum should trigger. Have attached an abstraction which performs the same.
- This reply was modified 9 years, 1 month ago by Majonymus.
November 3, 2015 at 1:33 pm #3433@majonymus – perhaps this could be an addition to the waveshape section if the code works -( yeesh I do go on don’t I ) to control mutes.
@kieran – and inversions!!
I’ve written a cunning way of including offsets were Christian to implement step copy – momentary copy/pastes offset in a direction.May 29, 2016 at 5:46 pm #4822How about just using an Euclidean Rhythm generator as another kind of wave for the WAVE GEN?
In the WAVE section we choose eucl.
GAIN chooses the value of the notes.
RATE is the number of pulses (Always a smaller/equal number than the Sequence Length).
OFFSET is offset as in here:http://www.groovemechanics.com/euclid/
The number of steps is the same as the Sequence Length.
This way we could easily use euclidean rhythms for everything that WAVE GEN can change.
- This reply was modified 8 years, 7 months ago by Francisco.
-
AuthorPosts
You must be logged in to reply to this topic.