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?
Thanks !!
Peter
Hi Peter,
I think I know what you're after and did a quick patch (using my [cmetro] abstraction). The patch is not pretty but it works quite well and tempo changes are safe. Let me know if it works for you.
Christof
Gesendet: Samstag, 09. Januar 2016 um 21:07 Uhr Von: "Peter van Haaften" petervh@gmail.com An: pd-list@lists.iem.at Betreff: [PD] Clock Division
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?
Thanks !!
Peter_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sorry, there was a stupid mistake in my patch! I forgot the [f] objects beneath the number boxes for the quarter notes. I fixed it, now it's safe to change the subdivisions dynamically while playing.
Cheers.
Gesendet: Samstag, 09. Januar 2016 um 23:47 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Peter van Haaften" petervh@gmail.com Cc: pd-list@lists.iem.at Betreff: Re: [PD] Clock Division
Hi Peter,
I think I know what you're after and did a quick patch (using my [cmetro] abstraction). The patch is not pretty but it works quite well and tempo changes are safe. Let me know if it works for you.
Christof
Gesendet: Samstag, 09. Januar 2016 um 21:07 Uhr Von: "Peter van Haaften" petervh@gmail.com An: pd-list@lists.iem.at Betreff: [PD] Clock Division
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?
Thanks !!
Peter_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list_________________________________... Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Something like the attached patch?
Martin
On Sat, Jan 9, 2016 at 3:07 PM, Peter van Haaften petervh@gmail.com 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?
Thanks !!
Peter
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
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@gmail.com An: pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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@gmail.com An: pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Peter
I've just pushed my [ndmetro] to moonlib github repo ( https://github.com/MetaluNet/moonlib). I'll soon publish an update for moonlib to deken (but at the moment I can't build for windows).
I think this tool could help you, I wrote it in 2005 for similar purpose. It allows continuous tempo change and can decompose a virtual master tempo in whatever measure you want (and it keeps in sync in every circumstance).
Cheers
Antoine
2016-01-10 20:09 GMT+01:00 Peter van Haaften petervh@gmail.com:
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@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@gmail.com An: pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hello, maybe you want to try [list-tuplet], it's an abstraction I've wrote for playing something else than quarter notes, but it can play them as well:
http://megalego.free.fr/pd/patko/list-sequence/list-sequence.zip
Le 09/01/2016 21:07, Peter van Haaften a écrit :
I am trying to find a simple and efficient way to divide quarter notes in Pd.
-
Antoine Rousseau -
Christof Ressi -
Martin Peach -
patrice colet -
Peter van Haaften -
Roman Haefeli