[PD] Clock Division

[Peter van Haaften]

Greetings,

Thanks you all for the quick and speedy attempts to solve my issue!

Martin: Your approach to my problem seems very efficient. However, I am
having an issue with this solution where the last outputted tick always
plays late. I added a delay of '1' behind the bang that feeds into the
[spigot], which is not ideal but it generally improves the behavior. But,
when increasing the length of the period it acts up again and will play one
of the subdivided ticks late. I am curious to see this solution working
smoothly, as it is otherwise very simple and clear.

Roman: Thank you for the detailed information, and the links to your own
solutions. I think for the needs of this project it is not absolutely
essential that the metro interval changes as soon as it is received, but
certainly it would be preferable!

Christof: Your solution seems pretty solid, nice work! I am going to patch
it in to what I have, and I will attempt to modify it with the [tempo<
messages suggested here by Roman for improved synchronicity.

Thanks again for all of your solutions and advice. I'll post a finished
version of this patch around here when complete.

Best,

Peter

On Sun, Jan 10, 2016 at 1:02 PM, Christof Ressi <christof.ressi at gmx.at>
wrote:

> I was not aware that the new tempo method would affect metro times between
> bangs. Thanks a lot!
>
> > Gesendet: Sonntag, 10. Januar 2016 um 13:01 Uhr
> > Von: "Roman Haefeli" <reduzent at gmail.com>
> > An: pd-list at lists.iem.at
> > Betreff: Re: [PD] Clock Division
> >
> >
> > On Sat, 2016-01-09 at 15:07 -0500, Peter van Haaften wrote:
> > > Greetings,
> > >
> > > I am trying to find a simple and efficient way to divide quarter notes
> > > in Pd.
> > >
> > > The patch I am constructing is a kind of ostinato sequencer. There are
> > > four quarter notes, which should each by divided into 1-16 ticks (user
> > > definable). So, QT1 could be divided into 5 ticks, QT2 into 10, QT3
> > > into 1, and QT4 into 16. On the GUI, a series of 16 toggles allow the
> > > user to sequence and trigger a sample at each outputted tick.
> > >
> > > I was originally using the [timing.tempo] pdmtl patch as my clock. It
> > > largely works well, but there is a second component to this project,
> > > where a variable master tempo can change across time. With quickly
> > > shifting tempos, [timing.tempo] stumbles and occasionally counts
> > > incorrectly.
> > >
> > > Can anyone recommend a simple way to divide a clock in the fashion
> > > described above? Perhaps there is already a stable abstraction out
> > > there I can take advantage of?
> > >
> >
> > As I understand you, you want to be able to smoothly change the master
> > tempo while maintaining synchronicity among all subdivision. All
> > suggestions posted yet fail at that, since they simply send an updated
> > interval to the [metro]. However, [metro] takes the new interval into
> > account only _after_ it has finished the current interval. When having
> > many subdivisions, the tempo change takes effect at a different moment
> > in time for every subdivision and thus you get shift.
> >
> > I tried to tackle that problem in netpd in the [master] instrument (the
> > master clock of all sequencers). It uses [rh_metro] internally, which is
> > a [metro] replacement that does take into account tempo changes during
> > intervals. There is also a [master-poly] abstraction that generates any
> > integer subdivision tempo that stays in sync with the master.
> >
> > Check https://github.com/reduzent/netpd-instruments
> >
> > I was working on those things before [metro] was updated in Pd 0.45. It
> > now supports setting time intervals in many different units. There is
> > newly introduced 'tempo' method that let's change tempo _during_
> > intervals (which makes [rh_metro] from above obsolete). Checkout the
> > help of [delay], it covers all the details of specifying units and
> > tempo. I think using [metro] and changing tempo with 'tempo' is what
> > you're looking for.
> >
> > Roman
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160110/683bad14/attachment-0001.html>