On 02/27/2016 12:34 AM, s p wrote:
> Hi!
>
> I am trying to use [utime] to get an absolute date in seconds since epoch.
> However, the number of seconds seems to be rounded, so I don't understand
> how is it of any use!? For example, the following patch prints 0 ...
>
short answer: single precis
Yes, I guessed the issue was with precision, but in that case why would
anyone want to use it?
I was about to use [zexy/time], but [utime] would have been so much simpler
in my case ...
On Sat, Feb 27, 2016 at 10:23 AM, IOhannes m zmölnig
wrote:
> On 02/27/2016 12:34 AM, s p wrote:
> > Hi!
> >
>
I really wish Pd had a 32 bit integer data type for counters, and other
places where integers are appropriate.
This problem with single precision floats is my #1 gripe/ buzz-killer
(but overall, I am very, very happy with Pd!)
e.g. I spent aa few hours with it, but was unable to master the o
my guess for your last question:
no overlap:
[tabsend~] is now at blocksize 128 and [tabrecieve~] at blocksize 64. Every
other block, [tabsend~] is still busy filling the rest of the table while
[tabreceive~] is reading the last 64 samples a second time (since the table
couldn't been updated y
Hi list,
I think that this question was already pointed out in this list, but I
can't find it anymore.
Is there a simple way to chek if a pd patch is made only using vanilla
object?
Or:
Is there a way to find which external lib are needed for a given patch?
A possible solution is to keep a plai
On 27/02/16 11:05, Alessio Degani via Pd-list wrote:
Hi list,
I think that this question was already pointed out in this list, but I
can't find it anymore.
Is there a simple way to chek if a pd patch is made only using vanilla
object?
Or:
Is there a way to find which external lib are needed for a
>
>
>
> > It would allow you to do things like partitioned convolution without any
> delay, since the convolution of two 64-sample windows fills a 128-sample
> window.
>
> sounds more like the classic overlap-add-method. can you explain more?
>
>
>
OK, forget partitioning and imagine that your im
On 27/02/2016 13:12, Claude Heiland-Allen wrote:
On 27/02/16 11:05, Alessio Degani via Pd-list wrote:
Hi list,
I think that this question was already pointed out in this list, but I
can't find it anymore.
Is there a simple way to chek if a pd patch is made only using vanilla
object?
Or:
Is there
On 02/27/2016 09:55 AM, William Huston wrote:
> I really wish Pd had a 32 bit integer data type for counters, and other
> places where integers are appropriate.
actually i strongly disagree: i think it is one of Pd's killer features
to have a single numeric type.
the only problem is that the actu
On 02/27/2016 12:05 PM, Alessio Degani via Pd-list wrote:
> Is there a simple way to chek if a pd patch is made only using vanilla
> object?
as in: install Pd-vanilla, start it with "-noprefs -verbose" and load
the patch?
then see if any object couldn't create.
then check the Pd-console to see wh
On 02/27/2016 03:21 AM, Lucas Cordiviola wrote:
> link which points to http://wiki.puredata.info/en/osc~ that don't exist yet.
well, given that pdpedia died a couple of years ago, the "yet" is
slightly euphemistic.
gfmards
IOhannes
signature.asc
Description: OpenPGP digital signature
___
On 02/27/2016 09:40 AM, s p wrote:
> Yes, I guessed the issue was with precision, but in that case why would
> anyone want to use it?
[utime]? i have no idea.
what's worse: i have no clue why anyone would *write* that object with
the given limitations of a single precision Pd.
gmasrd
IOhannes
> we should have switched to doubles long ago.
According to katja, that would trigger a zombie apocalypse in external land.
And the only way to tell the zombies from the survivors would be to... *gulp*...
actually read external library code.
Personally, I'd rather get eaten by a zombie than do th
It would change some pretty major things in vanilla, too. For instance,
[phasor~], [osc~], and [tabosc4~] all depend on a bit-manipulation trick to
wrap phase, which won't work with doubles. I'm not sure if the output is
any different, but it does save the per-sample bounds check and is
theoretical
Sorry, I didn`t know it lived in the past, never use it.
Could we use wikipedia for that and somehow guarantee longevity, ease of use
for the community, and multilingual html help files?
Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at
From: zmoel...@iem.at
Date: Sat, 27 Feb 201
Sorry, I didn`t know it lived in the past, never use it.
Could we use wikipedia for that and somehow guarantee longevity, ease of use
for the community, and multilingual html help files?
Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at
From: zmoel...@iem.at
Date: Sat, 27 Feb 201
> It would change some pretty major things in vanilla, too. For instance,
> [phasor~], [osc~], and [tabosc4~] all depend on a bit-manipulation trick to
> wrap phase, which won't work with doubles.
katja addressed this with Pd Double.
See:http://www.katjaas.nl/doubleprecision/doubleprecision.htm
On 02/27/2016 04:49 PM, Jonathan Wilkes via Pd-list wrote:
>> we should have switched to doubles long ago.
> According to katja, that would trigger a zombie apocalypse in external land.
first of all, we should have switched to doubles *long* ago.
> And the only way to tell the zombies from the
Thanks so much for that! I’ve been enjoying its fruits recently.
Peter
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
> hmm, what again was wrong with my proposal to distinguish between single
and double precision externals, allowing to have externals that would
work on both precisions ("phat")?
The problem I'm describing is how to distinguish between the externals with
t_float=double that work as they should, an
> I feel one of the best aspects of PD are the examples via help patches so
> maybe splitting things up outside of PD might work against that?
That is definitely a great feature. If there's a way to keep that and add sane
multi-language support, that would
be the way to go.
-Jonathan
On
As an sketch:
pd nameoftheobject
@wikipedia.org
pd osc~ or with the
underscore pd_osc~
https://en.wikipedia.org/wiki/pd_osc~
It will be slow to fill
objects but...
>
I feel one of the best aspects of PD are the examples via help
patches so maybe splitting things up outside of PD
Yes... These way seems to some 99% of the auto learning issues about help
translations... Much more I can imagine before this thread..
Em sáb, 27 de fev de 2016 15:13, Jonathan Wilkes via Pd-list <
pd-list@lists.iem.at> escreveu:
> > I feel one of the best aspects of PD are the examples via help
so, you could do it, but it's insane to do partitioned convolution as a
patch, right?
2016-02-27 10:42 GMT-03:00 Matt Barber :
>
>>
>> > It would allow you to do things like partitioned convolution without
>> any delay, since the convolution of two 64-sample windows fills a
>> 128-sample window.
No, I have one in the works. I had to take some months off to write a piano
concerto, but once this is done I can get back to it and show you. It won't
be quite as quick as [partconv~] (and even [partconv~] used naïvely isn't
nearly as quick as [partconv~] used well).
On Sat, Feb 27, 2016 at 2:10
Em sáb, 27 de fev de 2016 15:46, Lucas Cordiviola
escreveu:
> As an sketch:
>
>
> pd nameoftheobject @wikipedia.org
>
>
> pd osc~ or with the underscore pd_osc~
>
>
> https://en.wikipedia.org/wiki/pd_osc~
>
>
> It will be slow to fill objects but...
>
>
>
> > I feel one of the best aspects of PD
Eventually the user can
make his particularly language translated patch:
Or it can be obteined with
some href and an Id, not sure if its posible:
pd_obj...@wikipedia.org
#N canvas 20 43 698 447
12;
#X floatatom 524 338 0 0
0;
#X floatatom 353 338 0 0
0;
#X floatatom 298 338 0
Of course if we`re gonna
use wikipedia.org as storage for encoded html information of a
software we should tell them about it an ask for their permission.
Probably they say no.
So we will be looking for
another server.
But...
Mensaje telepatico asistido por maquinas.
From: lucard...@hotma
by the way, partconv~ is buggy, we should fix it... I emailed bsaylor a
couple of years ago and he said he didnt have time for it
2016-02-27 16:16 GMT-03:00 Matt Barber :
> No, I have one in the works. I had to take some months off to write a
> piano concerto, but once this is done I can get back
There are chances that
we`re welcome at wikipedia.
Mensaje telepatico asistido por maquinas.
From: lucard...@hotmail.com
To: pd-list@lists.iem.at
Date: Sat, 27 Feb 2016 21:18:01 +
Subject: Re: [PD] multi-language help patches
Of course if we`re gonna
use wikipedia.org as storage for enco
Probably an html server
can provide both things, the html help AND the translated patch in
the same url.
Whats important is that in
can be completed/translated by users.
Wikipedia is the most
familiar one to almost everyone. (perhaps I'm wrong here, not sure)
Mensaje telepatico asistido por m
Portuguese translation of help patches are guaranteed! :)
Em sáb, 27 de fev de 2016 19:07, Lucas Cordiviola
escreveu:
> Probably an html server can provide both things, the html help AND the
> translated patch in the same url.
>
>
> Whats important is that in can be completed/translated by users
+1
Yep, with :
$ pd -noprefs -verbose...
seems the way to go.
++
Jack
Le 27/02/2016 16:35, IOhannes m zmölnig a écrit :
> On 02/27/2016 12:05 PM, Alessio Degani via Pd-list wrote:
>> Is there a simple way to chek if a pd patch is made only using vanilla
>> object?
>
> as in: install Pd-vanill
Le 27/02/2016 16:49, Jonathan Wilkes via Pd-list a écrit :
>> we should have switched to doubles long ago.
>
> According to katja, that would trigger a zombie apocalypse in external
> land.
> And the only way to tell the zombies from the survivors would be to...
> *gulp*...
>
> actually read ext
Le 27/02/2016 17:31, IOhannes m zmölnig a écrit :
> On 02/27/2016 04:49 PM, Jonathan Wilkes via Pd-list wrote:
>>> we should have switched to doubles long ago.
>> According to katja, that would trigger a zombie apocalypse in external land.
>>
>
> first of all, we should have switched to doubles
I was always asking myself why FFT convolution in Pd is usally done without
zero-padding and with a sqared hann-window. theoretically, ommiting
zero-padding leads to circular convolution, but the squared hann-window seems
to prevent audible artifacts. However, having less delay using your [tabse
Can you point to an example of this? I don't think it would work for
partitioned convolutions, e.g. for reverb, where we need the linear
convolution.
I was always asking myself why FFT convolution in Pd is usally done without
zero-padding and with a sqared hann-window. theoretically, ommiting
zero-
37 matches
Mail list logo