Thanks Frank,

in fact I started already to study some other examples of yours (the list-rhythm one posted on this list) and I was thinking to look at some list stuff. I will soon look your example, thanks a lot.

I have a question about how to install the RTC library on MacOs Pd-extended: I made a folder called "my-pd-libraries" and added to the pd path (I do this always with max, so it's easy for me to know which libraries I have installed), I also put "rtc" in the "preferences->startup". Unfortunately now the pd-window shows only the loading of "GEM" at startup, the RTC seems to work, but the other libraries are not loaded. Which is the right way to install it? It would be nice also to have access to other libraries from the pd-browser; is there a way to do that?

btw, thanks a lot for porting the RTC-library to pd!

Libero

Message: 3 Date: Wed, 26 Dec 2007 20:01:10 +0100 From: Frank Barknecht fbar@footils.org Subject: Re: [PD] complex metronomes sequencing problem To: pd-list@iem.at Message-ID: 20071226190110.GG5459@fliwatut.scifi Content-Type: text/plain; charset="us-ascii"

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__