[PD] complex metronomes sequencing problem

Libero Mureddu libero.mureddu at gmail.com
Mon Dec 24 14:20:10 CET 2007


Hi,

On Dec 24, 2007 12:28 AM, Andy Farnell <padawan12 at obiwannabe.co.uk> wrote:
> On Mon, 24 Dec 2007 00:00:13 +0100
> "Libero Mureddu" <libero.mureddu at gmail.com> wrote:
>
> > 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.
>
> [moses] comes in when you want to create separate bars or phrases
> and attach copies or similar parts to them.
>
> Say we have a subpatch or abstraction that plays a phrase [melody1]
> and it takes a count from 0-127, and another phrase in [melody2] that
> is different but the same length. To have them alternate you can say
>
> [count 256]
> |
> [moses 127]
> |          \
> [melody1]  [- 128]
>            |
>            [melody2]
>
> [change]  is useful when you did an integer division or remainder
> with [/][int] or [div]. Even though the float output doesn't change
> in value it is repeated for every bang of the timebase. For example
> a counter mod 16 divided into four bars or four like this
>
> [count 16]
> |
> [/ 4]
> |
> [int]
>
> will output {0, 0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3}
>
> Adding [change] turns this into {0, 1, 2, 3] changing on every fourth
> beat.
>
> >
> > 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.
>
>
> This idiom is useful to make a n beat sequencer with settable
>
>    [unpack f  f  f]
>       |     |     |
>   \   | \   | \   |
>    [==]  [==]  [==] .......
>
> With all the left inlets connected to the timebase (remember to use a
> big [t b b b b b ...]. A 1 is output for each match of a list you can
> update. Use [sel 1] to turn that to a bang if necessary.
>

Do you mean something like the attached patch? Where the big [t b b b
b b...] should be placed and for what?
Thanks a lot,

Libero
>
>
> >
> > 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
> >
>
> There's a few things to browse here, including an early example of a signal
> domain composition with loops and synths;
>
> http://www.obiwannabe.co.uk/html/music/musictuts/Composition-000/Composition-000.html
> http://www.obiwannabe.co.uk/html/music/musictuts/Composition-001/Composition-001.html
> http://www.obiwannabe.co.uk/html/music/musictuts/Composition-002/Composition-002.html
> http://www.obiwannabe.co.uk/html/compositions/compositions.html
>
>
> > > From: Andy Farnell <padawan12 at obiwannabe.co.uk>
> > > Subject: Re: [PD] complex metronomes sequencing problem
> > > To: pd-list at iem.at
> > > Message-ID: <20071223205532.01f5fcb3.padawan12 at 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 at 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 at iem.at mailing list
> > > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> > >
> > >
> > > --
> > > Use the source
> > >
> > >
> > >
> > > ------------------------------
> > >
> > > _______________________________________________
> > > PD-list mailing list
> > > PD-list at 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
> > > ****************************************
> > >
> >
> >
> >
> > --
> > Libero Mureddu
> > Vanha Viertotie, 21 as 417
> > 00350 Helsinki
> > Finland
> > http://webusers.siba.fi/~limuredd/
> > http://www.myspace.com/liberomureddu
>
>
> --
> Use the source
>



-- 
Libero Mureddu
Vanha Viertotie, 21 as 417
00350 Helsinki
Finland
http://webusers.siba.fi/~limuredd/
http://www.myspace.com/liberomureddu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: deplor-new-003.pd
Type: application/octet-stream
Size: 720 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20071224/2ab014f6/attachment.obj>


More information about the Pd-list mailing list