Re: [PD] Delay time limit bug (was: PVoc patch "bug"?)

here's another example, there's a delay line with a size of 2048 samples, in patch with a block size of 2048, and the delay line is only able to delay a maximum of 64 samples 2015-09-22 14:07 GMT-03:00 Alexandre Torres Porres : > > > 2015-09-22 5:56 GMT-03:00 Christof Ressi

Re: [PD] Pduino and arudino mini pro/raspi debian- Pduino or Comport?

i am saying i was using raspberry pi with an arduino uno and the comport help patch was working fine when i switched to the arduino pro mini that patch was not importing the values from the device in a readable format, when i switched to the pduino patch for whatever reason the values were

Re: [PD] Delay time limit bug (was: PVoc patch "bug"?)

2015-09-22 15:41 GMT-03:00 IOhannes m zmölnig : > this seems to be the easy route, just as [s~]/[r~] or [throw~]/[catch~]: > simply forbid the use of [delread~]/[vd~] if the block-sizes differ. > I think it's an elegant solution, and can't see why it would be a problem. But

Re: [PD] Understanding the mechanics of rebuilding Pd's DSP graph

In C, what's the overhead of having function_call(return array->x_size) insteadof array->x_size inside a perform routine? If that's not significant, it seems like it'd be better to over-allocate the array at creation/resize time and report the requested size to the user.  That way reallocation

Re: [PD] [vd~] VS [delread~] - different delay limit!

I found another difference between vd~ and delread~ vd~ will have that issue where you need to divide the time in ms for the overlap number - which I think is bad and maybe it should just work around that. It's really annoying working with a different time range. now, delread~ doesn't need that,

Re: [PD] Pduino and arudino mini pro/raspi debian- Pduino or Comport?

On 09/22/2015 07:58 PM, Pagano, Patrick wrote: > i am trying to apt-get that pd-pduino and it cannot locate it > is there a repo i need to update? when i said "but only since recently", i really meant it: the package has entered Debian/unstable on august 26, and has migrated to Debian/testing

Re: [PD] Delay time limit bug (was: PVoc patch "bug"?)

On 09/22/2015 08:27 PM, Alexandre Torres Porres wrote: > if you check my last patch, I can't see why it would have to be hard not to > make it happen. instead of bothering about the block sizes of the vd~ > objects, just make it sure the delwrite~ is at the same block size and it this seems to be

Re: [PD] Delay time limit bug (was: PVoc patch "bug"?)

if you check my last patch, I can't see why it would have to be hard not to make it happen. instead of bothering about the block sizes of the vd~ objects, just make it sure the delwrite~ is at the same block size and it should work one way or another, if not, it's just a bug. It's bad that you

Re: [PD] [vd~] VS [delread~] - different delay limit!

funny, I found out about the same thing and just posted on the thread that I'm reporting it as a bug Well, my oppinion is that there might be some explanation why it happens, but also that both objects have bugs regarding the way they operate as they can't reach the delay limit when it comes to

Re: [PD] Understanding the mechanics of rebuilding Pd's DSP graph

On Sun, 2015-09-20 at 22:19 +0200, IOhannes m zmölnig wrote: > On 09/17/2015 11:55 PM, Roman Haefeli wrote: > > > Is the time it takes to recalculate the graph only dependent on the > > number of tilde-objects running in the current instance of Pd? If so, is > > that a linear correlation? 10

Re: [PD] Pduino and arudino mini pro/raspi debian- Pduino or Comport?

i am trying to apt-get that pd-pduino and it cannot locate it is there a repo i need to update? Patrick Pagano B.S, M.F.A Audio and Projection Design Faculty Digital Worlds Institute University of Florida, USA (352)294-2020 From: Pd-list

Re: [PD] Delay time limit bug (was: PVoc patch "bug"?)

> well, I still consider it to be a bug, it's not that it is misleading, it is just not happening because of bug. > There's nothing to prevent you from reading a delay line to the maximum of what it was specified, if it can't, then the object is buggy. > If it has some limitation of a block

[PD] [vd~] VS [delread~] - different delay limit!

In the course of a discussion with Alexandre I ran into something really interesting: [delread~] and [vd~] have different delay limits! While [delread~] has always the buffersize minus the blocksize of the subpatch where it is located, the limit of [vd~] is 64 samples greater. Any explanations?  

Re: [PD] Delay time limit bug (was: PVoc patch "bug"?)

2015-09-22 5:56 GMT-03:00 Christof Ressi : > You're totally right that the sentence >The delay time is always at least > one sample *and at most the length of the delay line (specified by the > delwrite~)*< is misleading. > well, I still consider it to be a bug, it's not

Re: [PD] A patch to create a patch to create a patch to create a patch to close puredata...

Hi list, It's quite the same stuff than the last one, but not exactly, so... https://vimeo.com/140111564 Cheers... °1 Le 13/09/2015 02:04, Olivier Baudu a écrit : > Masterpieces !! :-D > > Are those patchs the ones Benjamin was talking about few answers before ? > (He saw them at the PdConv

Re: [PD] A patch to create a patch to create a patch to create a patch to close puredata...

Good one. I like how minimalist these all are. On Tue, Sep 22, 2015 at 5:39 PM, Olivier Baudu <01iv...@labomedia.net> wrote: > Hi list, > > It's quite the same stuff than the last one, but not exactly, so... > > https://vimeo.com/140111564 > > Cheers... > > °1 > > > Le 13/09/2015 02:04, Olivier

Re: [PD] Understanding the mechanics of rebuilding Pd's DSP graph

There's nothing wrong per se with resizing an array -- but there are good reasons not to do it while a patch is running after a [tab*] object has referred to it. I have myself only noticed audio dropouts when I'm resizing a table with soundfiler; I thought it must have been a disk-access

Re: [PD] Understanding the mechanics of rebuilding Pd's DSP graph

Does [soundfiler] rebuild the dsp graph on read, or only if the -resize flagis used?  If its the latter then you can just set the right array size ahead of time.Then if you still get dropouts you'll know it's the blocking i/o doing it. -Jonathan On Tuesday, September 22, 2015 10:50 PM,

[PD] more delay weirdness

wow, I'm still finding some weird things going on with delay lines and fft subpatches. Find my newest issue in the attached patch. Now I have only [z~] as the delay line (but same happens with [delay~]). So I have two patches: on the parent patch, [z~ 64] will act as a "back" window, and you can

Re: [PD] Delay time limit bug (was: PVoc patch "bug"?)

You're totally right that the sentence >The delay time is always at least one sample and at most the length of the delay line (specified by the delwrite~)< is misleading.   But the reason why it can't be exactly the length of the delay line is quite simple: Because in Pd audio is computed in

Re: [PD] Pduino and arudino mini pro/raspi debian- Pduino or Comport?

On 2015-09-22 04:47, Pagano, Patrick wrote: > I could not get the arduino pro mini to work with just comport no matter how > i tried, so i installed "Pduino" and [...] got it to work. i'm not sure i understand what you are trying to say here. "Pduino" is really just an *abstraction* built around

Re: [PD] how to expand time limit for video delay? -> ramfs

hi list > ssd buffer? if i remember correctly you can capture a video stream to a file and read it simultaneously and asynchronously (neologism?) using linux perhaps have a look for examples of that, or..use tapes :-) if you have some spare RAM, use ramfs, even faster then ssd cheers