Re: [PD] So [bang~] can't "bang" in less than 64 blocksize, huh?

> there must be other examples... like from control objects, seems the bang GUI will also only fire at 64 block periods. sorry if I annoy, but I find it all curious and interesting 2015-03-14 3:36 GMT-03:00 Alexandre Torres Porres : > It seems there are other objects that somehow restrict thems

Re: [PD] So [bang~] can't "bang" in less than 64 blocksize, huh?

It seems there are other objects that somehow restrict themselves to a 64 size block minimum. print~ will always start printing from the beginning of a 64 block period snapshot~ will always output the last sample from an audio block of 64 there must be other examples... cheers 2015-03-14 2:02

Re: [PD] maximum "control rate" in Pd

2015-03-12 19:36 GMT-03:00 Alexandre Torres Porres : > since it was mentioned here, what's the behaviour and deal with > [vnsapshot~]? Cause there's no help file for ir yet. > Made a few tests and saw how snapshot~ only outputs the last saple from an audio block, and also how vsnapshot~ can outpu

Re: [PD] So [bang~] can't "bang" in less than 64 blocksize, huh?

attached patch 2015-03-14 2:02 GMT-03:00 Alexandre Torres Porres : > I was trying to get a bang at every sample and found out that the minimum > time bang~ works is at the 64 blocksize, check attached patch. > > Anyway, no question, just saying... but yeah, I don't see why it has to be > this way

[PD] So [bang~] can't "bang" in less than 64 blocksize, huh?

I was trying to get a bang at every sample and found out that the minimum time bang~ works is at the 64 blocksize, check attached patch. Anyway, no question, just saying... but yeah, I don't see why it has to be this way. Hopefully it can increase its resolution someday. cheers __

Re: [PD] Pd performance relationship to CPU model

On 03/13/2015 09:08 AM, Samuel Burt wrote: I had watched the CPU numbers drop on portable Mac computers for some time with frustration. At first, my friends said the extra cores will give me more performance. Pd isn't multi-threaded! Then Intel started the auto-overclock trend. Does Pd cause

Re: [PD] maximum "control rate" in Pd

On 03/13/2015 09:23 PM, Martin Peach wrote: > Yes I just realized .00756ms is three times the sample rate, so the > "control rate" is faster than the sample rate. > Makes sense now. Does it make sense for that to be possible though? What > use is it? like: upsampling to an arbitrary rate, doing s

Re: [PD] maximum "control rate" in Pd

Yes I just realized .00756ms is three times the sample rate, so the "control rate" is faster than the sample rate. Makes sense now. Does it make sense for that to be possible though? What use is it? Martin On Fri, Mar 13, 2015 at 4:17 PM, IOhannes m zmölnig wrote: > On 03/13/2015 09:10 PM, IOh

Re: [PD] maximum "control rate" in Pd

On 03/13/2015 09:10 PM, IOhannes m zmölnig wrote: > so your rate is really low, lower than sr. which of course should have read: "high" btw, you are multiplying your input signal (at 44.1Hz) with a rectangle signal at 3*samplerate: of course you are getting aliasing. fgrdsam IOhannes signatu

Re: [PD] maximum "control rate" in Pd

On 03/13/2015 09:10 PM, IOhannes m zmölnig wrote: > when i change the tabsize to something small (like 44), and the input using a small tabsize has two advantages: - signals with a high frequency can be inspected more easily - there is less data sent from pd-core to pd-gui, does making the gui mor

Re: [PD] maximum "control rate" in Pd

On 03/13/2015 09:03 PM, IOhannes m zmölnig wrote: > On 03/13/2015 08:43 PM, Martin Peach wrote: >> Yes with [vline~] it goes finer, but try using numbers around 756 in the >> upper number box in this patch, I get long intervals, it's as though the >> control rate is aliasing. > > cannot reproduce.

Re: [PD] maximum "control rate" in Pd

The upper number box is then multiplied by 10^-5 so it should be .00756ms. Yes I don't have actual sound here so it could be the display that's aliasing. I'm using pd 0.46-5 on WinXP. I'll try again when I get home. Martin On Fri, Mar 13, 2015 at 4:03 PM, IOhannes m zmölnig wrote: > On 03/13/20

Re: [PD] maximum "control rate" in Pd

On 03/13/2015 08:43 PM, Martin Peach wrote: > Yes with [vline~] it goes finer, but try using numbers around 756 in the > upper number box in this patch, I get long intervals, it's as though the > control rate is aliasing. cannot reproduce. (though it's a bit unclear what yo umean by "in the upper

Re: [PD] maximum "control rate" in Pd

On 03/12/2015 09:16 PM, Cyrille Henry wrote: > - from the outside, clock accuracy is related to block size and sample > rate. i think this is a but misleading, as it completely ignores the output objects. e.g. when dealing with audio-processing, audio samples are calculated in bursts of small blo

Re: [PD] maximum "control rate" in Pd

Yes with [vline~] it goes finer, but try using numbers around 756 in the upper number box in this patch, I get long intervals, it's as though the control rate is aliasing. Martin On Fri, Mar 13, 2015 at 3:16 PM, Alexandre Torres Porres wrote: > > The attached patch lets you see Pd's "control ra

Re: [PD] maximum "control rate" in Pd

You're measuring many things at once:1) lower limit of [metro] granularity, which is much higher than other clock-based objects in Pd like [del] and [pipe]2) common way in which control messages are converted to signals on the block boundaries (the other way is how vline~ and vsnapshot~ do it)3)

Re: [PD] maximum "control rate" in Pd

> The attached patch lets you see Pd's "control rate" in action. this is not the best way to measure this, cause [*~ 0] is not able to convert data to audio as you expect, it's best to use [vline~]. cheers 2015-03-13 14:55 GMT-03:00 Martin Peach : > On Fri, Mar 13, 2015 at 3:51 AM, Alexandre To

Re: [PD] maximum "control rate" in Pd

On Fri, Mar 13, 2015 at 3:51 AM, Alexandre Torres Porres wrote: > > About the "control rate" paradigm in Pd, I have to admit that when I asked > about it I was thinking about it in relation to what that means in > supercollider and Csound, but I also always considered that Pd doesn't > really hav

Re: [PD] oscparse multiple routing. Was: Re: OSC over netsend -u -b

Also, of interest, is a little tutorial patch I wrote when I was learning the new osc objects:  mrpeach-to-vanilla-osc.pd Description: Binary data Dan Wilcox@danomatikadanomatika.comrobotcowboy.com On Mar 12, 2015, at 2:19 PM, Dan Wilcox wrote:I am now wondering h

Re: [PD] [GEM] Latest OS X version working with GEM

>> On Fri, Mar 13, 2015 at 9:48 AM, IOhannes m zmölnig wrote: >> something else must have "become quite problematic"... yes osx but responsibility aside, the two (pdx + osx 10.10) now fail to play nice together m On Fri, Mar 13, 2015 at 9:48 AM, IOhannes m zmölnig wrote: > i'm followin

Re: [PD] maximum "control rate" in Pd

On 03/12/2015 10:11 PM, Roman Haefeli wrote: > On Don, 2015-03-12 at 21:16 +0100, Cyrille Henry wrote: >> for the simple answer, i would say that : >> -from inside a patch, pd clock accuracy is "infinite" > > That is actually what I meant when I said it was limited by the > precision of the floati

Re: [PD] [GEM] Latest OS X version working with GEM

i'm following the recent thread with interest (for obvious reasons), but try to not chime in. however, i cannot resist this one: On 03/12/2015 04:44 PM, me.grimm wrote: > yeah Gem (from pdx 0.43.4) has become quite problematic in teaching. at since "Gem (from pdx 0.43.3)" has not changed a jota

Re: [PD] OSC over netsend -u -b

On 03/12/2015 05:52 PM, Dan Wilcox wrote: > Split the list and convert the first element into a set message. Then pipe > the rest of the list (2nd outlet of [list split 1] into [oscformat). > just make sure that the "set" message arrives at the [oscformat] object before the remainder of the list.

Re: [PD] Pd performance relationship to CPU model

I had watched the CPU numbers drop on portable Mac computers for some time with frustration. At first, my friends said the extra cores will give me more performance. Pd isn't multi-threaded! Then Intel started the auto-overclock trend. Does Pd cause a CPU to run at its maximum speed now? If I were

Re: [PD] Pd performance relationship to CPU model

On 12/03/15 16:25, Roman Haefeli wrote: > I've been using Pd and having netpd sessions on my 8 year old Laptop > happily ever since. Recently, I was doing a session on my much newer (1 > year old) work computer and I was hitting the CPU limit much quicker > than I'd expected. I booted my old lapto

Re: [PD] maximum "control rate" in Pd

On Fri, 2015-03-13 at 04:51 -0300, Alexandre Torres Porres wrote: > I'm aware that CPU can choke on an absurdly fast control rate. > Nonetheless, the concern and question is not to how much the CPU can > take, but how small a period of time Pd could consistently and > steadily send messages. To m

Re: [PD] svg script (with pdlua?)

that should work theoretically, but it's maybe a too complicated of a task, involving lots of extra processing? meanwhile j wilkes pointed out a fairly simple solution, svg can use spaces instead of commas. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Converting all your text file in its

Re: [PD] svg script (with pdlua?)

you are right, it works perfectly. although at some point it would be very useful for me to learn how to use lua to process data generation. On 03/11/2015 01:54 PM, João Pais wrote: Hello list, I wanted to create an svg file using Pd, but it's a bit hard, as the character "," can't be use

Re: [PD] maximum "control rate" in Pd

>> I thought there was a limit control rate that was below >> the audio rate, but curiously it can go over. > That is what I'm trying to say since - I don't know - at > least three posts. And I understood that even before I asked to the list in my first email, when I first mentioned that the fact