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

Hello,

I try to build pd-double with a configure time program-suffix option:

./configure --enable-jack --enable-double-precision --program-suffix=-double

Builds ok but doesn't run :

$ pd-double priority 6 scheduling enabled. priority 8 scheduling enabled. sh: 1: /usr/local/lib/pd/bin/pd-watchdog: not found Error in startup script: couldn't read file "/usr/local/lib/pd/tcl//pd-gui.tcl": no such file or directory

Of course pd-watchdog is now pd-watchdog-double and pd-gui.tcl is pd-gui.tcl-double.

What can I do?

Cheers, Joël

Hello Katja,

I just try pd-double, and I have to say it is very nice to play long soundfile with [soundfiler] :) Where can i find list of libraries that use double float that i can use with pd-double ? ++

Jack

Thanks, a local install in a directory out of the path works well.

Joël

Le samedi 01 mars 2014 à 13:59 +0100, katja a écrit :

Never tried a program suffix, at may not work at all but anyway pd-double will only start when it is installed. A local install using configure time prefix option is much recommended, see INSTALL.txt. By the way note that pd-double is based on pd 0.43 (vanilla) and unmaintained.

Katja

On Sat, Mar 1, 2014 at 12:18 PM, moa jdlvmail@gmail.com wrote:

...

Hello,

I try to build pd-double with a configure time program-suffix option:

./configure --enable-jack --enable-double-precision --program-suffix=-double

Builds ok but doesn't run :

$ pd-double priority 6 scheduling enabled. priority 8 scheduling enabled. sh: 1: /usr/local/lib/pd/bin/pd-watchdog: not found Error in startup script: couldn't read file "/usr/local/lib/pd/tcl//pd-gui.tcl": no such file or directory

Of course pd-watchdog is now pd-watchdog-double and pd-gui.tcl is pd-gui.tcl-double.

What can I do?

Cheers, Joël

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On Tue, Mar 4, 2014 at 8:53 PM, Chris McCormick chris@mccormick.cx 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?

On Thu, 2014-03-06 at 19:22 -0500, Brian Fay wrote:

On Tue, Mar 4, 2014 at 8:53 PM, Chris McCormick chris@mccormick.cx 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?

Assuming, that libpd uses the same code for [metro], I'd say yes.

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.

[metro] used to have an artificial lower limit of 1ms. I assume this was implemented in order to save Pd from freezing if a [metro] accidentally received a '0' as interval. It seems that is not the case anymore in 0.45. The current behavior is that it allows any non-zero input, but falls back to one unit as defined in the 'tempo' method when set to 0.

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.

This is still only sample precise, while you could make it sub-sample precise in Pd.

This isn't addressed to you specifically, but it is a common misconception to think of the audio domain as being precise and the message domain as being rounded to vectors. This might apply to many softwares, especially those that have two configured rates, one audio sampling rate and one fixed control rate. However, there is no such thing as a control rate in Pd. It is true, though, that many classes with message inlets and signal outlets only evaluate the incoming message only at block boundaries ([tabplay~], [line~] and more). However, [vline~] is the __one__ class that connects the two worlds (message and signal) without losing precision. But I'm getting off-topic now, as your topic is about precision in the message domain only. Anyway, the precision of [metro], [delay], [timer] and co is only limited by the float type used in Pd.

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?

It depends on what you consider straight-forward. It is certainly possible to have many [metro]s with arbitrary divisions running in sync. I still think the whole topic is very complex. I implemented something like that in some of the netpd instruments. However, I figured the tick rate of the master metro would be way too high, if I'd make it dividable by all the possible divisions I can think of. I went for a different strategy. The master metro ticks at 16th of the given BPM. I made an [metro] replacement abstraction that takes divisor and dividend as arguments. [polymetro 7 5] plays 7 ticks within the period of 5 ticks of the master metro. [polymetro] is designed so that it runs on its own and plays 7 ticks and then waits for every 5th master tick to start again. The difficult part was to allow tempo changes without losing sync. Pd's [metro] applies the new tempo only at the next tick. In order to be able to run many [polymetro]s concurrently without them losing sync on tempo changes, I had to create a [metro] replacement that allows for in-interval tempo changes. By using that [metro] replacement in the master metro and the [polymetro]s, it is possible to change tempo at any time without losing sync. One issue, that I haven't solved yet is a clean start at an arbitrary tick. [polymetro] doesn't immediately start when master metro is started at a non-zero tick, but it waits for the next sync tick of the master (any 5th master metro tick in the case of [polymetro 7 5]).

Roman

There is also disis_phasor~ that does exactly what you mentioned (it is available as a separate download as well as part of pd-l2ork). Namely, it has 2 outlets with the right one firing a bang whenever ramp is complete. This, however is only accurate to the nearest vector size (default 64 samples). On Mar 5, 2014 3:27 AM, "Roman Haefeli" reduzent@gmail.com wrote:

On Wed, 2013-05-08 at 22:00 +0100, Ed Kelly wrote:

...

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,

Yes!

...

but it has to be dropped into the Ninja Jamm patch, so there isn't really time to rewrite the rest of the patch.

Frankly, I am pretty sure, just using what Pd provides is too easy to use and likely less time consuming than writing your custom external. (Or I am totally missing the point of this adventure).

...

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...

No, it's not the case. A [phasor~] ramp virtually starts always at 0 and ends at 1 - true, but most of the time the wrapping point doesn't lie exactly on sample boundaries. This means the sample values around the wrapping point are almost never 1 or 0, respectively.

Trying to derive precise timing from the audio domain is a moot exercise anyway, in my opinion. The best you can get from this approach is sample precision and analyzing all samples of a signal is relatively expensive.

If you truly care about CPU consumption and a proper design from the start, use [metro] - which is as precise as 32-bit floats can be - and [vline~] - which actually uses the precise timing from [metro] (as opposed to [line~] that doesn't).

With this combo [metro]/[vline~] you can rebuild [phasor~] with the additional benefit of giving you more-than-sample-exact bangs at the 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'll be glad to help you build the [phasor~] replacement that has an additional bang outlet, if you need it.

Roman

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list