[PD-dev] [PD] Rewriting a unified phasor / metro object for reading tables

Ed Kelly morph_2016 at yahoo.co.uk
Thu May 9 15:33:01 CEST 2013


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 <ico at vt.edu> 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-bounces at iem.at [mailto:pd-list-bounces at 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 at iem.at mailing list
>>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
>
> 



More information about the Pd-dev mailing list