On Don, 2018-04-05 at 22:55 +0200, Christof Ressi wrote:
> in the project I'm working on I have a couple of subpatches which
> shrink vertically whenever I close and open them...
> I made a funny little patch to demonstrate the issue. can anyone
> reproduce this on his/her machine?
I cannot repr
On Don, 2018-04-05 at 21:17 +0200, Dan Wilcox wrote:
> test? https://github.com/pure-data/pure-data/pull/346
Better do than talk, hey? ;-)
Works fine and is definitely convenient. Can't see any disadvantage or
problem with compatibility, though it challenges my notion of how
things are supposed t
I am reading a text file into an array. I would have expected the array
size to grow to the same as the number of lines/elements in the text
file but it seems to default to a size of 100. Is there a way for the
size of the array to take on the size of the text file automatically? If
not how do
Hi Jim,
Like [soundfiler]’s “-resize” flag, this would be a very useful feature for
array loading.
You can load a text file and then query its size, something like:
[read -c your_file, bang(
|
[text]
|\
[text size]
|
[array size your_array]
Best,
fede
On Apr 6, 2018, at 10:38 AM, Jim Rux
Hi list,
with the latest Debian testing versions (0.48.1) the font for the
console menus comes up with 24pt size, although the font dialog
indicates 12pt. Upon clicking 12pt once more the font changes to 12pt.
My .pdsettings file holds
-font-size 12
but the described behavior exists als
I don't think it makes sense to have a malloc() and free() for each call to a
msg box.
Pd is already not very real-time friendly, why make it worse?
There could be ...
- statically allocated memory for t_gstack y in pd_pushsym
- a pre-allocated memory pool meant for short-lived memory allocations
The second lazy-load option might work pretty well, but what would the
per-instance/threading considerations be?
> On Apr 6, 2018, at 12:21 PM, Giulio Moro wrote:
>
> I don't think it makes sense to have a malloc() and free() for each call to a
> msg box.
> Pd is already not very real-time fri
On Friday, April 6, 2018, 6:24:13 AM EDT, Giulio Moro via Pd-list
wrote:
> I don't think it makes sense to have a malloc() and free() for each call to
> a msg box.
> Pd is already not very real-time friendly, why make it worse?
> There could be ...
> - statically allocated memory for t_gsta
I might be a bug with calculating the size based on current zoom factor. Zoom
of 2 with font size 12 is 24...
> On Apr 6, 2018, at 2:41 PM, pd-list-requ...@lists.iem.at wrote:
>
> Date: Fri, 6 Apr 2018 11:36:30 +0200
> From: "Peter P." mailto:peterpar...@fastmail.com>>
> To: pd-list mailto:pd-l.
Yeah sorry I have no idea how deep these nest, I am not familiar with that part
of the code.
In this case the memory could be allocated in the stack and then passed to
something like pd_pushsymnoalloc(t_pd *x, t_gstack* y)
which should in turn skip the allocation. But yes, a cached value seems
Hello,
Le 06/04/2018 à 10:55, Fede a écrit :
> Hi Jim,
>
> Like [soundfiler]’s “-resize” flag, this would be a very useful feature for
> array loading.
>
>
> You can load a text file and then query its size, something like:
>
> [read -c your_file, bang(
> |
> [text]
> |\
> [text size]
> |
Hi Jack,
Well, yes, it was something ‘like’ that.
here it is with the missing [t b p] and [text size -s text t]
array-resize.pd
Description: Binary data
your_file
Description: Binary data
On Apr 6, 2018, at 4:21 PM, Jack wrote:
> Hello,
>
> Le 06/04/2018 à 10:55, Fede a écrit :
>> Hi J
Le 06/04/2018 à 16:21, Jack a écrit :
> Hello,
>
> Le 06/04/2018 à 10:55, Fede a écrit :
>> Hi Jim,
>>
>> Like [soundfiler]’s “-resize” flag, this would be a very useful feature for
>> array loading.
>>
>>
>> You can load a text file and then query its size, something like:
>>
>> [read -c your_f
OK, thanks.
Nice example using pointer.
On My side, I used to use [text define] (to load the text file) and
[text size] (to query the size with a 'bang' message).
++
Jack
Le 06/04/2018 à 16:36, Fede a écrit :
> Hi Jack,
>
> Well, yes, it was something ‘like’ that.
>
> here it is with the mis
here's an alternative implementation which uses no additional memory allocations but is more invasive: https://github.com/pure-data/pure-data/pull/347
Gesendet: Freitag, 06. April 2018 um 14:41 Uhr
Von: "Jonathan Wilkes via Pd-list"
An: pd-list@lists.iem.at, "Dan Wilcox"
Betreff: Re: [PD] sugg
Thanks for all the reporting... I still don't have Windows machine with an ASIO
device on it to test, but once I can get that together I'll try to figure out
what's going on.
(Other people are managing to compile it correctly; it's just something about
my setup I think).
Miller
On Fri, Apr 06, 2
ha, you're right! I just opened an issue:
https://github.com/pure-data/pure-data/issues/348
> Gesendet: Freitag, 06. April 2018 um 09:25 Uhr
> Von: "Roman Haefeli"
> An: pd-list@lists.iem.at
> Betreff: Re: [PD] shrinking subpatches!?
>
> On Don, 2018-04-05 at 22:55 +0200, Christof Ressi wrote:
>
Hi Alfonso,
On 4/6/2018 10:14 AM, alfonso santimone wrote:
> Hi Lucas,
> just to give a little bug report.
> If i select some MIDI devices the next time pd does not starts unless
> i launch it from command line with the -nomidi flag
First:
Please don't use "ASIO troubles" topic subject to infor
hi, i have a player abstraction and I want it to find files in the parent's
patch folder.
sure, i know i can use [declare ./] in the parent path, but I was hoping to
have this hard coded inside the abstraction.
Is there a vanilla way of doing this?
and how about a suggestion to make this possibl
I found a solution by updating one of my externals. I upgraded [else/dir]
to be able to get the parent's directory, and I'm using dynamic patching to
create [declare -path "parent's dir"]. I imagine this is impossible with
vanilla, but I'm good now.
cheers
2018-04-06 16:47 GMT-03:00 Alexandre Tor
20 matches
Mail list logo
