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 <i...@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-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-l...@iem.at mailing list >>UNSUBSCRIBE and account-management -> >>http://lists.puredata.info/listinfo/pd-list >> >> > > > _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
