Re: [PD] [PD-dev] Rewriting a unified phasor / metro object for reading tables
On Thu, 2014-03-06 at 19:22 -0500, Brian Fay wrote: > 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? 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] Rewriting a unified phasor / metro object for reading tables
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" 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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] Rewriting a unified phasor / metro object for reading tables
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
Re: [PD] [PD-dev] Rewriting a unified phasor / metro object for reading tables
Thanks Katja. I'm doing things in a quick and dirty manner, to see if they work and so that they can be implemented quickly for the 100,000 or so downloads we've had, but I want to get it right. We'll have a testflight version next week so we'll be able to test the new version (it's like a heart transplant for the app). The first thing is that it has to work with the limited resources of the iPhone4 (the most basic device we are supporting). The second is to make it better, so that we can move from tabread~ s to tabread4~s, but I think this'll be just for the iPhone5. I really want it to be super efficient, so I'll study your code. Interesting that the original phasor~ relies on a double precision variable for the wrap. Sometime we need to move onto 128bit architecture, but probably not too soon ;) Cheers, Ed PS thanks for answering the question I asked. 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: katja > To: Ed Kelly > Cc: PD List ; pddev > Sent: Thursday, 9 May 2013, 10:12 > Subject: Re: [PD-dev] Rewriting a unified phasor / metro object for reading > tables > > On Wed, May 8, 2013 at 11:00 PM, Ed Kelly wrote: > >> ... >> 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... >> ... > > > A [phasor~] ramp should start with the remainder after wrapping, which > is non-zero in most cases. > > For pd-double I had to rewrite [phasor~], and it turned out that an > implementation with branching is more efficient on current Intel > processors. ARM processors do branch predication, it could be > efficient as well. You could try the code from here and put message > triggers in the branches: > > https://github.com/pd-projects/pd-double/blob/master/src/d_osc.c > > > Katja > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] Rewriting a unified phasor / metro object for reading tables
On Wed, May 8, 2013 at 11:00 PM, Ed Kelly wrote: > ... > 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... > ... A [phasor~] ramp should start with the remainder after wrapping, which is non-zero in most cases. For pd-double I had to rewrite [phasor~], and it turned out that an implementation with branching is more efficient on current Intel processors. ARM processors do branch predication, it could be efficient as well. You could try the code from here and put message triggers in the branches: https://github.com/pd-projects/pd-double/blob/master/src/d_osc.c Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] Rewriting a unified phasor / metro object for reading tables
Hi Ed, maybe the ramp abstraction in http://g.org/research/software/upp/upp-tut6c/ is of use for you. It doesn't wrap but just ramp endlessly. gr~~~ -- Thomas Grill http://g.org Am 08.05.2013 um 23:00 schrieb Ed Kelly: 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-dev mailing list pd-...@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
