hi,
I'm about to embark on an external-building exercise involving designing and building a timing system and looping envelope editor inspired by the looping-envelopes paradigm that Ableton Live uses.
Basically what I want is the ability to subdivide time into 3, 4, 5, or 7, to any depth, and use this to control looping movement along a function; and I want to be able to do this multiple times simultaneously without losing sync. As a very simple example, I want to be able to have a triplet-based loop that is 1 bar along against a quarternote-based loop that is 1.5 bars long, and have both loops synchronised every three bars. The bar lines for each would come at the same time, but the first would have 3 beats in the bar, and the second would have 4 beats in the bar, and the first loop would repeat three times for the second loop's twice; at which point they both start again at square 0. If anyone's done any kind of polyrhythmic stuff using Live they'll know what I'm trying to say I hope :)
Against this looping grid, I want to be able to both rapidly set blocks of time to a flat value (a la ctrl-2 ctrl-2 ctrl-2 click in Live), and to zoom in on a small section and micro-tweak values (ctrl-1 ctrl-1 ctrl-1 click in Live), and (this may have to come later) be able to switch to an interpolating graph view and edit that instead of being fixed to discrete units of time.
Are there any built-in objects or externals I should be investigating before or even instead of embarking on this exercise?
The specifics of it are fairly important to me -- what I basically want to be able to do is control multiple arpeggiators with non-fixed time intervals on each step, all lined up so that I can build multiple layered polyrhythms that maintain synchronisation. And it needs to be easy to edit in a live situation.
(I am perfectly willing to and capable of duplicating the Ableton Live interface if needs be in this respect (I'm much less interested in the Live audio engine than I am in the interface) -- I already have a broken prototype I built in C++ for a VJ toy based around the WinAmp AVS source code, which rendered abstract visual elements and transitions against a rigid metronome capable of polyrhythmic sequencing -- visual techno, if you will. But it was based on a fairly unsuitable GUI library which I had to heavily modify, and then I went and reinstalled my system without backing up the modfications (as you do), and thus it is all gone.)
So, (apologies for the mammothosity of this email), I'm looking at at least two new objects. The first, we'll call it TimeMachine, will be based around a high-frequency timer triggering at some common multiple of 2, 3, 5, and 7 times every beat. The second, maybe call it LoopingEnvelope, has to decode that raw number and decide based on envelope data whether or not to send out a new message of the form 'float float' that will get passed on to a _line_ object.
How best then to get the timing messages from TimeMachine to LoopingEnvelope? Is it ok to send a bajillion messages every second between objects, or should I be looking at some kind of hacky non-PD shared-memory style technique that forever ties LoopingEnvelope to TimeMachine? I figure I can't just disconnect TimeMachine from LoopingEnvelope and build LoopingEnvelope around delays because over time the start points of multiple LoopingEnvelopes could very well drift apart, especially if triplets or seven-ets start getting involved.
Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote:
So, (apologies for the mammothosity of this email), I'm looking at at least two new objects. The first, we'll call it TimeMachine, will be based around a high-frequency timer triggering at some common multiple of 2, 3, 5, and 7 times every beat. The second, maybe call it LoopingEnvelope, has to decode that raw number and decide based on envelope data whether or not to send out a new message of the form 'float float' that will get passed on to a _line_ object.
I don't see what TimeMachine can do that [metro] wouldn't be able to do? [metro] is capable of high-frequency triggering, and can fire in multiples of every (sensible) control frequency or period.
To really get the full timing resolution of [metro] you will not want to use the [line~] object however, but the [vline~] object.
Doing the polyrhythm stuff is quite easy with builtin Pd objects and it's also more flexible for users, who can directly change the internals without having to recompile. Pd users often like to do that.
An example of what I mean is a little polyrhythm-testpatch I did some time ago using only builtin objects (including [list] so pd-0.39 required as well as [list]-abs). [list-rhythm] simply is a little counter, that counts in intervals you send to its second inlet. So sending e.g. "2 2 1 3" will make list-rhythm count like this: "0 1 0 1 0 0 1 2" and repeat that.
Combining many list-rhythms can create interesting polyrhythms, whose patterns can change on the fly. See simple-test.pd for an example.
Frank Barknecht _ ______footils.org_ __goto10.org__
hi damian
"Damian Stewart" damian@frey.co.nz wrote:
I figure I can't just disconnect TimeMachine from LoopingEnvelope and build LoopingEnvelope around delays because over time the start points of multiple LoopingEnvelopes could very well drift apart, especially if triplets or seven-ets start getting involved.
i think, you wouldn't get any problems with drift, if you are sending real 32bit resolved floats to [metro], e.g.
[1 (
|
[/ 3]
|
[metro] (for a triplet)
though i didn't test it yet. the (big) problem is still, when you'd like to change the pattern during a period, since you mentioned live situation (how to resync then?).
as you mentioned, there are two approaches to polyrhythmic stuff:
desired grids 2. a metro with a fixed period and then calculate the rest and do it with other metros or delays and sync them at certain times.
i'm still unsure which way is better. would it be against the first solution, if i have quite a lot of receivers (in terms of cpu load)?
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de