Re: [PD] Rewriting a unified phasor / metro object for reading tables
On Sam, 2014-03-15 at 09:43 -0400, me.grimm wrote: > I noticed though, is there a reason why it works on 0.45.3 and not > 0.43.4-extended? Oh, yes. You're right. I got confused, because the equation to determine the current intra-step position for [vmetro] (now [rh_metro]) was assuming Hz and s, but most Pd classes expect ms. That is why I used a new feature introduced in 0.45 that lets you define your own timing unit for most timing related classes. I forget to reverse that when it finally worked. I worked some more on [rh_metro], fixed some bugs (re-entrency did cause Pd to hang) and put it on github.com. You'll find a slightly updated [rh_phasor~ ], which still uses [rh_metro] internally, here: https://github.com/reduzent/netpd2-patches Enjoy! Roman > On Sun, Mar 9, 2014 at 5:39 PM, Roman Haefeli > wrote: > (I believe this might rather belong to pd-list instead of > pd-dev) > > On Don, 2014-03-06 at 18:56 -0500, me.grimm wrote: > > Roman, > > > > >> wrapping points. The only drawback compared to [phasor~] > is that > > the > > >> latter allows to control the frequency with a signal and > the > > >> [metro]/[vline~] based phasor obviously doesn't. > > > I never did quite figure it out but how do you do more > advanced things > > with [vline~] such as updating/increasing ramp speed mid > ramp? > > > Frankly, I often find myself struggling with those kinds of > problems. > > > >> I'll be glad to help you build the [phasor~] replacement > that has > > an > > >> additional bang outlet, if you need it. > > > > Are you saying this is possible with just metro/vline~ > combo? I would > > be curious what that looks like if you did build it > > > It wasn't as easy as I initially expected it to be. I already > had a > [metro]-like abstraction that can do intra-interval tempo > changes. > However, I figured it was buggy (it worked only for the first > tempo > change within an interval) and had to redo it. That was the > most > difficult part. Combining it with [vline~ ] to make a > [vphasor~ ] with > extra bangs at each wrapping point wasn't as hard (at least > not with its > current limitations). > > Check attachment. > > Roman > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > -- > > m.e.grimm | m.f.a | ed.m. > megr...@gmail.com > _ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Rewriting a unified phasor / metro object for reading tables
hey roman, thanks for that! I noticed though, is there a reason why it works on 0.45.3 and not 0.43.4-extended? I could not tell off hand m On Sun, Mar 9, 2014 at 5:39 PM, Roman Haefeli wrote: > (I believe this might rather belong to pd-list instead of pd-dev) > > On Don, 2014-03-06 at 18:56 -0500, me.grimm wrote: > > Roman, > > > > >> wrapping points. The only drawback compared to [phasor~] is that > > the > > >> latter allows to control the frequency with a signal and the > > >> [metro]/[vline~] based phasor obviously doesn't. > > > I never did quite figure it out but how do you do more advanced things > > with [vline~] such as updating/increasing ramp speed mid ramp? > > Frankly, I often find myself struggling with those kinds of problems. > > > >> I'll be glad to help you build the [phasor~] replacement that has > > an > > >> additional bang outlet, if you need it. > > > > Are you saying this is possible with just metro/vline~ combo? I would > > be curious what that looks like if you did build it > > It wasn't as easy as I initially expected it to be. I already had a > [metro]-like abstraction that can do intra-interval tempo changes. > However, I figured it was buggy (it worked only for the first tempo > change within an interval) and had to redo it. That was the most > difficult part. Combining it with [vline~ ] to make a [vphasor~ ] with > extra bangs at each wrapping point wasn't as hard (at least not with its > current limitations). > > Check attachment. > > Roman > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > -- m.e.grimm | m.f.a | ed.m. megr...@gmail.com _ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Rewriting a unified phasor / metro object for reading tables
(I believe this might rather belong to pd-list instead of pd-dev) On Don, 2014-03-06 at 18:56 -0500, me.grimm wrote: > Roman, > > >> wrapping points. The only drawback compared to [phasor~] is that > the > >> latter allows to control the frequency with a signal and the > >> [metro]/[vline~] based phasor obviously doesn't. > I never did quite figure it out but how do you do more advanced things > with [vline~] such as updating/increasing ramp speed mid ramp? Frankly, I often find myself struggling with those kinds of problems. > >> I'll be glad to help you build the [phasor~] replacement that has > an > >> additional bang outlet, if you need it. > > Are you saying this is possible with just metro/vline~ combo? I would > be curious what that looks like if you did build it It wasn't as easy as I initially expected it to be. I already had a [metro]-like abstraction that can do intra-interval tempo changes. However, I figured it was buggy (it worked only for the first tempo change within an interval) and had to redo it. That was the most difficult part. Combining it with [vline~ ] to make a [vphasor~ ] with extra bangs at each wrapping point wasn't as hard (at least not with its current limitations). Check attachment. Roman vphasor~.tar.gz Description: application/compressed-tar ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Rewriting a unified phasor / metro object for reading tables
Hi Brian, On 07/03/14 08:22, Brian Fay wrote: > Does anybody know if sample-accurate [metros] are available in libpd? Looking at x_time.c in libpd it does not seem like those changes from Miller's branch have been merged into libpd yet. I am sure somebody will get to it soon, or you could do it yourself and submit a patch. I would like to take this opportunity to say thanks to Dan and most especially Peter, and anybody else who is maintaining the libpd branch of Pd - it really is an amazing resource for the community. Cheers, Chris. -- http://mccormick.cx/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Rewriting a unified phasor / metro object for reading tables
On Tue, Mar 4, 2014 at 8:53 PM, Chris McCormick wrote: > > > Not sure if this is relevant or already common knowledge but newer > versions of Pd allow you to specify metro and delay tempo & units, > including in samples. e.g. [metro 500 1 samp]. > Does anybody know if sample-accurate [metros] are available in libpd? I'm making an application that allows for fairly arbitrary divisions of a tempo. Originally I was going to make clocks out of metros, but I wasn't aware that you could set a [metro] faster than one bang per ms. If I wanted a bunch of different rhythms, not just eigths and sixteenths, but triplets and divisions of fives or sevens or whatever, I would need to make a bunch of [metro] objects (or maybe one running at the least common multiple of the various divisions). In the end, I settled on handling this logic in the Java side of my application by counting samples and doing some math. I can schedule bangs at arbitrary divisions of a base amount of time (so I can make seven-tuplets or fiftythree-uplets or whatever strange rhythm I want to). In theory my solution should be sample-accurate, and it sounds like it's working fine. But is there a straightforward way to do this in pd that I completely overlooked? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Rewriting a unified phasor / metro object for reading tables
Hi, On 09/05/13 05:00, Ed Kelly wrote: > I'm rewriting phasor~ and unifying it with metro so that a pulse is > generated from the boundaries of each ramp - so that bars of music can > be read using tabread~ objects with a sample-accurate metro. Not sure if this is relevant or already common knowledge but newer versions of Pd allow you to specify metro and delay tempo & units, including in samples. e.g. [metro 500 1 samp]. Cheers, Chris. -- http://mccormick.cx/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Rewriting a unified phasor / metro object for reading tables
This is what it used to look like (forgot to include the pic ;) Ed Ninja Jamm - a revolutionary new musix remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ - Original Message - > From: Ed Kelly > To: i go bananas ; Ivica Ico Bukvic > Cc: PD List ; pddev > Sent: Thursday, 9 May 2013, 14:33 > Subject: Re: [PD] Rewriting a unified phasor / metro object for reading tables > > I figured out how to do this. > > Generally the problem is this: the signals to run four independent tracks in > my > patch are all devised from one phasor~ object that scans a single bar of > material. Clicks then appear in the material when jumping from one bar to the > next, because the control events are quantized to the 64 samples of a block. > So > we get lines like the picture enclosed that read the material using tabread~. > > In order to get rid of the clicks, I have an alternative method for reading > the > material _without_ adding any new DSP objects (this has to run on an iPhone > 4). > It involves the phasor~-esque object ramping from 0 to 8 over 8 bars or not, > depending on whether it is jumping around or smoothly reading the 2, 4 or > 8-bar > loop. > > I already have this working - it has to detect when the ramp is crossed and > generate a clock signal from it for the intra-bar rhythms. I took phasorshot~ > as > my prototype, but that had the same problem as before, namely that non-signal > pulses are quantized to 64 sample blocks. I tried using clocks but they went > out > of sync while the tempo was being changed of course. > > So, I built an object where all the clocks are derived from the phasor ramp, > but > sent out as control rather than DSP signals. It uses more CPU than phasor~ > does > (~70% more) but no matter how much you speed-up or slow down the phasor~ > on-the-fly, the clocks never go out-of-sync. It's called phasorbars~. > > I'll be uploading a version of the external soon to svn, and anyone > who's downloaded Ninja Jamm for their i-device will get an update soon also. > > Cheers, > Ed >> >> >> why not just make a half speed phasor~, retrigger the phase to zero with a > normal metro, and then multiply the output by 2? >> >> >> >> >> >> >> >> On Thu, May 9, 2013 at 10:09 AM, Ivica Ico Bukvic wrote: >> >> Assuming you want a pulse in non-signal domain, you could use disis_phasor~ > (see http://l2ork.music.vt.edu/main/?page_id=56 for download links) which > outputs a bang every time ramp is crossed. This is only accurate to the > nearest > sigvs size (by default 64 bytes) as there is no guarantee that you will get a > msg interrupt exactly at the time ramp has crossed. >>> >>> HTH >>> >>> From:pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of > Ed Kelly >>> Sent: Wednesday, May 08, 2013 5:00 PM >>> To: PD List; pddev >>> Subject: [PD] Rewriting a unified phasor / metro object for reading > tables >>> >>> Hi Lists(s), >>> >>> I'm rewriting phasor~ and unifying it with metro so that a pulse is > generated from the boundaries of each ramp - so that bars of music can be > read > using tabread~ objects with a sample-accurate metro. >>> >>> I'm sure someone will say this can already be done, but it has to be > dropped into the Ninja Jamm patch, so there isn't really time to rewrite the > rest of the patch. >>> >>> I don't fully understand the way phasor~ wraps, but I have the > object firing out bar numbers correctly. I'm putting clocks in for 16ths and > 24ths of the beat, initiated on each wrap. I need to minimise CPU, so what I > want to know is this: >>> >>> Does phasor~ always start from 0 and go to 1, i.e. is there always a > signal value of 0 at the start of the ramp and a signal value of 1 at the > end? > As I write this, my common sense tells me it should be "yes" but I > want to make sure. I suppose I should just try it really... >>> >>> Cheers, >>> Ed >>> >>> Ninja Jamm - a revolutionary new musix remix app from Ninja Tune and > Seeper, for iPhone and iPad >>> http://www.ninjajamm.com/ >>> Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! >>> http://sharktracks.co.uk/ >>> ___ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >>> >>> >> >> >> > <>___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Rewriting a unified phasor / metro object for reading tables
I figured out how to do this. Generally the problem is this: the signals to run four independent tracks in my patch are all devised from one phasor~ object that scans a single bar of material. Clicks then appear in the material when jumping from one bar to the next, because the control events are quantized to the 64 samples of a block. So we get lines like the picture enclosed that read the material using tabread~. In order to get rid of the clicks, I have an alternative method for reading the material _without_ adding any new DSP objects (this has to run on an iPhone 4). It involves the phasor~-esque object ramping from 0 to 8 over 8 bars or not, depending on whether it is jumping around or smoothly reading the 2, 4 or 8-bar loop. I already have this working - it has to detect when the ramp is crossed and generate a clock signal from it for the intra-bar rhythms. I took phasorshot~ as my prototype, but that had the same problem as before, namely that non-signal pulses are quantized to 64 sample blocks. I tried using clocks but they went out of sync while the tempo was being changed of course. So, I built an object where all the clocks are derived from the phasor ramp, but sent out as control rather than DSP signals. It uses more CPU than phasor~ does (~70% more) but no matter how much you speed-up or slow down the phasor~ on-the-fly, the clocks never go out-of-sync. It's called phasorbars~. I'll be uploading a version of the external soon to svn, and anyone who's downloaded Ninja Jamm for their i-device will get an update soon also. Cheers, Ed > > >why not just make a half speed phasor~, retrigger the phase to zero with a >normal metro, and then multiply the output by 2? > > > > > > > >On Thu, May 9, 2013 at 10:09 AM, Ivica Ico Bukvic wrote: > >Assuming you want a pulse in non-signal domain, you could use disis_phasor~ >(see http://l2ork.music.vt.edu/main/?page_id=56 for download links) which >outputs a bang every time ramp is crossed. This is only accurate to the >nearest sigvs size (by default 64 bytes) as there is no guarantee that you >will get a msg interrupt exactly at the time ramp has crossed. >> >>HTH >> >>From:pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Ed >>Kelly >>Sent: Wednesday, May 08, 2013 5:00 PM >>To: PD List; pddev >>Subject: [PD] Rewriting a unified phasor / metro object for reading tables >> >>Hi Lists(s), >> >>I'm rewriting phasor~ and unifying it with metro so that a pulse is generated >>from the boundaries of each ramp - so that bars of music can be read using >>tabread~ objects with a sample-accurate metro. >> >>I'm sure someone will say this can already be done, but it has to be dropped >>into the Ninja Jamm patch, so there isn't really time to rewrite the rest of >>the patch. >> >>I don't fully understand the way phasor~ wraps, but I have the object firing >>out bar numbers correctly. I'm putting clocks in for 16ths and 24ths of the >>beat, initiated on each wrap. I need to minimise CPU, so what I want to know >>is this: >> >>Does phasor~ always start from 0 and go to 1, i.e. is there always a signal >>value of 0 at the start of the ramp and a signal value of 1 at the end? As I >>write this, my common sense tells me it should be "yes" but I want to make >>sure. I suppose I should just try it really... >> >>Cheers, >>Ed >> >>Ninja Jamm - a revolutionary new musix remix app from Ninja Tune and Seeper, >>for iPhone and iPad >>http://www.ninjajamm.com/ >>Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! >>http://sharktracks.co.uk/ >>___ >>Pd-list@iem.at mailing list >>UNSUBSCRIBE and account-management -> >>http://lists.puredata.info/listinfo/pd-list >> >> > > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Rewriting a unified phasor / metro object for reading tables
why not just make a half speed phasor~, retrigger the phase to zero with a normal metro, and then multiply the output by 2? On Thu, May 9, 2013 at 10:09 AM, Ivica Ico Bukvic wrote: > Assuming you want a pulse in non-signal domain, you could use > disis_phasor~ (see http://l2ork.music.vt.edu/main/?page_id=56 for > download links) which outputs a bang every time ramp is crossed. This is > only accurate to the nearest sigvs size (by default 64 bytes) as there is > no guarantee that you will get a msg interrupt exactly at the time ramp has > crossed. > > ** ** > > HTH > > ** ** > > *From:* pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] *On Behalf > Of *Ed Kelly > *Sent:* Wednesday, May 08, 2013 5:00 PM > *To:* PD List; pddev > *Subject:* [PD] Rewriting a unified phasor / metro object for reading > tables > > ** ** > > Hi Lists(s), > > ** ** > > I'm rewriting phasor~ and unifying it with metro so that a pulse is > generated from the boundaries of each ramp - so that bars of music can be > read using tabread~ objects with a sample-accurate metro. > > ** ** > > I'm sure someone will say this can already be done, but it has to be > dropped into the Ninja Jamm patch, so there isn't really time to rewrite > the rest of the patch. > > ** ** > > I don't fully understand the way phasor~ wraps, but I have the object > firing out bar numbers correctly. I'm putting clocks in for 16ths and 24ths > of the beat, initiated on each wrap. I need to minimise CPU, so what I want > to know is this: > > ** ** > > Does phasor~ always start from 0 and go to 1, i.e. is there always a > signal value of 0 at the start of the ramp and a signal value of 1 at the > end? As I write this, my common sense tells me it should be "yes" but I > want to make sure. I suppose I should just try it really... > > ** ** > > Cheers, > > Ed > > > > Ninja Jamm - a revolutionary new musix remix app from Ninja Tune and > Seeper, for iPhone and iPad > http://www.ninjajamm.com/ > > Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! > http://sharktracks.co.uk/ > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Rewriting a unified phasor / metro object for reading tables
Assuming you want a pulse in non-signal domain, you could use disis_phasor~ (see http://l2ork.music.vt.edu/main/?page_id=56 for download links) which outputs a bang every time ramp is crossed. This is only accurate to the nearest sigvs size (by default 64 bytes) as there is no guarantee that you will get a msg interrupt exactly at the time ramp has crossed. HTH From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Ed Kelly Sent: Wednesday, May 08, 2013 5:00 PM To: PD List; pddev Subject: [PD] Rewriting a unified phasor / metro object for reading tables Hi Lists(s), I'm rewriting phasor~ and unifying it with metro so that a pulse is generated from the boundaries of each ramp - so that bars of music can be read using tabread~ objects with a sample-accurate metro. I'm sure someone will say this can already be done, but it has to be dropped into the Ninja Jamm patch, so there isn't really time to rewrite the rest of the patch. I don't fully understand the way phasor~ wraps, but I have the object firing out bar numbers correctly. I'm putting clocks in for 16ths and 24ths of the beat, initiated on each wrap. I need to minimise CPU, so what I want to know is this: Does phasor~ always start from 0 and go to 1, i.e. is there always a signal value of 0 at the start of the ramp and a signal value of 1 at the end? As I write this, my common sense tells me it should be "yes" but I want to make sure. I suppose I should just try it really... Cheers, Ed Ninja Jamm - a revolutionary new musix remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Rewriting a unified phasor / metro object for reading tables
Hi Lists(s), I'm rewriting phasor~ and unifying it with metro so that a pulse is generated from the boundaries of each ramp - so that bars of music can be read using tabread~ objects with a sample-accurate metro. I'm sure someone will say this can already be done, but it has to be dropped into the Ninja Jamm patch, so there isn't really time to rewrite the rest of the patch. I don't fully understand the way phasor~ wraps, but I have the object firing out bar numbers correctly. I'm putting clocks in for 16ths and 24ths of the beat, initiated on each wrap. I need to minimise CPU, so what I want to know is this: Does phasor~ always start from 0 and go to 1, i.e. is there always a signal value of 0 at the start of the ramp and a signal value of 1 at the end? As I write this, my common sense tells me it should be "yes" but I want to make sure. I suppose I should just try it really... Cheers, Ed Ninja Jamm - a revolutionary new musix remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
