Hi Andy,
thanks for your message, it clarified a lot my problem. In fact I need a "time aware" synchronous system, could you send a basic example of that? I can guess that I need a metro plus counter and different [mod]s, but I dont get how to use [moses] and [change] for that.
In another attempt that I did, I made a select with many arguments, each one representing a "playing point". Unfortunately it seems impossible to send a list of arguments as message and set dynamically all the values for set (at least I was unable to do that). [multiselect] that should do that is broken.
Do you have an example of the sample timing based idea that you mentioned? In fact, the compositions I'm working on are not longer than 4-5 minutes.
Thanks Libero
From: Andy Farnell padawan12@obiwannabe.co.uk Subject: Re: [PD] complex metronomes sequencing problem To: pd-list@iem.at Message-ID: 20071223205532.01f5fcb3.padawan12@obiwannabe.co.uk Content-Type: text/plain; charset=US-ASCII
If you have two or more independent metronomes that form a polyrhythmic relationship then stopping them will lose the relationship. Each will begin its timing series from the same "zero point".
A synchronous system is probably better if you want to start and stop the composition at arbitrary points and have it resume.
The general problem with a synchronous system is that the smallest timing resolution is the division of the master clock at all points.
But there are also two quite distinct approaches to synchronous sequencers in Pd having different properties.
One is based on bangs and built from many subsystems that each hold their own state. These "state aware" subsequences use a local counter and a [select] object. The advantage here is that if you stop the master bang message source, each will remain in it's last state until new bangs start to flow. The disadvantage is that no part of the system is "time aware", so you cannot jump forwards or backwards a number of beats to see what the sequence is like without explicitly going through all steps.
The second kind is "time aware". Instead of sending bangs you send float messages which represent the current time. You can use combinations of [moses], [mod], [change] and simple arithmetic to make subsystems behave in different ways. You can jump forwards, backwards or pause the sequence in any way you like.
If you want sample accurate timing you can try an interesting approach that Chun Lee and I have both experimented with, composition entirely in the signal domain. You start with a very slow [phasor~] or [vline~] and calculate all sequence timings using a mixture of [wrap~], [rpole~]/[rzero~] and [min~]/[max~] to constrain, integrate or differentiate the timebase. This has some really nice features, like being able to warp the timebase and get swings or extremely smooth tempo changes. You can also warp parts independently and have them converge on some point in the future with sample accuracy (like spinning back a sample table and having it land exactly on the beat... which you cannot do in any other software afaik). The disadvantage to this is that you're limited to songs of less than about 5 mins because of rounding errors.
On Sun, 23 Dec 2007 21:08:08 +0100 "Libero Mureddu" libero.mureddu@gmail.com wrote:
Hello to everybody!
I have a problem and I'd need that someone could point me at least to the right approach to solve it.
Let's say I have three simple metronomes running, built with metro. Their speed is 1000 1001 and 1002 ms (in my case I have 88 of them, running at different speeds). I'd like to have the possibility to:
a) keep the proportion constant between them and change the global tempo (i.e. 100, 100.1, 100.2 etc) b) I'd like to stop and restore the metros with their right time differences: if they start at the same time (from the same bang), they create a particular net of rhythms, that I'd like to control, analyze and change. I'd like to be able to stop them at a certain point and restart from another but keeping the same rhythmic combination.
I know that this exist and is called sequencer :-) But I want to control this using pd but I don't know really how to do it, and also this is the simplest example: some parts could start at a certain point a change towards a different tempo in a certain time, having different dynamic according to a particular pattern etc. etc. So I think pd would a good platform to implement this.
I was thinking to have a global metro running at 1 ms speed with a counter that reads many different arrays: the first of 1000 values (the first "1" and the other values "0"), the second of 1001 values and the third 1002 values and so on.
But this works if I decide in advance the metros speed and leave it fixed, but I want to be able to modify the speed and still being able to restart, stop etc. Other idea was to have many qlists, but again, a note approach would give the problem of sync between the different notes.
Any help appreciated!
Thanks, best regards and
Merry Christmas!
Libero
-- Libero Mureddu Vanha Viertotie, 21 as 417 00350 Helsinki Finland http://webusers.siba.fi/~limuredd/ http://www.myspace.com/liberomureddu
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Use the source
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://lists.puredata.info/listinfo/pd-list
End of PD-list Digest, Vol 33, Issue 163
Hallo, Libero Mureddu hat gesagt: // Libero Mureddu wrote:
thanks for your message, it clarified a lot my problem. In fact I need a "time aware" synchronous system, could you send a basic example of that? I can guess that I need a metro plus counter and different [mod]s, but I dont get how to use [moses] and [change] for that.
In another attempt that I did, I made a select with many arguments, each one representing a "playing point". Unfortunately it seems impossible to send a list of arguments as message and set dynamically all the values for set (at least I was unable to do that). [multiselect] that should do that is broken.
Do you have an example of the sample timing based idea that you mentioned? In fact, the compositions I'm working on are not longer than 4-5 minutes.
The signal based approach Andy mentioned is in fact a very old one: Old voltage controlled analog synthesizers were sequenced like that. Miller's book has a little chapter on that "Audio signals as control" at http://crca.ucsd.edu/~msp/techniques/latest/book-html/node47.html Its advantage is that smooth tempo changes are possible. A disadvantage is, that syncing is a bit tricky because phasor~'s phase inlet is not sample accurate, but operates on block sizes. And you need to take great care when converting from control messages to signals, so often you're tied to do signal sequencing all the time.
Another approach besides constant metro bangs and a global counter is working with so called inter onset times. IOIs are the delay times between two events. If the IOI between two events is 0, they happen at the same time, if it is > 0, one comes first, the other later. [qlist] works with IOIs but you can also build chains of IOIs yourself using [delay] or [pipe].
With IOIs you can build irregular metros. The basic idiom there is to "drip" or "serialize" a list of IOIs, either using [list-drip] from [list]-abs or manually using variations of the idiom in list-help.pd.
So assuming you have an IOI-list like this: "2 2 1 2 2 2 1", where each number is the IOI in beats. Drip this list one by one into a [* 200]--[delay] where 200 is your beat length, and feed back the delay to list-drip. You get a nice little pattern, which you also can change through simple messages. Then the nice things come with the fact, that you can do various list operations on the lists you use as patterns, like reversing them of selecting random elements. A lot of this stuff is already implemented in the Rhythm abstractions of the Realtime Composition Library (RTC-lib). IOI is called "entry delay" (ED) time there, but it's the same concept.
See attached patch for a simple example.
Ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
Libero Mureddu