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@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@iem.at [mailto:pd-list-bounces@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
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 morph_2016@yahoo.co.uk To: i go bananas hard.off@gmail.com; Ivica Ico Bukvic ico@vt.edu Cc: PD List pd-list@iem.at; pddev pd-dev@iem.at 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 ico@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@iem.at [mailto:pd-list-bounces@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
On Thu, 2013-05-09 at 14:33 +0100, Ed Kelly wrote:
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.
This is not the case when using [metro]/[del] in combination with [vline~] (saying this while only partially understanding what the [phasor~] are used for. Sorry, if I'm way off).
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.
The problem with [metro] is that when you change the tempo, the current interval sticks to the old tempo and the new tempo is only applied at the time of the next tick. It is possible to change the tempo in the middle of an interval by measuring the elapsed time since the last tick and calculating the remaining part of the interval with new tempo. This way it is possible to change the tempo of many simultaneously running [metro]s with different interval settings without them running out of sync. I implemented this to allow the creation of polyrhythmic sequencers. I made an abstraction ([rh_metro] [1]) which behaves very similar to [metro] but allows for in-interval tempo changes.
[1] https://github.com/reduzent/netpd2-patches.git
Roman